进行正式代码审查时有什么有益的心态

我们的团队最近开始对每个签入进行代码审查。

作为团队的负责人，我试图在提供过多建议，使开发人员烦恼和减少团队输出，以及放开我本应以不同方式编写的代码之间找到平衡。

是否有来自知名来源的证据，研究或指南建议有用的方法？

牢记总体目标：最后，只有有效的软件才重要

同行审查和签入代码审查的目标是提高质量。但是，没有什么比没有动力的开发人员更能保证质量的了。作为团队负责人，您的角色不是认可您自己可以编写的代码，而是促进团队合作并确保总体结果。

为您的审核设置明确的范围

请记住：这不是您的代码，而是团队的代码。因此，专注于可能导致错误结果的事情。

• 不要挑战开发人员选择满足要求的方式，除非您确定它不起作用（但是它应该已经通过了测试，对吗？）

• 除非有能够表明问题出在哪里的度量，否则不要对性能低下提出挑战。过早的优化是万恶之源;-)

• 如果您发现要挑战的设计或软件结构，请问自己为什么不被预先抓住！已经编写的代码重写成本很高。如果发生这种情况，是时候至少与代码一样来审查软件开发和团队实践。

• 解决符合既定编码标准的问题。对于审稿人和被审稿人来说，这是最令人讨厌的话题。当每个人都同意在您的团队中使用大写的班级名称而一个人没有班级时，这是不是有品味？还是团队合作的有效性和风险性？

顺便说一句，如果您认为不值得讨论编码标准，请将其从标准中删除，不要浪费时间和精力。

培养领导力：审查的人性化方面

作为团队负责人，您可能会在这里找到机会，发展自己和团队，而不仅仅是质量控制的形式：

• 如果能进行真正的交流，那么代码审查对于每个人来说都会更加愉快。让您的开发人员也有机会展示他们的技能（是的，也许您可​​以学习一些新知识）。
• 公开批评设计选择或现有标准。有时人们可以更好地应对这种挫败感，因为他们可以谈论它。
• 指导您的大三学生：不要犹豫，为下一次迭代提供建议或重构方向。不要对年长的人这样做：在另一个世界中，您各自的角色可能已经改变。

利用其他做法

在代码审查中可以避免两件事：

• 在同行评审之前很久，在您的构建链中使用静态代码分析器就可以自动发现常见的错误或不可移植的结构。有些工具甚至可以检查您的某些编码标准。
• 如果您有关于代码布局的标准，请使用预先提交的漂亮字体或类似的格式化程序来按要求自动格式化代码。永远不要花时间在软件可以为您做得更好的事情上，而无需讨论:-)
• 最后，质量不仅可以通过评审来保证，而且可以通过测试来保证。如果您尚未使用TDD，请独立于代码审查而思考。

作为开发人员，我们的思维定式应始终保持开放和怀疑。

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

由于我们（人类）在交流中很糟糕，请不要做出错误的假设，并愿意向代码所有者询问您正在检查的代码。如果他/她未能在公司的标准下对创意进行编码，则首席开发人员也愿意指导他/她。

这里是主观的方法。这个问题很好地解释了客观方法IMO 。

除了上面的链接，要实现的目标集（可维护性，可读性，可移植性，高内聚性，松散耦合性等）不一定是十诫。您（团队）应该能够将这些目标调整到质量和生产率之间的平衡，使工作变得舒适并且“适合开发人员”。

我建议根据这些目标使用静态代码分析工具来衡量质量的进度。诸如SonarQube之类的工具可以为我们提供质量门和质量配置文件，可以根据我们的优先级进行自定义。它还为我们提供了一个问题跟踪器，可以使开发人员针对与代码气味，错误，可疑做法等有关的问题。

这类工具可能是一个很好的起点，但是正如我所说，请保持怀疑态度。您可能会在Sonar中找到一些对您毫无意义的规则，因此可以随时忽略它们或将其从您的质量档案中删除。

干预开发人员的外观更改代码将使开发人员失去动力，但在绝对情况下必须这样做。铅已经找到提供之间的平衡有用的代码审查和学习放手的小小缺点。 https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

注意事项：

1. 它与技术一样关乎心理学，因此这里没有黄金法则。
2. 关于人的不仅是知识，还包括文化和等级制度中的地位。
3. 如果这是一场“漫长的”游戏（稳定而稳固的公司），那么人们相互信任的高度集成的团队通常比所审查的代码具有更高的价值。它不应用于强制执行并非绝对必要的事情。魔鬼在细节中...
4. 如果这是一个“简短”的游戏（副项目，研发，一群自由职业者），则CR的成本通常会克服因进行冒险而产生的冒险。态度应该是“让它入锅”

只有两件事很重要。

1. 是否有针对所有要求的自动化测试？
2. 他们都通过了吗？

其他所有东西都是化妆品，应该在啤酒上争论而不是强加于门。

如果您遵循这种观点，那么它将局限于一个狭窄的领域。

要求好吗？在开始任务之前，您应该了解哪些理想信息，即性能，安全性等都应该存在于其中

测试是好的测试吗？任何遗漏的边缘情况，它们是否可以很好地测试需求等。最终：您可以编写一个针对现有需求但会失败的测试吗？