如何使良好的代码审查更好

十多年来，我一直在进行日常代码审查。代码审查的好处是很多的：有人抽查您的工作是否有错误，他们可以从您的解决方案中学习，而协作有助于改善组织的整体工具和自动化方法。如果您当前不在组织中进行代码审查，请立即开始。这将使每个人都成为更好的工程师。

许多人和组织已经分享了他们的代码审查最佳实践，以及好的代码审查的定义对他们意味着什么。指南  由谷歌，  该SmartBear团队，和工程师菲利普·豪尔都是很棒的读物。下面是我个人对好的代码审查的外观以及如何使它们在团队和组织层面上变得更好的个人看法。这是在我一直在工作的技术环境的背景下进行的-目前在Uber，在此之前在Skype / Microsoft和Skyscanner。

良好的代码审查是我们所有人应努力追求的标准。它们涵盖了任何团队都可以开始使用的常见且易于遵循的最佳实践，同时确保了长期的高质量和有用的审核。

更好的代码审查工程师不断改进代码审查的方式。这些代码回顾着眼于代码库上下文中的代码更改，谁在请求它以及在什么情况下。这些审查会根据情况和情况调整其方法。目标不仅是高质量的审查，而且还帮助要求审查的开发人员和团队提高生产力。

守则审查涵盖的领域

好的代码审查人员应着眼于更改本身及其如何适应代码库。他们将通过标题和描述的清晰性以及更改的“原因”来进行了解。它们涵盖了代码的正确性，测试范围，功能更改，并确认它们遵循了编码指南和最佳实践。他们将指出明显的改进，例如难以理解的代码，不清楚的名称，注释掉的代码，未经测试的代码或未处理的边缘情况。他们还将指出何时将太多更改挤入了一次审阅，并建议保持代码更改为单一用途或将更改分为更集中的部分。

更好的代码审查查看大型系统中的更改，并检查更改是否易于维护。他们可能会问有关更改必要性或它如何影响系统其他部分的问题。他们研究引入的抽象以及它们如何适合现有的软件体系结构。他们注意到可维护性的观察，例如可以简化的复杂逻辑，改进测试结构，消除重复以及其他可能的改进。工程师Joel Kemp将出色的代码审查描述为在初次轻度通过之后进行的上下文传递。

评论的语气

代码审查的语气可以极大地影响团队内部的士气。苛刻的评论会因其微攻击性而给人以敌对环境的感觉。固执己见的语言可以使人们产生防御性，引发激烈的讨论。同时，专业而积极的基调可以为更具包容性的环境做出贡献。在这些环境中，人们愿意接受建设性的反馈意见，而代码审查则可以引发健康，活泼的讨论。

好的代码评论提出开放性问题，而不要发表有力或过分的陈述。他们提供了替代方案和可能的解决方法，它们可能会针对情况更好地工作，而无需坚持认为这些解决方案是最佳或唯一的解决方法。这些评论假定审稿人可能遗漏了一些东西，要求澄清而不是更正。

更好的代码审查也很有同感。他们知道编写代码的人在此更改上花费了很多时间和精力。这些代码审查是友善和张扬的。他们赞扬好的解决方案，并且是全面积极的。

批准与请求更改

审阅者完成审阅后，可以将其标记为已批准，可以通过更改请求阻止审阅，也可以不设置特定状态，而将其置于“尚未批准”状态。审阅者如何使用批准并请求更改状态说明了代码审阅。有开放式问题时，

良好的代码审阅不会批准更改。但是，它们可以清楚地指出哪些问题或评论没有阻碍性或不重要，从而将它们区别对待。批准更改时，它们是明确的，例如，添加诸如“看起来不错！”之类的赞许评论。有些地方使用首字母缩写词，例如LGTM-这些也可以，但是要注意，新来者可能会误解这些内部缩写词，以作其他用途。良好的代码审查要求通过代码审查工具或团队惯例对此进行跟进时，他们要求采取后续措施。

更好的代码审查原则上是坚定的，但实践上是灵活的：有时，某些注释由作者提出，并单独进行了后续代码更改。对于比其他人更紧迫的更改，审阅者尝试使自己可以更快地进行审阅。

从代码审查到彼此交谈

代码审查通常是异步进行的，并通过代码审查工具以书面形式进行。这通常出于方便目的，以实现远程代码审查，并允许多个人审查同一代码更改。但是何时该停止使用该工具（可能有多棒）并开始面对面讨论代码了？

良好的代码审阅会根据需要留下尽可能多的注释和问题。如果修订版本未解决所有问题，他们也会予以注意。当对话来回漫长时，审阅者将尝试切换为与作者面对面交谈，而不是使用代码审阅工具浪费更多时间。

更好的代码审查在他们第一次对代码进行传递并提出很多评论和问题后，将主动与进行更改的人员联系。这些人已经知道，他们通过这种方式节省了很多时间，误解和痛苦。在代码上有很多注释的事实表明，双方可能都存在一些误解。通过交谈，这些误解更容易识别和解决。

刺针

Nitpicks是无关紧要的注释，其中的代码可以合并甚至不解决这些问题。这些可能是诸如变量声明按字母顺序排列，遵循某种结构的单元测试或方括号在同一行。

