EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
Code Review不只是一种管理方法,也是开发者特有的沟通方式,更是一种团队文化。Code Review机制是否健全是评价一个研发团队技术氛围好坏的重要参考。Code Review的意义- 交叉排查缺陷 - 绝大多数BUG都可以在代码层面被发现,甚至测试难以覆盖到的深层次BUG也可以通过团队成员相互审核而避免
- 提高代码质量 - Code Review意味着开发者要接受团队成员的建议与监督,在完成功能的基础之上不断完善代码结构
- 建立团队意识 - 代码是团队财产,团队成员在相互督促与改进中共同成长; K2 {2 z: [" @% H% `0 ^0 D
Code Review的体系- Daily Code Review - 开发者完成初步结构设计,或者完成一个相对完整的小模块都可以提交PR让团队成员Review
- 需求Code Review - 评估需求完成度,与其它需求的潜在冲突
- 上线Code Review - 上线前Review,重点排查配置问题,安全问题,代码冲突
- 重点代码走读 - 每个迭代/双周/月度对具有代表性的代码集体走读,重点在于解决团队共性问题,讨论改进方法- i J6 L# ^4 }% V9 U2 U
3 r) e5 `4 i- t$ M; t3 @ P) ?
是整个Code Review体系中最重要的是Daily Code Review,绝大多数问题应该在每天的Code Review中沟通解决,也就是功夫在平时。
# \4 j& J* @$ H& _4 f; P Code Review有几个重要的参考指标: - 单次提交Review的代码量 - 在思路相对完整的情况下越少越好
- 评论的数量,参与程度 - 每个PR至少2人Review通过之后才能合并代码,但参与人数也不宜过多,避免盲目通过的情况
- 更新的次数 - 通常情况下Code Review不应该直接通过,平均要Update至少一次
! O/ p# v6 V& E* v: }+ G [' u Code Review的文化通过多层次的Code Review体系,在团队中建立起集体认知: - 代码是团队共有的知识财富,而不是个人的私有地
- 所有人对所有代码的最终质量负责,而非某个人对某些代码负责
- 完成功能只是开始,代码需要持续改进以符合团队标准# v( j! G2 d0 |3 h# F) l
Code Review对于团队中的新人来说是很好的锻炼机会,我们团队的新人首次提交代码,被打回更新四五次是很正常的事情。集体对代码质量的追求,也能提升新人的成就感、荣誉感。 ( y" m/ V; G4 C% @4 h$ R
实践中注意强调以下问题:- Code Review不能形式化,没看过PR、没改进意见不能通过
- 被Decline PR不是丢面子的事情,被提改进建议也不是批评,对事不对人
- 将别人提交的代码视作自己将维护的代码,个人标准与集体标准对齐
- H. I- o8 r2 y+ e 总结Code Review体现的是团队对于代码质量的追求,对于团队内部协作的重视。对于新人来讲,对于日常工作的钻研与打磨比偶尔一次的技术培训或分享更有学习价值。
8 w, @; {3 C8 b- D4 B' ]6 u2 e |