琦彦责编
欧阳姝黎出品
CSDN博客
不做codereview基本山就是背着定时炸弹前进：什么时候炸了都不知道。
现在不做，将来就是救火队员。
好的codereview会减少大量的不确定的坑：这个就像我们日常出门上班会确定门是否关好一样
代码审查的流程
先来简单介绍一下常见的代码审查的流程。为了开发某个新特性，或者修复某个特定问题，负责的程序员会从代码库的主分支（masterbranch）上面建立并checkout一个新的分支，将工作分为一次到若干次的“代码变更”来提交。这每一次的代码变更，都可以组成一次代码审查的单元，有的公司把它叫做CR（CodeChange），有的叫做PR（PullRequest），还有的叫做CL（ChangeList），但无论叫做什么，它一般至少包含这么几项内容：
帮助理解代码的描述，如果有问题单（任务）来跟踪，需要包括相关的问题单号或者问题单链接；
实际的代码变更主体，包括实际的代码和配置；
测试和结果，根据项目的情况，它可以具备不同形式，比如单元测试代码，以及手工测试等其它测试执行的结果说明。
多数情况下，以上这三项都不可或缺，缺少任何一项都会让代码变更失去一定可审查的价值。
进行审查的，一般是一起工作的，对代码涉及变更熟悉的其他程序员。这个“熟悉”，既包括业务，也包括技术，二者当中，有一项不具备，就很难做好审查工作，给出有建设性的审查意见。
接下去的交互就在这个代码变更上面了，审查者会提出其问题和建议，变更的作者会选择性采纳并改进变更的描述、代码主体以及测试。双方思考、争辩，以及妥协，目的都是寻求一个切合实际且可以改进代码质量的平衡。
如果审查的程序员觉得代码没有太多问题，就会盖上一个“Approved”或者“Shipped”戳，表示认可和通过。这根据项目而定，一般代码变更最少要得到1~3个这样的认可，才可以将代码变更合并（merge）到主分支。而主分支的代码，会随着CI/CD的流程进入自动化的测试程序，并部署上线。
代码审查的争议
在介绍代码审查的好处之前，我想先来谈谈争议。因为我观察到大多数的争议，都不是在否认代码审查的好处，而是聚焦在不进行代码审查的那些“原因”或者“借口”上，而有些讽刺的是，我认为这里面大部分的“原因”，所代表着的因果关系并不成立。
加班要累死了，完成项目都来不及，还做什么代码审查？
类似的问题还有，“代码审查拖慢了进度”，“代码审查不利于快速上线”。这是最常见的不做代码审查，或者草草进行代码审查的理由了，但是稍稍一细想，就会发现这里的因果逻辑完全不对。
这就像以前国内大兴“敏捷”的时候，有好多程序员，甚至项目经理，觉得因为项目时间紧才要实施敏捷，因为可以少写文档，少做测试，随意变更需求，可这里的因为所以根本是牛头不对马嘴。我记得知乎上有句流行的话叫做，“先问是不是，再问为什么”，这里也可以用，因为项目压力大就让“不做代码审查”来承担后果，这实在是过于牵强了。
项目压力大，时间紧，可以草草做分析，不做设计，直接编码，不做重构、不做测试、不做审查，直接上线，快及一时，可是造成的损失，最后总是要有谁来背锅的。这个锅很可能，就是上线后无尽的问题，就是恶性循环加班加点地改问题，就是代码一个版本比一个版本烂。当这些问题都焦头烂额，就更不要说团队和程序员的成长了。
代码审查太费时间，改来改去无非是一些格式、注释、命名之类不痛不痒的问题。
这也是个逻辑不通的论述，虽然这个还比前面那个稍微好一点。只能提出这些“次要问题”，很可能是代码审查的能力不够，而并非代码审查没有价值；或者是代码审查的力度不够，只能提出一些浅表的问题，这个现象其实更为普遍。
前面已经介绍过了，一是技术，二是业务，二者缺一都无法做出比较好的审查。在某些特殊情况下，有时候确实不具备完备的代码审查条件，我们现在来分业务、技术欠缺的情况进行讨论。
如果团队中有业务达人，但是技术能力不足。比如说，新版本使用的是Scala来实现的，但是团队中没有精通Scala的程序员，这个时候可以寻找其它团队有Scala经验的程序员来重点进行技术层面的代码审查，而自己团队则主要