良好的代码审查可以清楚地知道何时更改不重要。他们通常会在这些注释上添加明显的标记，并在它们的前面加上“ nit：”前缀。这些中的太多内容可能会令人沮丧，并使注意力从评论的更重要部分转移开来，因此审阅者的目标是不要太过重视这些评论。

更好的代码审查意识到太多的挑剔是缺乏工具或缺乏标准的标志。经常遇到这些问题的审阅者将在代码审阅过程之外寻求解决此问题的方法。例如，许多常见的nitpick注释都可以通过自动掉毛解决。那些通常无法解决的问题可以由团队同意某些标准并遵循它们来解决，甚至可能最终使它们自动化。

新加入者的代码审查

对于大多数人来说，从一家新公司入手是不知所措的。代码库是新的，编程风格与以前不同，人们对您的代码的查看也大不相同。因此，对于新手来说，代码审查应该更温和一些，以使它们适应新的环境，还是应该像其他所有人一样，对代码进行严格的审查？

良好的代码审阅对每个人都使用相同的质量标准和方法，无论他们的职称，级别或加入公司的时间如何。遵循以上内容，代码审阅会以一种友好的语气，在需要时请求更改，并在审阅者有很多评论时与他们进行交谈。

更好的代码审查还要特别注意使新加入者的前几条评论变得很棒。审阅者对新加入者可能不了解所有编码准则并且可能不熟悉部分代码这一事实感到同情。这些审查付出了更多的努力来解释替代方法并指出指南。它们的语气也非常积极，庆祝作者建议的对代码库的前几处更改。

跨办公室，跨时区评论

当审阅者不在同一位置时，代码审阅会变得更加困难。当审阅者坐在非常不同的时区时，它们尤其具有挑战性。多年来，我在这些评论中占有相当的份额，修改了美国和亚洲团队（同时位于欧洲）拥有的代码。

良好的代码审查会考虑时区差异。审核员旨在在办公室之间重叠的工作时间中审核代码。对于评论很多的评论，评论者将提供直接聊天或进行视频通话以讨论更改的信息。

更好的代码审查请注意，当代码审查反复遇到时区问题并在代码审查框架之外寻找系统解决方案时。假设来自欧洲的团队经常更改一项服务，该服务会触发来自该服务的美国所有者的代码审核。系统级的问题是为什么这些更改如此频繁地发生。更改是在正确的代码库中完成的，还是应该更改另一个系统？更改的频率是相同的还是随着时间推移而降低？假设更改是在正确的代码库中完成的，并且频率不会降低，跨办公室的依赖关系能否以某种方式被打破？解决这类问题的方法通常并不简单，可能涉及重构，创建新服务/接口或改进工具。

组织支持

公司及其工程组织处理代码审查的方式是提高效率的重要因素。认为它们不重要和琐碎的组织最终很少投入资金来简化审核。在这种文化中，完全放弃代码审查可能很诱人。提倡进行更好的代码审查的工程师可能会感到孤立，没有上级的支持，最终放弃了。结果是组织不断出现问题并不断加剧。 

具有良好代码审查的组织确保所有工程师都参与代码审查过程，甚至可能参与单独项目的那些人。他们鼓励提高质量标准，并且团队促进团队和组织级就代码审查方法进行健康的讨论。这些公司通常具有工程师发起和编写的针对较大代码库的代码审查指南。这样的组织认识到代码审查占用了工程师大量的时间。这些公司中的许多公司都将代码审查作为对开发人员工作能力的期望，期望高级工程师将大部分时间用于审查其他人的代码。

具有更好代码审查的组织在没有代码审查的情况下，没有代码的情况下就很难制定严格的规则-就像业务逻辑更改在没有自动化测试的情况下就不能使其投入生产一样。这些组织已经知道，偷工减料的代价是不值得的。相反，他们有紧急情况下的快速审查程序。这些组织投资于开发人员的生产力，包括不断努力开发更有效的代码审查和工具改进。乐于助人的工程主管无需说服代码审查和其他工程最佳实践的好处。相反，他们支持团队提出的有关更好工具或更有效代码审查流程的计划。  

当人们遇到令人怀有敌意的评论时，他们会说自己可以发表意见并获得全面支持以解决问题。高级工程师和经理认为，代码审查不像草率的代码或不良的行为那样严重。工程师和工程经理都感到有权改善代码审查的方式。

从良好开始，变得更好

好的代码评审已经投入了很多心血。他们对更改本身进行了彻底的审查，避免被评论的语气所束缚，并明确表示。无论谁要求进行审查，他们都保持一致的标准，并通过更加注意跨时区审查来减轻痛苦。具有良好评价的组织确保每个开发人员都定期收到并进行代码评价。这已经是一个很高的标准，但是如果您到达这里，请不要停止。代码审查是提高技能，指导他人并学习如何成为更有效的沟通者的最佳方法之一。 

获得更好的代码评论通过不断改进细节，同时也开始着眼于高层次的变化。对注释的语气保持同情心，并思考代码审查过程之外的方法以消除频繁出现的挑剔。使代码审查特别欢迎新手使用，并为痛苦的跨时区审查寻找系统的解决方案。具有前瞻性的组织鼓励在工具和流程改进方面进行投资，以使代码审查更好，从而获得更多收益。