代码审查（CodeReview）是很多大公司的流程。它指的是一个人编码，其他几个人审查并提出更改建议。在大多数情况下，codereview可以提高公司整体的工程质量，但如果使用不当，很可能会降低工程质量。代码审查对组织的影响是积极的还是消极的取决于很多因素，我认为其中最重要的是代码审查在开发过程中所扮演的角色。首先，让我们看看需要在代码审查中发现的问题类型。它们可以是：语法和代码风格问题：一般静态检查工具可以解决，但难免有遗漏。效率问题：需要有一定经验的人来识别效率低下的部分。命名问题：这其实是一个非常频繁和重要的问题。对一个人有意义的命名可能对团队没有意义，所以很多情况下困难的命名需要团队通过代码审查来解决。设计问题：从接口设计到服务之间的通信协议，都属于设计问题，可以根据情况由一小部分人或整个团队来解决。设计问题是代码审查中最常见的问题。前三个问题相对容易解决。比较难的是效率问题，但其实基本上知道效率问题的人都知道优化方案。但是，如果审稿人突然提出一个非常合理的设计问题，需要你返工源代码，你会发现你需要花很多时间来重写。例如，在编写JavaScript库packageA时，您将其提交进行代码审查。可能有人提醒你：packageA是桌面网站的库，有对应的移动端库packageB。为了保持项目的一致性，建议将packageA改成和packageB一样的API。一致性一直是无可辩驳的设计追求，所以你辛辛苦苦设计的所有API都要重写……因此，如果你的代码出现设计问题，消耗的工程时间就会增加。工程时间就是公司的金钱。设计问题需要大改的原因其实有3个：设计能力不足对开发的系统不熟悉，缺乏上下文（Context）codereview来不及前两个原因很直白，但是第三个原因就有点不可思议了什么是延迟提交代码审查？我认为是代码审查的英文单词中的“Review”具有误导性。很多人在代码快写完或者已经写完之后才提交codereview。就好比做一道菜，走到第一步的时候，记得咬一小口看看味道对不对，结果发现没有放盐。在codereview的最后一步，因为reviewer一下子收到的信息太多，可能会发现一些应该发现的问题。显然，这里的“审阅”角色是有问题的。它不应该是传统意义上最后一步的检查，而是贯穿整个编码过程的一个辅助过程。用老套的软件工程“本地语言”来说，应该是一个UmbrellaActivity（保护伞活动），它全程保护编码过程的质量。现在，我的codereview流程是这样的：先完成一个基础设计，加上基础注释，达到一个完成度——最容易出现重大设计问题的完成度。然后commit，并push到codereview，邀请其他人review。它基本上是在对他们说，“看，这是我写的，很简单，它可能像一坨屎一样烂，请帮我看看它是否有问题”。稍有一点开发经验的人都可以大致估计手头的工作可能在哪一步导致重大的设计问题。比如你在设计一个新模块的时候，可能出现大设计问题的时候可能就是在设计API的时候。紧接着，下一个可能出现的大设计问题就是类之间的抽象关系等等。我什至给自己代码审查。这不是在做计算，而是把自己的疑惑告诉团队，通过codereview提出自己的想法，让大家更好的和你交流。相信我，把你有疑虑和犹豫的地方提出来；指出你有自己独特想法的地方，因为你独特的想法有时对团队来说是坏主意。每当你遇到一个你认为可能出现的大设计问题时，尽量使用代码审查，让团队与你一起解决。对于工程经验不多的人（比如我）来说，应该多做这种事情。这样做一开始可能会花费更多人的时间，但一段时间后，您会更有信心做出好的设计决策。换句话说，减少了出现大设计问题的可能性。因为在与他人交流的过程中，你总能学到新的东西。但是，如果每次编码完成后都进行代码审查，即使代码审查后可能会产生高质量的代码，您也会将大部分时间花在无聊上，而真正编码的时间很少。欣赏他人意见的真正价值。从长远来看，可以显着减少整个工程团队的工程时间。第一个是因为大家的经验可以通过codereview增长得更快，所以整体的工程效率会提高；二是因为完全受保护的代码审查可以解决（或缓解）各个层面的设计问题，让工程人员在短期和长期内花费更少的工程时间，减少技术债务。幸运的是，虽然这里说的是一个比较宏观的流程问题，但是是每个工程师去落实的事情。也就是说，代码审查的执行方式最终取决于编码的工程师个人。整个流程的改造不需要添加新的工具，也不需要很多复杂的文档。所需要的只是团队的培训课程——而这篇文章可能是这方面的一个很好的来源。
