9年间，这个鹅厂团队是如何让code review从无到有再到系统化的？

本文最开始是从鹅厂内部的技术论坛的一个问题回答，这里做一些整理形成一个文章。

记录下团队构建以来，9年间code review从无到有到系统化的历程。

“生产关系与生产力”

回过头来看，code review也好，各种开发方式也好，很像生产关系（开发方式）与生产力（团队战斗力，文化等）之间的关系，需要匹配，恰当的配合可以互相发展，反之在团队初期强推“最终版”，恐怕也是不行的。

btw，技术方案的review，结果的定期同步对齐，这些都是性价比超级高，也是一直有的，就不赘述，这里专门指“code review”的专项；

这里就记录下来各个阶段各个情况下我们的选择和结果。


阶段1："不review"的开荒时期

在天刀开发的前1,2年，同事们以有经验的开发者为主，其中大约一半是育碧时期的老同事，还有一些是各个公司里“次时代”项目的开发者。

这个时期有这么几个情况：

• 项目因素：项目在不停的猛烈地赶milestone节点，code review势必要拖慢节奏
• 技术水平：同事们战斗力还都比较好，从结果上看，短时间并没有看出需要code review的必要
• 团队文化：团队文化还都是自由，彼此还有点“抹不开面子”说别人技术哪里不好，所以review的时候“点到为止”“轻描淡写“居多
• 认知：code review本身也存在争议，比如我在13年也写过这样的文章：https://blog.csdn.net/toughbro/article/details/12703813
  

所以这里我们只是在提交milestone的很短的时间里稍微review下，正常情况下都是不review的。

综合上面的各项因素，我们可以看出来这一阶段的不review，谈不上高明，但是有其合理性：

得失

• 确实获得了速度优势：这个至关重要，milestone有个闪失，项目前期cancel了就没的玩了
• 团队文化和比较强的战斗力，都让code review显得多余
• 而且不review，有一些代码问题，由于距离上线还早，有充裕的时间来处理，所以不review的代价也没那么明显
  

当然我们对于技术债务还是比较敏感的，是作为专项问题来看，甚至说还有“借贷式开发”的一种操作：

“主动牺牲一些事情来换取速度，详细记录下所欠债务和处理方式，拿下阶段性的任务，然后接一轮重构和review来把“债务”还清。“

some details:

https://blog.csdn.net/toughbro/article/details/22776277

不过回头看，这一个阶段不review也是比较遗憾，大量的模块遗留实现的不足，尤其是同事们的代码能力的建设没有达到最好，组里几个写程序最强的人，能力与日俱增，但是有些同事则是一直原地踏步。


阶段2：上线阶段+高速迭代+测试人力不足+版本不出事情==double全量review

实际上我们在《天涯明月刀》《无限法则》上线的时候都经历过这样的阶段，版本2天一个，但是测试人力又不太够（恐怕要10x人力才能行），还要保证版本不出事情。

这里只能靠全量review保证，小组内资深程序一轮review，然后leader再review。

底层级别的review，像我们之前做过一次GC（垃圾回收）的优化，曾经直接把整个game object的底层完完整整过了3遍，review时间与开发的时间相当。

这样一种方式，确实能够把事情搞定，且也颠覆了我之前在一些3A项目里的迭代，测试，安全性的认知。

当然也很伤，对项目组的消耗是非常大的，我个人也常常是review到怀疑人生。。。

更直接的技术文化

这里的review因为是要强制保证版本质量必须要做的事情，所以直接无视所有阻力落地，review的力度也是很大，一直到代码“无懈可击”为止。

这里除了代码的稳定质量外，一个最大的收获就是，潜移默化的改变了组内的技术文化，让直接彻底的技术交流文化能够沉淀下来，就代码进行深入交流，reviewer和被review的人都不会觉得难堪。

进一步这样的文化和行动，直接产出了更好的“代码能力”，有一些同事确实是重算法轻工程，中间被review的比较厉害，加上确实出现几次大规模crash，代码力上升也是比较快的。


阶段3：固化和系统化

到天刀上线稳定运营，《无限法则》也开发进行中，团队开始有这样几个变化：

定位变高了：做出行业一流的东西已经是理所当然的了，写出不好的代码，也没人能瞪着眼睛说“运行没问题就行呗”

团队扩大了几倍，

–也吸纳了很多年轻同事，也包括很多刚毕业的萌新，年轻同事都是拥有100%闯祸率,囧

–单靠leader去hold住团队完全不现实了，团队迫切需要更多的高水平的reviewer

可以说对于技术的扩散有了更强的需求和意愿，真是恨不得把代码力最强的几个同事直接传功给项目组。

这里有几个要点：

代码review让技术传承“惯例化”

平时我们也强调技术上的“传帮带”很重要，但是实际落地的时候，一方面大家都这么忙，一方面有时候也碍不开面子，搞不好落一个好为人师，或者对同事不信任等等的感觉。

代码review变成制度之后，不做也要做，而且要认真做，老司机面对代码能够放心的讲解到深层次的思考，听者也不会觉得没面子了。

责任清晰

reviewer要不要对问题负责，这是review中非常重要的一环，没出事大家都可以开开心心的，但是出了事情，就一定要说清楚。

我们的做法是reviewer对代码质量和最终结果要负责的，之前也出现过萌新同学提交出了问题，老司机reviewer也不上心看，结果处理是萌新没事，老司机受罚：新人出事是难以避免的，整件事情中真正有能力确保事情不出错的还是老司机reviewer，reviewer这种情况下才是要真正负担起责任的人。

周会上的典型问题点评

从独乐乐到众乐乐，有些典型的代码问题，写的好的地方，周会专门有一个时段用于展示和讨论。

经验上升也就更快了。

code review的消耗问题

这个应该说是最棘手的问题，这里的核心与根本解决之道还是“以最有效的方式提升团队代码能力”，其余方法基本都是“掩耳盗铃”了。

写代码的人，没有那么多的毛病，团队里技术力强的reviewer也比较多，技术leader也进一步可以解放出来。

sum

是否review以及如何review，在个人看来不是一个“一套真理打天下”的事情，确实是具体问题具体分析，是一个长期建设演化的过程，也是一个逐渐大家理解参透的过程，这样才能在不断变化的业务和阶段，始终能有最优解。


作者：安柏霖
专栏地址：https://zhuanlan.zhihu.com/p/78728333