问在进行正式的代码评审时，什么是有用的心态？

EN

记住了总体目标:最终，只有工作软件才会影响

同行评审和签入代码评审是提高质量的目标。但就质量而言，没有什么比缺乏动力的开发人员更糟糕了。作为团队的领导者，您的角色不是认可代码，而是促进团队合作并确保整体结果。

为您的审查设置了一个明确的范围，

记住:这不是你的代码，而是团队的代码。所以，关注那些可能导致错误结果的事情。

• 不要挑战您的开发人员选择满足需求的方式，除非您确信它不能工作(但是它应该已经通过了测试，不是吗？)
• 不要对糟糕的表现提出质疑，除非有一个指标显示问题的所在。过早优化是万恶之源;-)
• 如果你发现一个设计或软件结构是要挑战的，那就问问自己，为什么它没有被预先抓住！已经编写的代码要重写成本很高。如果发生这种情况，那么是时候回顾您的软件开发和团队合作实践了，至少与代码一样多。
• 处理符合既定编码标准的问题。这是最恼人的话题，无论是评论人还是评论人都要讨论。当每个人都同意在你的团队中使用大写类名，而一个人没有大写类名的时候，这是一个品味问题吗？还是团队合作的有效性和风险？

顺便说一句，如果你觉得编码标准不值得讨论，从你的标准中删除它，不要在它上浪费时间和精力。

发展领导力:回顾的人的一面

作为一个团队领导者，你可能会在这里发现一个发展自己和团队的机会，超越了质量控制的形式：

• 如果有真正的交流，代码评论对每个人来说都要愉快得多。让你的开发人员也有机会展示他们的技能(是的，也许你可以学到一些新的东西)。
• 公开听取对设计选择或现有标准的批评。有时候，人们可以更好地应对这种挫折，仅仅是因为他们可以谈论它。
• 指导你的初中生:不要犹豫给出建议，或者为下一次迭代重构方向。不要对高年级的人这样做:在另一个世界里，你们各自的角色可能已经改变了。

利用其他实践

在代码评审中，您可以避免以下几点：

• 在构建链中使用静态代码分析器可以在同行评审之前实现常见臭虫的发现或非便携结构的自动化。有些工具甚至可以使用检查您的一些编码标准。
• 如果您有关于代码布局的标准，请使用预提交漂亮打印或相似形成器自动格式化代码。不要把时间花在软件能为你做得更好的事情上，而不讨论:-)
• 最后，质量不仅是通过审查，而且也是通过测试。如果您还没有使用TDD，那么独立于代码评审来考虑它。

作为开发人员，我们的心态应该始终保持开放和怀疑。

开放，因为我们不知道开发人员什么时候会给我们带来惊喜，我们对自己的想法持怀疑态度，因为我们经常忘记，在软件工程中，没有一种实现解决方案的正确方法。我们的解决办法背后的理由对我们来说是有意义的，而对其他人则没有道理。在代码气味后面可能有个好主意。也许，开发人员没有找到正确表达它的方法。

由于我们(人类)沟通能力很差，不要做错误的假设，愿意向代码所有者询问您正在查看的代码。如果他/她没有按照公司的标准对这个想法进行编码，作为首席开发人员，他/她也愿意指导他/她。

这里是主观的方法。客观的方法，国际海事组织，很好地解释了在这个问题上。

除了上述环节外，还需要达到一组目标(可维护性、可读性、可移植性、高凝聚力、松散耦合等)。不一定是十诫。您(团队)应该能够将这些目标调整到这样一个程度，即质量和生产力之间的平衡使工作能够适应并“适合开发人员居住”。

根据这些目标，我建议使用静态代码分析工具来衡量质量的进展。像SonarQube这样的工具可以根据我们的优先级定制质量门和质量概要文件。它还为我们提供了一个问题跟踪器，开发人员可以针对与代码嗅觉、bug、可疑实践等相关的问题。

这类工具可能是一个很好的起点，但正如我所说，要保持怀疑态度。你可以在Sonar中找到一些对你来说毫无意义的规则，所以你可以忽略它们或者从你的质量简介中删除它们。

干预开发人员的代码以进行外观更改将使开发人员失去工作积极性，但在绝对情况下必须这样做。领导必须在提供有用的代码审查和学会放弃小缺点之间找到平衡。https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/