说说代码评审_代码评审制度规范

近一段时间以来，组内严格实行代码评审制度。参与过多次评审后发现，一次有效的代码评审并不简单，把一些思考做一下总结。

||  代码评审的目的

| 提前发现问题

问题发现越早，解决成本越小，带来的损失也越小。

| 保证代码库的健康状况

随着时间推移，代码库的健康状况往往会下降。通过代码评审，如果能使代码库整体健康状况不快速下降，就算达到目的了。

||  评审准备工作

| 评审规范

团队最好要有一套评审规范，如果没有，可以在一段时间的评审后沉淀一套规范。

有了规范，评审就可以按规范一条条过，节省时间。

有了规范，产生意见分歧时，依据规范，化解分歧。

| 评审时间节点

很多观点是每次提交代码前都要评审，但实际工作中并不可行。

自测后期就可以发起评审，最晚到测试前期。如果有问题，还有充足的时间修改、测试。

新的模块可以分阶段多次评审，优先评审核心代码，及时发现并纠正问题，避免后期大量返工。

评审不通过有大改动的，改动后要再次评审。

| 评审形式

有条件的一定要面对面评审，效率高。下文也都是基于此形式的讨论。

跨地域的可以邮件评审或者评审工具评审。

| 发起人要做什么

邀请评审人（必须包含熟悉此业务的人），提前发会议邀请，协调评审人的时间。

需求背景提前同步出来，便于评审人提前了解，节省评审时间。

准备好CL（Change List），要了然于心，确定一个合理的讲述方案。建议零星改动按列表讲，其他最好按业务流程讲。

多说一句：CL 不仅仅是改动的代码，还可能包括DB脚本、配置信息、单测、数据现状、调研方案及结论...

| 评审人要做什么

参加评审，就要对其负责（假设出现事故有问责制），做好前期必要的准备工作。时间允许的话，提前了解需求，熟悉此部分业务，预判可能出现问题的节点，重点关注哪些部分，带着问题去评审。

| 评审工具

IDE集成的对比工具即可。使用工具有很多好处：

1）可以一条一条的点，不会漏代码。千万不要滚鼠标，很容易漏；

2）有前后对比，使评审人更直观的看到原来代码什么样，你这次改成什么样；

3）可以只看改动代码，节省时间。直接看代码很容易扯到没改动的代码去。

||  评审过程中容易出问题的点

评审时，千万不要上来就讲改了哪些代码... 这只会使评审效果大打折扣。

发起人要先花上几分钟，快速讲一下本次的需求背景，原来什么样，这次什么样，要改哪些模块。让评审人快速准确的了解本次业务范围，以便接下来能够给出合理的评审意见。

| 粗心类错误

这类错误和技术水平没有太大关系。

比如 if 条件里的取反；

配置是否漏配了环境，是否拷贝后忘了修改环境相关的信息；

数据库字段长度够不够用（一般都是扩展字段容易超）；

测试结束后改动的代码忘提交了；

这些可以通过和同桌交叉检查的方法来避免。

| 方案过度设计

1）过度考虑未来业务

设计满足当前需求，以及合理业务扩展即可。

经验表明，之前很多当时认为极具前瞻性的设计，后面多数都是没用的，或者用到了，也要做很大改动。

2）过度考虑极端场景

比如某个后台人工操作的场景（一个月也不一定操作一次，正好又赶上服务挂了），要不要失败系统自动重试？

类似这种通过简单的人工补救方案（业务重试、重新发起）可以达到目的，就没必要设计复杂的技术补救方案，因为每引入一个方案又会带来新的问题。

3）过度的错误兼容逻辑

为了追求数据的正确性、一致性，可能会出现各种异常数据校验、各种异常处理逻辑，层层自我重试。

很多情况下，完全可以采取 “约定大于开发” 的准则，就能减少很多校验，很多重试的处理。比如约定入参格式、返回结果，约定由谁触发重试等等。

各个行业都有约定，比如 USB、网线的排线顺序，我们不可能在提供USB口、网线口的设备上考虑各种错误线序的兼容方案、错误反馈。

| 前后业务流程有逻辑漏洞

这种问题不好发现，需要对业务足够熟悉，流程足够清楚。

可能单看 A、B 两个接口都没有问题，但 A、B 在前后流程上有依赖关系。整个流程一串起来问题就暴露出来了。

| 事务

日志类的操作不要回滚，要留痕。

事务回滚是否影响重试的请求？ 

| 冗余的数据库访问、服务调用

同一流程中前后2个方法都查询了同一数据。

循环逻辑内查库、调服务。

（假设每次访问都是要收费的，是不是就能省则省了）

| 定时任务

是否幂等？

是否能重复执行？

是否能暂停？

是否能够异常继续？

是否有超时风险？

是否超过下游承载能力？

禁止limit m,n 分页。

| 影响范围有遗漏

梳理影响系统的方案是否科学。

服务治理统计出的是否全面，有没有直接调用的？

从日志、端口统计，时间范围是否够广？

一些边缘系统、定时任务是否会遗漏？

||  共同成长

| 心态要正

代码评审不是挑毛病，能有效实现功能无严重问题即可。可以给出自己的建议，但允许每个人有自己的风格。

对事不对人，发起人和评审人都要有这个意识，大家的共同目的是一致的。

| 沉淀

评审发现的问题要留心记一下，避免重复采坑。

经过一个阶段的评审之后，很多东西是可以直接拿来复用的。

| 点赞学习

好东西要点赞、相互借鉴学习（好的技术方案，好的编码习惯，或者好用的工具类），共同提高编码水平。

扯两句

评审一次费时费力，尽量让其效果最大化

一个合格的程序员绝不仅仅是写好代码这么简单

搜寻资料的过程发现了谷歌的代码评审规范，可以参考学习。
官方：https://google.github.io/eng-practices/review

中文：https://jimmysong.io/eng-practices