在知名IT公司里，我认为代码审核应该是强制的工程流程了。一般人是不会有权限不经过代码审核流程而完成代码修改并上线的。
比如，在Cortana组的任何一个代码库修改代码，我是无法在master分支上直接提交更改的（push commit），我得发PR（pull request），然后找人审核。而且，重要的代码库一般有更严格的审核规范，比如得参加一些培训才能给有效的approval，部分重要的代码还需要经过特定的一小部分人的审核，等。
2016年左右，微软要求所有研发部门将代码库都移植到Git上，即现在Azure DevOps的Repos。Azure DevOps的Repos，可简单理解成Azure DevOps内置的GitHub。在这一年，Cortana的代码从古老的source depot移植到了Git，从此生产力达到了大大的提高。也许微软的员工都比较喜欢这现代化的代码版本管理工具，两年后微软收购了Github。
微软内部的代码审核工具codeflow倒是一直延用至今。现在对于改动少的PR，我习惯直接在网页上做审核；代码改动多的话程序员应该知道的97件事，codeflow的确更方便一些。
虽然代码审核已经成为现代工程习惯，但是这个观点的原文并没有深入地思考为什么我们还要做代码审核。 或者，为什么还需要有人亲自审核代码？
在说到代码审核的时候，一般说的都是人工的代码审核。但是，我不认为这是代码审核的全部。
从代码审核的目的看，自动化的代码规范检测、代码构建和代码测试，应该都属于广义上代码审核的一部分。它们都是在审核代码是否正确和符合质量要求；而且，它们是基于优秀的软件工程师在工程实践中的积累的知识和经验去实现的机器逻辑。
通过人为的代码审核去分享知识和建立共同的编码实践规范，这点没错；但如果我们要做的更好，应该要多去思考为什么这些好的审核建议不能成为作为自动化审核的一部分。当我们过于依赖团队里某一位资深的工程师给审核意见的时候，这往往意味着他们是代码审核效率的瓶颈。这类拥有着极高技术权威的人往往也很忙；当代码变更频率需求很大的时候，要不为了效率牺牲审核效率，要不为了质量而牺牲研发效率，或者他们根本没预留足够的时间去审核需要他们审核的代码改动。
我是很反感那些只有几个人的approver组的，尤其当他们并没有承诺会及时审核的时候。这时候你只能和其中一两位打好关系，方便需要的时候能够及时得到审核。
即使做好了自动化代码审核，我们很可能还是需要人工的代码审核，因为有很多良好的设计和实践经验还无法自动化，尤其是业务领域相关的设计细节。我们程序员应该为此感到庆幸，否则我们就容易被机器取代了。在一些古老的IT故事里，IBM就比较喜欢做那些将专家经验自动化生成代码实现的工具，恨不得画个图就能生成可执行程序。幸好他们没有成功。
当然，编码应该是一个创造性的过程，所以人工的代码审核还是很有必要的。
编码是一种创造性的过程，而非机械式的过程。—— #12 编码是设计 （Code Is Design）
但是，为了持续提高生产力，我们还是应该努力将常见的审核经验和实践指南实现成自动化代码审核的一部分，然后省下时间给更多重要的创造性的工作。比如，我见过一些代码审核特别细致的同事，他们经常发现注释里的语法错误和单词拼写错误；我不认为这类审核意见没意义，但如果有办法能自动化检测和修正注释里的语法错误，大家就能省下时间去关注其他方面的审核。
有一次，一位同事将一个小文件里的copyright写成其他公司了。一位眼力劲超强的发现了留了一个comment，问他是不是忘记自己在哪家公司了。如果自动化代码检测能发现这个问题，那同事就不会犯这个尴尬的错误了。不过，真做到这么细，这种工作中的小乐趣可能也会大幅度减少。
由于我们还是需要人工的代码审核，所以我们应该培养良好的代码审核习惯。
以下是我的一些小建议。
对于提交代码审核的人，
清楚谁应该审核你的代码，而且明确对方也这样想。明确审核者有足够的信息审核你的代码，比如确保他了解甚至审核过设计，等。如果审核者对你的改动的需求和设计一无所知，往往他们也无法给出有效的审核。确认审核者会在你预期的时间之内完成审核。我见过不少人提交了代码审核就不跟进了，默默地等待代码被审核程序员应该知道的97件事，然后几天就过去了才发现对方还没开始。注意，这是你的代码审核，你应该对审核进度负责，所以你需要更主动地和审核者沟通审核的进展。不要抱有一次审核就能通过的幻想。预期明天就要提交的代码，别等到今天甚至当天才开始审核。这样做的话，为了完成工期，你要不给审核者施加压力损害审核质量，要不你给自己压力赶工修改损害代码质量。代码更改越多，你便要预期代码审核需要的轮数会越多。
对于审核代码的人，
及时审核是美德。如果你希望代码审核能及时被审核，那么你得先做好这一点。确认你理解了设计再去审核代码实现。设计就好比代码的蓝图。没有蓝图地去审核，你无法判断代码的更改是否实现了所有的逻辑和正确的逻辑；你大多只能审核出一些代码规范相关的小毛病，而无法深入审核业务领域的关键逻辑是否有问题。当你有意见并留下了评论，至少要将审核状态设成等待以告知对方你做了审核并留了意见；我建议再给作者发个消息。虽然更改状态会发通知（比如邮件），但是顺手留个言告知对方并不是那么麻烦的事情，却极大地改善了审核效率，还能够给对方一个好的印象。下次你需要对方审核的时候，可能会更高效一些。
最后，祝耐心看完这篇文章的人都能够及时完成代码审核。
本系列之前的文章
#1 谨慎行事 (Act with Prudence)
#2 应用函数式编程的原则 (Apply Functional Programming Principles)
#3 问“用户会做什么？”（你并不是用户）Ask “What Would the User Do?” (You Are not the User)
#4 自动化执行你的编码规范（Automate Your Coding Standard）
#5 美在简单 (Beauty Is in Simplicity)
#6 在你重构之前 (Before You Refactor)
#7 当心共享的诱惑 （Beware the Share）
#8 童子军规则 （The Boy Scout Rule）
#9 在责备其他之前，先检查你的代码 (Check Your Code First before Looking to Blame Others)
#10 谨慎选择你的工具 （Choose Your Tools with Care）
#11 使用领域语言去编程（Code in the Language ofthe Domain）
#12 编码是设计 （Code Is Design）
#13 代码布局很重要 (Code Layout Matter)
注册会员查看全部内容……
限时特惠本站每日持续更新海量各大内部创业教程，年会员只要98元，全站资源免费下载
点击查看详情
站长微信：9200327
