代码评审最常见的两个痛点:Lead/TD 把太多时间耗在评审上,而资深工程师评审参与不够;同时每个评审人的职责边界不清。解决这两点,关键不是「让大家多评审」,而是按团队所处阶段设计不同的评审流程——新团队和成熟团队要的东西不一样。
项目启动时先定三件事
- 职责表:每个功能模块谁是第一评审人、谁是第二评审人,写清楚。
- 评审沟通频道:专门的 channel 收发评审请求和讨论,别散落在各处。
- 编码规范:评审有客观依据,避免吵主观偏好。
搭 Jenkins 流水线之前,先理清持续集成到底要解决什么。这几条是反复验证过的老规矩,顺序大致也是落地优先级。
让构建自带测试
传统意义的「构建」就是编译、链接,把程序弄到能跑。但能跑不等于做对了事。静态类型语言能拦住一部分 bug,漏网的更多。把自动化测试塞进构建过程,是更快抓 bug 的办法——测试不完美,但能抓住的那部分已经够有用了。
每天都往主干提交
集成的本质是沟通:让其他人知道你改了什么。提交频繁,大家就能尽早感知到变化在往哪个方向走;攒一大坨再合,冲突和惊吓都是成倍的。