|
|
本文最开始是从鹅厂内部的技术论坛的一个问题回答，这里做一些整理形成一个文章。
记录下团队构建以来，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
|
|
发表于 2019-8-26 09:46:45
