最近一直在想如何提高产品质量的方法，其中最重要的一点就是要真正做好“代码审核”，而不是浮于便面只是为完成公司的流程制度，在这点上不仅我自己要做好，要让整个团队也能做好，要让大家真正通过代码审核这个活动提升自己，帮助别人。站在当前的角度在为提升团队代码审核效果要加强宣贯代码审核的重要性意义，已有的规范工具方法，团队成员达成共识。毕竟人才是首要问题，要大家齐心协力才能做好。下面这篇文章感觉很不错从自身不同的角色成长描述了对代审核的看法，其中穿插了一些不错的方法，分享一下。

“code review”已经是很多公司的常规实践，初看上去好像是浪费时间，降低工作效率，其实反之，好处大家有目共睹。它能检查代码的正确性，合理性，安全性，发现隐秘的bugs，让系统更可靠的运行。它能保证代码能有两个或以上的人熟悉，促进知识共享。它能让团队成员互为备份，互相支持，不会有SPOF。它能威慑埋雷的任何想法，杜绝邪念。它能互相学习好的代码，提高编程技能。等等。

从毕业开始工作到现在，我对“code review”的认识也越来越深刻，越来越感受到它的重要性，对产品研发的不可缺失。在我的成长过程中，经历了“code review”的不同角色，每个过程，每个角色，都经历了很多，积累了经验。

作为初出茅庐的创业者

从学校毕业不久，出来和朋友一起创业，那时就知道埋头苦干，不讲方法，快速出来产品系统是首要唯一任务。所有的事情都得自己做，加班加点，人也不多，各做各的，相互之间根本没有什么code review，谁写好了，谁就commit到代码库，经过简单测试，就可以上线了。不行回滚，修复了再上，完全就是初出茅庐的原始人的做法。那时，经验不足，考虑不周全，系统经常会出问题。调试bug的过程中，耗时耗力，当时就会有同事一起调试，一起看代码，最原始的非正式的code review就是那时开始的。当初的经验教训就是，debug sucks，test rocks，code review even rockets。

作为代码提交者

刚出道时，作为新人，更多的是写代码和让高手审查，也慢慢学习怎么审查。

首先，必须了解和学习公司的code review 规范流程。最先学习了不同编程语言的code style，并且要求通过公司的code style测试，也叫做code readability（代码可读性）测试。之后一定按照style规定来写代码，包括怎么定义变量名，函数名，类名，如何使用空格，怎么写注释说明，哪些语法不鼓励甚至禁止使用，等等，这样做的好处是提高代码的可读性，一致性，可维护性。有了好的训练，一辈子受益的事情。公司开发了code style检查工具，使用工具来检查代码的可读性，不符合的立即修正。

写代码之前，设计好项目的目录结构，模块结构，对象结构，保证代码的整体结构合理。这样，别人一看目录就能知道项目要完成的任务，每个文件要做的事情。

进入编码阶段，先勾画出大体框架，然后一个一个细化，代码漂亮，结构合理，算法精致，执行效率高。能复用的尽可能复用，因为那些代码经过了很多测试，质量有保证。

每写完一个部分，一定要完善测试用例，主要是白盒单元测试。整体写完之后，要有集成测试，回归测试，甚至负载测试，等等。编译，测试，整合到脚本里面，这样，每次修改，就能运行脚本自动完成各种测试，保证质量。

一个大项目的各个可以独立完成的任务，实现和测试好了之后，打包成一个change list，而不是零零散散的，不成系统的，不能独立运行的一堆代码。

再次检查，自己满意了，才会提交code review。一般，找同项目中的水平高的，能力强的，甚至技术leader，邀请他们来审查，他们能给你更好的建议，让你学到更多的东西，提高的更快。要求越高越严，实际对自己越好。有人经常犯的错误是找一个关系好的，或是很随和的容易通过的，去做自己的code review，以为这样省事，不会被“批评”，其实，从长远看是不利于自己发展和提高的。

作为代码审查者

跟高手交流的过程中，积累了不少code review的经验，自己也慢慢可以做一些code review的工作了。尤其是当别人改了自己写的代码，毋庸置疑会被挑选为第一代码审查者。

