【学习分享】关于代码评审的一些建议

关于BIDS贸易科技有限公司的CTO Jim Bird总结的一些代码评审的建议：

1、代码评审不要太正式

目前，有很多研究表明正式代码的评审会议会延误开发进度和增加开发成本。尽管可能只需要几周的时间进行代码评审，但是只有4%的缺陷是在会议期间发现的，其余所有的缺陷是靠代码评审者自己发现和处理的。只有采用简短、轻量的代码评审才是有效的发现问题在代码检查,这样的代码评审更适合迭代、增量开发，为开发者提供更快的反馈。

2、代码评审人员要尽可能少

并不是代码评审人员越多就能发现越多Bug，只有合理数量的审查人员才能够更加有效的地审查代码。研究表明，平均来说，一个代码评审人员能够发现Bug的一半,第二审稿人会发现剩余新问题的一半。多个人同2个人发现问题的数量没有太大差异，故两个人进行代码评审是比较合适的。另外，还由于社会惰性的存在，更多代码评审人员意味着多人在寻找同样的问题，使得审查人员积极性、主动性不高，更加不利于代码评审工作的有效进行。

3、需要有经验的开发者进行代码评审

研究充分表明，代码评审的有效性依赖于审查人的技能和对问题领域以及代码的熟悉程度。如果让新加入团队的成员进行代码评审的话，并不利于他们的成长，且对于代码评审来说也是一种非常糟糕的方式。只有擅长阅读代码、程序调试、非常熟悉语言、框架、对应的问题的人才最适合代码评审，才能够高效发现问题、提供更多有价值的反馈。新的、没有经验的开发者只适合检查代码的变化和使用静态分析工具并和另一位评论人员共同代码评审。

4、实质重于方式

完全按照编码规格标准进行的代码评审是一个浪费开发人员宝贵时间的方式。代码评审的实质是确认代码能够正确的运行，发现安全漏洞、功能错误、代码错误、设计失误、安全验证和防范、恶意代码等。而不是单单按照编码规范完全保证代码格式一致，而丢失了代码评审的实质。

5、合理安排Bug 和可维护性问题代码的审查时间分配

发现代码中的Bug是很难的，在别人的代码找到的Bug更难。研究表明，代码评审人员找到Bug和可维护性、可读性问题的比例是25:75，故消耗在了代码可读性、可维护性等问题上和Bug上的代码评审时间应该合理分配。

6、尽量使用静态代码分析工具以提高审查效率

工欲善其事，必先利其器。静态代码分析工具可以帮助程序开发人员自动执行静态代码分析，快速定位代码隐藏错误和缺陷；帮助代码设计人员更专注于分析和解决代码设计缺陷；显著减少在代码逐行检查上花费的时间，提高了软件可靠性并节省软件开发和测试成本。

7、二八定律处理高风险代码

审查所有的代码并没有太大的意义，应该把审查的重点放在高风险的代码和容易引起高风险的修改或者重构的代码上。旧而复杂、处理敏感数据、处理重要业务逻辑和流程、大规模重构以及刚加入团队的开发者实现的代码都是审查的重点。

8、从代码评审中尽量获得最大的收益

虽然代码评审是发现Bug、提高开发人员代码编写质量的重要方式，但是它也增加了代码开发成本。如果没有合理、有效的进行代码评审，将有可能影响项目进度和破坏团队文化。故我们要紧抓代码评审的实质性问题，尽早和经常性的进行非正式的代码评审；选择精而少的人员并运用二八定律审查高风险的代码，同时，还需要合理分配Bug以及可维护性问题的代码评审时间，才可以从代码评审中获得最大的收益。

总结：

1.    代码评审不一定需要组织正式的会议，可以通过开发人员先自查，然后项目经理或者开发负责人坐在自己的电脑上对需要评审的代码进行走查，但不管是自查还是走查，必须输出评审问题。

2.    代码评审不一定要项目组全员参加，选择熟悉相关语言和框架、懂相关业务的有经验的人员参加评审即可。

3.    代码评审不一定要审核所有人写的代码，代码评审应该有重点，应把重点放在复杂、处理敏感数据、处理重要业务逻辑和流程、大规模重构以及刚加入团队的开发人员写的代码上。

4.    代码评审不一定要固定时间，但一定要有计划，后续项目经理在制定Mpp计划过程中也应依据开发进度计划所有的代码评审活动，在计划中明确评审哪些代码、哪些人参与评审、评审时间、评审形式）

5.    所有的评审问题均必须得到记录与跟踪。

6.     项目组员提交评审问题情况需纳入绩效考核。