游戏开发论坛

 找回密码
 立即注册
搜索
查看: 1750|回复: 0

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

[复制链接]

1万

主题

1万

帖子

3万

积分

论坛元老

Rank: 8Rank: 8

积分
36572
发表于 2019-8-26 09:46:45 | 显示全部楼层 |阅读模式
本文最开始是从鹅厂内部的技术论坛的一个问题回答,这里做一些整理形成一个文章。

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

“生产关系与生产力”

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

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

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

1.jpg

阶段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.jpg

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

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

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

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

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

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

更直接的技术文化

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

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

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

3.jpg

阶段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

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2024-5-3 11:14

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表