内容简介：在日常写完代码之后，你是否会有 Code Review 的习惯？Code Review 即代码审查，其目的在于找到开发时被忽视的 Bug，以此极大地提高代码质量也可以帮助开发者们更加熟悉项目。但遗憾的是，很多业界的开发者并没有常规代码审查的习惯。那么对于程序员而言，Review 是否真的是一项必备的工作？
在日常写完代码之后，你是否会有 Code Review 的习惯？
Code Review 即代码审查，其目的在于找到开发时被忽视的 Bug，以此极大地提高代码质量也可以帮助开发者们更加熟悉项目。但遗憾的是，很多业界的开发者并没有常规代码审查的习惯。那么对于 程序员 而言，Review 是否真的是一项必备的工作？
作者 | Gergely Orosz
译者 | 弯月，责编 | 屠敏
出品 | CSDN（ID：CSDNnews）
以下为译文：
十多年来，我常常担任代码审查的工作。代码审查的好处很多：从其他人的角度阅读代码变更、知识共享以及 工具 和自动化改进。如果你们没有代码审查，那么我强烈建议你遵从Jeff Atwood于2006年分享的这项建议（https://twitter.com/codinghorror）。
许多人和组织分享了有关代码审查的最佳实践，以及良好的代码审查的意义。SmartBear团队、Palantir工程团队和工程师Philipp Hauer分享的指南都是很好的阅读材料。以下是我个人对良好的代码审查的看法，以及怎样才能做到更好。本文的背景是我工作中的技术环境，包括现在我所在的Uber，以及以前微软的Skype和Skyscanner。
代码审查所涵盖的领域
良好的代码审查人员会查看代码本身的变更 ， 以及这些变更是否适合已有代码。 他们会仔细研究标题和描述，以及代码变更的“原因”。他们还会检查代码的正确性、测试覆盖率、功能变更并确认是否遵循了编程指南和最佳实践。同时，他们还会指出明显有待改进的地方，例如难以理解的代码、含混的名称、注释掉的代码、未经测试的代码或未处理的边缘情况。最后，他们还会注意，如果一次提交包含了太多代码变更的话，则建议代码的变更应该保持单一目的性，并将代码变更分解成目标更为集中的几部分。
更优秀的代码审查人员还会从系统整体的角度查看代码变更 ，并检查这些变更是否易于维护。 他们可能会询问代码变更的必要性，或对系统其他部分造成的影响。他们会研究代码中引入的抽象以及与现有的软件架构的适应性。此外，他们还会观察可维护性，例如是否可以简化的复杂逻辑、测试结构、重复和其他可能的改进。工程师Joel Kemp在这篇文章中（https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36），将这些代码审查划分成了两个级别：初步审查与全面的审查。
审查的基调
代码审查的基调可以极大地影响团队内部的士气。刺耳的评论可能会导致恶劣的工作环境。自以为是的语言可能会让人们感受到敌对，从而引发激烈的争论。同时，专业且积极的语气可以培养更包容的环境。这些环境中的人们可以接受建设性的反馈，而且代码审查会引发健康和热烈的讨论。
良好的代码审查人员会提出开放式的问题，而不是发表强烈或自以为是的陈述。 他们会提供替代方案或其他解决方法。这些审查人员会认为自己可能遗漏了某些内容，因此他们首先会要求对方澄清，而不是要求对方改正。
更优秀的代码审查人员富有同情心。 他们知道编写代码的人花了很多时间和精力来应对这些变化。这些代码审查人员善良且不张扬。他们会大力赞赏良好的解决方案，并采取全面积极的行动。
批准与请求变更
良好的代码审查人员不会在有开放式问题的时候批准代码更改。 但是，他们会明确指出哪些问题或评论没有造成阻塞或不重要，通常这样的审核意见被称为“挑剔”。他们只在变更非常明确的情况下批准变更（例如，注明“在我看来很好”）。当需要跟进时，他们同样会明确地使用代码审查工具或按照团队的习惯进行沟通。
更优秀的代码审查人员在面临需要回答某些问题或解决重要问题之前，也不会批准代码更改。 这种审核在原则上是坚定的，但在实践上却是灵活的：有时，写代码的人会在后续代码变更中单独解决审核指摘的问题。有些更改比较紧急，所以审查人员会尽快地推动审查。
从代码审查到彼此交谈
良好的代码审查人员会尽可能地留下评论和问题。 如果经过修改后仍然有残留问题，他们也会记录下来。如果来回的评论过多，那么审核人员会舍弃过于耗时的工具，而选择面对面交谈。
更优秀的代码审查人员在第一次审核完毕，但有很多评论和问题时，会主动联系写代码的人。 他们知道与其在评论中来回反复，还不如面对面的交谈，因为这种方式可以节省大量的时间，还可以省却不少误解和麻烦。很多针对代码的评论表明，审查双方往往会存在一些误解。彼此的交谈更容易消除误解。
吹毛求疵
如前所述，良好的代码审查人员会清楚地表明哪些评论不重要，或有点挑剔。这方面的审查问题包括变量声明按字母顺序排列、测试结构遵循某个结构或括号位于同一行或下一行。
通常，良好的代码审查人员不会有太多的挑剔。 鸡蛋里挑骨头会打击人的积极性，而且也会让大家丧失对重要问题的关注。
更优秀的代码审查人员明白太多的挑剔意味着缺乏工具或缺乏标准。 经常遇到这些问题的审核人员会考虑在代码审查流程之外解决这个问题。 例如，大多数常见的挑剔都可以通过自动linting来解决。如果无法通过工具解决，则应该由团队协商采用某些标准来解决，然后继续跟进这个问题，甚至可以自动化。
新加入代码审查的人
良好的代码审查人员会一视同仁，采用相同的质量标准和方法，无论他们的职位，级别以及加入公司的长短 。根据上述内容，通常代码审查人员都会很和善，只在有必要的时候请求变更，并在收到许多意见时与他们进行交谈。
更优秀的代码审查人员更加注重给新加入的人留下一个好印象。 审查人员明白新来的人可能不了解所有的编程指南，而且也可能不熟悉代码的某些部分。所以，他们会进一步努力解释替代方案，或建议他们阅读编程指南。他们还会使用非常积极的语气，鼓励写代码的人刚开始提交的代码变更。
跨办公室及跨时区审查
如果写代码的人和审查人员不在同一个地点时，代码审查会变得更困难。当审核人员位于不同的时区时，这种难度就会更高。多年来，我力争公平地审查所有代码，无论是美国、亚洲还是欧洲团队所提交的代码。
良好的代码审查人员会尽可能地考虑时区差异。 审查人员都会努力在双方都办公的时间内审查代码。如果遇到很多评论的情况，则会选择直接聊天或进行视频通话。
更优秀的代码审查人员在反复遇到时区问题时，就会努力寻找代码审查框架之外的系统解决方案。 假设某个欧洲的团队经常更改某项服务，而代码审查则由美国负责这项服务的人来进行。系统级的问题是，这些变化如此频繁发生的原因是什么？随着时间的推移，变化的频率相同还是下降了？假设代码变更是在正确的代码库中完成的，且频率没有下降，那么是否应该打破这种跨部门的依赖性？解决这些问题往往不简单，可能涉及重构，或者创建新的服务/接口，或改进工具。解除这种依赖关系会让两个团队都更加轻松，更有效地推动工作。
组织的支持
公司及其工程组织如何看待代码审查是影响代码审查的重要因素。如果组织认为代码审查无关紧要或微不足道，就不会在这方面投入太多。在这样的文化中，在某些情况下，开发人员将不得不放弃代码审查。倡导实施更好的代码审查的工程师可能会感到孤立，而且也无法获得获得上述支持，最终放弃。如果组织认为代码审查是工程中的关键部分，那么他们就会为工程师提供更好的工作环境。
拥有良好代码审查的组织会确保所有工程师都参与代码审查流程，包括那些单独在某个项目上工作的人员。 他们鼓励提高质量标准。这些团队会积极地讨论从团队和组织层面开展代码审查。通常，这些公司都有工程师发起和编写的大型代码库的代码审查指南。这样的组织中，理解代码审查会占用工程师的很多时间。许多这样的公司在招聘开发人员时，也会将代码审查作为一项重要的工作能力，并希望高级工程师花费更多的时间来审查其他人的代码。
拥有更好的代码审查的组织会建立硬性规则：没有经过代码审查的代码不能投入到生产中，就像没有经过自动化测试的业务逻辑更改不能进入生产环境一样。 这些组织明白，削减这样的成本根本不值得，相反他们拥有在紧急情况下，加快审查团队和组织代码审查的流程。这些组织会投资提高开发人员的工作效率，其中包括更有效的代码审查和工具改进。这些公司的高管通常都是软件工程师，你不需要说服他们有关代码审查和其他工程最佳实践的好处。相反，他们支持团队利用更好的工具，或更有效的代码审查流程。
当写代码的人感受到恶意的评论时，他们可以说出来并全力支持解决问题。高级工程师和管理人员认为不达标的代码评审与劣质的代码或不健全的功能同等严重。工程师和工程经理都感觉有责任改进代码审查的开展方式。
原文：https://blog.pragmaticengineer.com/good-code-reviews-better-code-reviews/
作者：Gergely Orosz，软件工程师，主要从事移动、Web和后台开发。
本文为 CSDN 翻译，转载请注明来源出处。
【End】
热 文推 荐
☞马化腾评 Facebook 加密货币；苹果或将 15% 产能移出中国；Python 新版发布 | 极客头条
☞第二! 他排中本聪与V神中间, 单靠文字就“打败”了敲代码的程序员!
点击阅读原文，即享优惠购票！
你点的每个“在看”，我都认真当成了喜欢
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
