“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。
这就是我的“code review”的成长历程。
喜欢的话，请关注我们的微信公众号“待字闺中”（daiziguizhongren)。
大家可能还感兴趣：
谢谢。
