译作。对原文做核心理念的意译。
LinkedIn 针对高效代码评审的几条建议
Preface
LinkedIn 刚刚完成了百万行代码审查的里程碑式的工程。其团队负责开发工具（效率）的领导将为大家分享一路的收获。
在每个工程师日常工作中，阅读以及审查代码是大家一直在做的事。但作为正式环节的一部分，则会有所不同：它要求每个代码变更都要在上线前被另一个团队成员进行正式复审。而在领英，从2011年起，代码审查就成为了强制的一个环节。他们相信，做好了代码审查，有助于提升整个团队的工程能力。分开来讲，首先可以保证编码质量，其次可以互相之间做知识共享。除此，做好代码评审也从方方面面改善了他们的工程文化。
Szczepan Faber 从2015年起，Szczepan Faber 就作为领英开发工具组的领导，这个团队为提升工程效率负责。2011年到2015年期间，他是 Gradle 1.x-2.x版本的核心工程师。在2007年，他创建了 Mockito 这个 Java 框架，预估有两百万的用户量。
在公司级别实行审查，最大的好处就是提高了开发工作流的标准性。领英的所有团队使用同样的工具、方式进行代码审查，这避免了诸如”我可以修复这个问题，但我不知道如何上手“之类的问题。工作流做了标准化，也间接提高了不同小组间的合作效率。
作为强制要求，在公司内，领英也建立了良好的反馈分为：团队欢迎每位工程师给予反馈，不仅限于代码。工程师将代码审查视为提升专业度的一个机会，而非消极的互相批评。事实上，高质量的代码审查已经成为了领英内部晋升的一大依据，这本身就佐证了工程师的工程能力。
Questions & Tips
经过多年演变，领英总结出了一些最佳实践。像下面这样，多问自己一些问题，就可以挖掘出代码评审的价值。
我真的理解为什么吗？
为了做好评审，每个提交都应该包含一个概要设计，以此说明编码变更的意图。在提交代码后，提交者也有义务来解释自己的动机。进一步，这也会促使提交者在commit message中规范化，进一步规范了编码文档。
我在做正向反馈吗？
工程团队往往充满了聪明的伙伴，大家都认为简洁的编码以及精干的测试覆盖率是理所应当的。这带来一个问题：每个人都专注于寻找你的问题。继而导致：问题背后的作者一定是被打击的。但实际上每个人都需要被鼓励，以此来提高团队战斗力，并且鼓励具有传播的作用。所以，领英鼓励，好的地方也有明确用书面语表达出来。
我的代码评审的注释写得够明确吗？
不管反馈是正面还是负面，对应的注释都应该是能自我解释的。当你反馈的信息不够明确时，代码作者也会有所疑惑（这里到底哪里写得不够好？），对于评审的注释、反馈，宁可多写，也不要写得过于简陋。
我尊重提交者的工作成果吗？
辛勤的工作永远值得大家尊敬（不管产出如何）。这一点有利于培养健壮、士气高的团队。有些编码存在问题较多，可能需要返工，这种情况下，我们仍然要尊重、认同作者的投入。作为反馈，我们可以给予提交者得体的说明：
- 指出做得好的地方
- 说句谢谢
评审注释对我有帮助吗？
多问一句这个问题，有利于辨明反馈是否有必要。我们应该视代码审查为有帮助的开发流程，而非冗余的无用功。如果觉得此处无用，那就直接移除。一个典型的无用评审案例就是编码风格规范。代码风格规范应该使用自动化工具进行强化推广，而非工程师。
测试完备够充足吗？
在领英团队，每个代码变更的提交都强制要修测试完备。比如使用 GitHub 为例，在每个 Pull Request 的描述中必须附带testing done的字样。而这个完备程度取决于每次变更的严重程度。如果变更包含了新的、变动的条件复杂性，那在单测中就应该覆盖。如果集成测试不够完备，那就需要人肉测试。在上面说到的案例中，testing done就应该包含测试前置情况、产出。
我是否在评审时过于深究细节？
有些评审注释过多，以至于把真正需要修复的问题给覆盖了。评审过于深究不要紧的细节会拖慢评审进度，并且给评审双方增加合作阻力。大家有共同的评审目标、正面例子、以及积极的评审文化，可以有效避免冗余、耗费精力的问题。
## Summary 将代码审查引入为工作流程有助于提高编码质量、知识共享度。当工程师意识到有人要阅读我的代码时，则会更加谨慎，也就会在首次提交时就做到最好（节约后续返工成本）。日常工作中经常收到反馈时，代码的精进也就成为一个习惯。
在领英，从百万行级别的代码评审中我们学到了很多，在以后更多的评审中，我们也渴望学到更多。编码质量越高，我们所创作的产品质量也就越高。高质量的评审是传播性的。