进击的CodeReview

下面是9年间code 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，在个人看来不是一个“一套真理打天下”的事情，确实是具体问题具体分析，它是一个长期的建构和演变过程，也是一个逐渐为大家所理解的过程。只有这样，我们才能在不断变化的业务和阶段中始终有最优的解决方案。

转载声明：本文来源于网络，不作任何商业用途