刚开始审查代码时，会偏重于表层的东西。整体扫描代码，代码风格是否满足，可读性怎么样，代码结构是否合理，是否有懒婆娘裹脚的函数，或是巨大的类，注释是否清楚，代码是否重复，是否完成了需求，是否有大的疏漏，等等。如果发现了这些相对容易识别的问题，会打回去，让作者先修改好，才给做仔细的深度的审查。原则上，如果代码提交者负责任的话，这类问题应该很少出现。

如果文档或是需求没有清楚说明，会和作者讨论，了解清楚要完成的任务，和解决办法，算法。所有这些都清楚了，就可以坐下来好好的读代码，想代码，审查代码了。

审查代码时，会一行一行读下来，理解它，会思考有没有一些可能出现的问题，边界情况是否考虑了。会思考如果自己来写，会怎么实现。如果想到的任何问题，会去检查测试用例中是否考虑到了。还会关注是否有安全漏洞，代码的扩展性如何，代码的执行效率如何，架构是否合理是否一脉相承，对象设计是否合理，在多线程多用户的情况下是否有问题，等等。很多的都可以作为checklist一项一项检查。

审查代码的过程，可不是一个轻松的过程。这时，不但在理解别人的代码，也是自己在思考如何实现。如果作者的设计和算法和自己不一致，会比较谁的方案更好。如果感觉自己的更好，会和作者讨论，建议。

代码复用，模式提炼是一个应该注意的点。看看代码的组织是否有利于别人复用，是否可以提取模式，能复用的应该提取出来生成便于复用的形式。再者，由于各人对整个代码库的掌握情况不一样，这时，也会关注作者的代码有没有是库里已经有的，那就应该调用，而不是重复实现，从而减少犯错。

对于重要的或是难以理解的代码，会做面对面的code review。对于核心或是critical代码，会组织code review meeting，大家一起看代码，这样，也是一个知识共享的过程。有时候，可能一个代码，会邀请多人审查，各人会有不懂的见解，发现不同的问题，虽然这样比较费时，但完成后更能保证质量。

作为管理者

后来，除了上面的角色，还要作为一个管理者，负责规范和实施code review。主要做着以下几个工作。

首先是制定公司的code review的规范和流程，而且这个必须作为研发的一项政策，要求全体研发必须严格执行。比如，类似如下的code review流程。

再者，文档化不同语言的代码风格（code style），对于公司常用的语言，都应该有一套，可能有Java，可能有C++，可能有Python，可能有PHP，可能还需要定义脚本语言的风格。这样，大家有据可循，统一思想和实践。

根据以前的经验，定义了一个code review的checklist，相当于一些注意事项都记载下来随时供参考，这样，对于主要的检查点，像安全检查，多任务多线程，扩展性，复用，OO设计，测试完备性，架构，等等，不会被忽略。其他的点，就可以自由控制和发挥了。比如，类似如下的checklist。

然后，设立简单易用的code review环境，并将review强制嵌入到代码提交到代码库的命令中。没有代码review，没有审查者的首肯，代码是没法commit到代码库中的。有人实现了review board ＋ svn 的强制code review的方案，有人实现了 review board ＋ git 的 方案。总之，希望在代码提交的命令中自动提醒和强制code review，这样人人都强制遵守，靠的是自动化的程序命令，而不是人。这一点很重要，能法制的，不要人治。

最后，量化效果，包括code review的执行情况，反馈时长，评论数量，反复次数，甚至和测试或是线上的bug系统联动起来，真正监控code review的质量，奖赏分明。各种指标可视化，放到dashboard上，谁都可以看到。再按指标给代码提交者和审查者排名，想激励优秀的，就将好的弄成 star list。想鞭策落后的，就将差的弄成 shame list。

 http://mp.weixin.qq.com/s?__biz=MjM5ODIzNDQ3Mw==&mid=2649966104&idx=1&sn=2e9a184beb676cb8687c0bed024fdd62&scene=21#wechat_redirect

关于代码审核