Question

我刚到一家互联网公司时发现整个App团队在使用Gerrit进行代码评审（Code-Review）。搭设Gerrit这样一个服务器并不难，难的是整个App团队都在坚定不移地贯彻Code-Review，每个人提交代码，都必须由另一个人审核批准后才能提交到GIT上——这不由得让我叹为观止。

但是我观察了一段时间后发现不是那么回事，Code-Review的具体执行和最初的美好愿景并不匹配。首先我们是个互联网公司，App迭代的周期只有2周，所有开发人员都疲于奔命做需求，哪里还有时间去审核别人的代码，于是就会产生以下几种情况：

·技术能力强并且责任心强的开发人员，一天80%时间用于审核别人提交的代码。

·技术能力强但是责任心差的开发人员，代码看都不看直接就审核通过了。

·技术能力弱的开发人员，要他们审核别人的代码，也看不出什么问题来。即使责任心强也是心有余而力不足。

另一个副作用是，因为每次请别人Code-Review都要等，所以开发人员倾向于每天下班前一次性提交所有改动，并没有遵守持续开发、持续提交、持续测试的持续集成思想。而审核代码的人就更是辛苦了。

我曾经一度想把Gerrit机制废弃了，但是想想还是不妥，主要是因为：

·好习惯很难养成，坏习惯一句话就能达到了。今天我把Gerrit废弃了，等哪天想恢复重新来可就难了。

·目前线上有各种bug，倒是还可以归咎为新人经验不足、开发资源不足、测试不充分等各种原因；而废弃Gerrit之后，接下来的线上bug，可就都是没有Code-Review导致的了。

思前想后，我的解决方案是：

·对老员工不再进行Code-Review。

·对新员工和实习生、应届生，要为他们每个人指定一个Code-Review的老员工，至少3个月之内，对他们的Code-Review还是要严格执行的。

此外，关于Code-Review的标准，每个人心里的秤也不一样。有的人看编码规范，有的人看编码逻辑，你问我哪个对？我也说不出来。Code-Review我在软件公司也经历过，那时是每周一晚上，所有开发人员坐在一个会议室，在各自的笔记本上看分配给自己的要审核的代码。这期间，每个人都可以提出他认为不妥的各种问题，由被审核人进行回答，只要能自圆其说就行，否则就记下来，Code-Review会议结束后进行修改。慢慢地，几个月下来，大家的编程风格渐趋一致，这就是Code-Review所要达成的效果。

在互联网公司，没空搞我上面说的那套。毕竟两周一次迭代逼死人啊！于是我把Code-Review的策略改为，每周一下午，技术经理从上周提交的代码中找出10处写的有问题的代码片段，然后给大家进行讲解和讨论。在达成共识后，今后就再也不能写类似的代码了。

那么对于有问题的代码，该怎么处理呢？我的做法是，对于首页、会员中心这种一级页面，代码写的再烂，也不要改，之前毕竟是稳定的，你改了后可能就不好用了，重构这部分代码是件长期的工作。对于二级或三级页面，我们倒是可以分配到具体的开发人员，把问题都改了，毕竟即使改错了，也只是影响局部某个功能。

每周进行一次整个团队的Code-Review，把每周发现的问题汇总，坚持半年时间，整个团队的代码质量会有很大改善。

在进行Code-Review的同时，有一个东西可以顺带搞出来，那就是模板页面，即符合编码规范要求、可以作为编写其他页面的模范页面。如果项目中没有这样的页面，那就找到符合60%要求的页面，然后把它改造为符合100%要求的。对于Android应用类App而言，一个模板页面是不够的，至少要提供Activity、Adapter、Entity、Fragment这4个模板页，其中Activity要包括对MobileAPI的调用。

有了模板页，所有开发人员的编码就有章可循，单纯搞Code-Review和编码规范都太抽象，一定要有能落地的东西，那就是模板页。