3.3.3 代码评审

代码评审（Code Review）一般指人工评审。进行代码评审既可以尽早发现代码中的缺陷、统一编码风格，又可以提高团队成员的工程能力，督促大家分享设计理念与实现方式。

1.代码评审的参与人员

代码评审的参与人员分为代码提交人员和代码评审人员两类，二者的职责也不尽相同。

代码提交人员应当遵循以下行为原则。

● 避免提交大PR，过大的PR，比如超过1000行的，既可能引入更多的缺陷，又会影响评审效率。

● 写清楚PR的标题和描述，指明PR在做什么，以及为什么这么做。

● 尽量完成PR的开发，否则要在PR的标题加上WIP以表示正在开发中。

● 保证代码的质量。

● 确保PR职责单一，降低代码评审的成本。

代码评审人员应当遵循以下行为原则。

● 及时审查新提交的或更新过的PR。

● 少一些抱怨，要明白从来就没有完美的代码。

● 给予尊重和耐心。针对代码，而不是代码提交人员。

● 提供代码改进建议。

● 意识到，如非必要，代码的重构可以发生在未来的迭代中。

● 避免一次性审查过多的代码。

● 保持合适的评审速度，比如每小时审查不少于500行代码。

2.代码评审的形式

代码评审一般分为线上代码评审和线下代码评审两种。线上代码评审是一种异步的代码评审方式。代码提交人员将PR提交给代码评审人员后，可以开始下一个任务。而代码评审人员可以按照自己的时间表进行评审。与之相对的，线下代码评审是指开发人员在会议室中向团队解释提交的代码。线下代码评审有利于减少代码提交人员和代码评审人员的沟通次数，也有助于团队理解代码评审的目标和意义。我们可以采用线上和线下相结合的方式进行代码评审。

3.代码评审中应关注什么

代码评审过程中通常要关注以下问题。

● 代码应该有好的设计思路。

● 代码要满足功能性需求。如果是前端的改动，需要有UI截图。

● 代码的实现不应过于复杂，要避免过度设计。简单易读的代码能够降低维护成本。

● 代码应该有测试用例。测试用例也应当有好的设计思路。

● 代码应该有好的命名规则。

● 代码应该有文档和注释。文档如godoc，用来解释代码是用来做什么的。注释则侧重于解释为什么这么做。

● 代码应该遵循团队的代码风格指南。