为什么代码评审（ code reviews ）很重要

剧透警告：如果你喜欢合理的架构决策，而讨厌成为“关键路径”开发者（"critical path" developer ），你会喜欢上代码评审的。

敏捷团队是自组织的，拥有跨越团队的技能集。这在一定程度上是通过代码评审实现的。代码评审可以帮助开发人员学习代码库，并帮助他们学习新的技术，从而提高他们的技能。

「CODING 企业版」作为企业级软件研发管理系统，助力团队敏捷开发转型升级。

那么，到底什么是代码评审（ code reviews ）呢？

当开发人员完成一项工作时，另一个开发人员会查看代码并考虑如下问题：

• 在代码中是否存在明显的逻辑错误？
• 查看需求，是否所有用例都实现了？
• 新的自动化测试是否足以满足新代码？
• 是否需要重新编写现有的自动化测试用例来应对代码的变化？
• 新代码是否符合现有的开发规范？

代码评审应该与团队的现有流程集成。例如，如果一个团队正在使用任务分支工作流，那么在所有代码编写完成并通过自动化测试之后，在代码合并之前，就会启动代码评审。这确保了代码评审人员的时间被用来检查机器遗漏的东西，并防止糟糕的编码决策污染开发主线。

代码评审对于敏捷团队来说有什么作用呢？

无论开发方法如何，每个团队都可以从代码评审中获益，敏捷团队更是能获得巨大的好处。因为团队的工作是分散的，通过代码评审可以做到没有人是唯一知道代码库特定部分的人。简单地说，代码评审有助于促进跨代码库和整个团队的知识共享。

代码评审共享知识

所有敏捷团队的核心都是战无不胜的灵活性：一种将工作从待办事项列表中划掉并由所有团队成员开始执行的能力。因此，团队能够更好地围绕新工作进行展开，没有人是“关键路径”。全栈工程师可以处理前端工作和服务器端工作。 随着代码评审使开发人员接触到新的想法和技术，他们会编写出更好的代码。

通过代码评审可以更好的进行工作评估

还记得评估的那一节吗？评估是一项团队练习，当产品知识在团队中传播时，团队会做出更好的评估。随着新特性被添加到现有代码中，原开发人员可以提供良好的反馈和评估。此外，任何代码评审人员也会综合考虑代码库的复杂性、已知的关注的问题。通过这种方式代码评审员分享了代码库中那个部分的原开发人员的知识。这种实践使得产品知识有多人了解，当大家做最终评估时，通常会使评估更加可靠。

代码评审能让你享受休假

没有人喜欢成为一段代码的唯一联系人。同样地，没有人愿意钻研不是他自己写的关键代码——尤其是在生产环境有紧急情况发生时。代码评审在整个团队中共享知识，这样任何团队成员都可以接管并继续领航这艘大船。（我们喜欢在 Atlassian 进行这样的比喻！）但这里的重点是：没有任何一个开发人员是关键路径，这也意味着团队成员可以根据需要休假。如果你发现自己在产品开发中忙的焦头烂额时，代码评审是一种很好的方式让你获得自由。自由地去享受个假期，或者自由地去看看产品其他领域的事情。

通过代码评审指导新工程师

敏捷开发的一个特点是当新成员加入团队时，经验丰富的工程师会指导新成员。代码评审有助于促进关于代码库的沟通。通常，团队在代码评审期间的代码中隐藏了产品知识。新成员带着新鲜的眼光，从新视角来审查代码库的粗糙之处和历史遗留缺陷的地方。因此，代码评审也有助于确保新见解与现有知识相调和。

专业提示：请记住，代码评审不仅仅是高级团队成员评审初级团队成员的代码。代码评审应该在各个方向上进行。知识是没有界限的！代码评审可以帮助新加入的工程师，但绝不应该仅仅作为一种指导练习。

在“上古”时代，代码作者在开始 Code Review 前，还需要手动做一份变更列表（ changelist ），来告诉评审者这一次提交做了什么改动。得益于 Git 的诞生，今天的我们可以借助基于 Git 版本控制系统的平台，来更轻松无痛地开展代码审阅，比如「CODING 企业版」，作为企业级软件研发管理系统，其提供的 Code Review 功能简单好用，能大大提高代码审阅效率：

借助 Git 自动实现精细的文件改动，红色代表删减，绿色代表新增，支持行级评论，再也不用在不同工位间来回走动，直接在具体代码下进行交流。

长远来看，代码评审可以节省时间

代码评审确实有点耗时，但是“做评审所花费的时间”不会比“不做评审所浪费的时间”多到哪里去。 只要执行得好，从长远来看，代码评审是可以节省团队时间的。原因有如下三点：

1. 代码评审可以分担任务负担

很多 Atlassian 的团队，需要对任何代码进行双重评审才能合并到代码库上去。听起来是不是有点额外增加工作负担了？但实际上不会。当代码作者递交评审时，是递交给整个团队的。任何工程师都可以加入评审。这使得任务负担可以被分担，从而可以防止“一项工作耽搁影响总体进度”的情况发生。也可以保证团队代码评审的质量。

1. 代码评审可以把软件 bug 扼杀在摇篮里

把代码评审作为提交代码前的必要工序去执行，可以让很多问题（例如熬夜做了不靠谱的架构决策、实习生用了不合理的设计模式）在软件最终发布前就被发现。

1. 代码评审可以提高工作质量

当一个工程师知道自己的代码会被同事审阅时，他会倾向于付出更多努力来让自己的程序设计变得足够优雅、让自己的代码能顺利通过全部测试。工程师们有了这个上进意识，最终也可以让整个项目变得更加顺畅、有效。

在开发周期里，如果急着得到反馈，那就不要等代码评审给出意见。提前得到反馈，往往会产出更好的代码。因此，无论何时，都不要羞于让别人提意见。这会提高你后续的工作质量，也会提高整个团队的代码评审能力。从而让开发团队进入正循环。

「CODING 企业版」作为企业级软件研发管理系统，任务看板功能实现了 Epic \ user stories \ Sprint 等敏捷概念落地。

本文中文翻译自原文：Why code reviews matter (and actually save time!) 编译者：程景天。