代码评审 Code Review

代码质量关系着项目的未来发展和维护，那么为了保持代码的质量，就需要对代码进行评审。代码评审（Code Review，CR）是通过阅读源代码，检查代码是否符合编码规范以及前置发现代码质量问题。

CR的关注点

CR需要重点关注：

代码规范
- 命名：变量名、函数名、类名是否清晰准确
- 描述：提交的描述是否准确对应到功能
- 风格：代码风格是否遵循统一规范
- 文档：是否提交/变更了相应的文档
功能设计
- 设计：设计是否良好、是否适合当前系统
- 功能：实现是否正确
- 简洁：实现是否简洁，有无更好的实现方式
- 测试：是否包含自动化测试，代码可测性如何

小CL（Change List）的好处

前面介绍了CR是什么以及CR关注什么，下面来介绍小CL的好处。小CL是指提交进行Code Review的Change List要尽可能小，把一大段代码拆小再提交给CR。这样做的好处是审查将会更快（代码片段小，不需要太长时间）、更彻底（代码少，更容易看懂），更容易合入代码（合并时不会产生大的冲突），此外如果未能通过代码审查而被拒绝，也能快速修改。

如何面对CR的不同意见

正视批评
- 当审查者对代码提出批评时，应当正视批评，不要为批评而倍感沮丧
修复代码
- 如果审查者对代码的某一部分产生误解，应当及时澄清代码并加上注释
自我反思
- 思考自己的解决方案是否合理，是否有更佳的解决方案
解决冲突
- 尝试在基于技术事实和业界标准的基础上与审查者达成一致

代码重构

在很多时候，我们可能无法在项目的一开始就确定最佳的架构、最优的技术，可能会因为种种原因而导致代码质量没有那么高，也就是产生了所谓技术债（Technical Debt），给未来的项目维护带来了负担。常见的技术债产生原因有时间紧迫、技术水平不够等。既然是技术债，总归是要偿还的，解决技术债的一种方法就是对代码进行重构，以提升代码的可维护性。

代码重构是指对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

何时重构

重构，其实就是为了提高代码质量，不断对抗所谓的Code Smell（代码的坏味道）。因此，当出现Code Smell时，就应该进行代码重构了。常见的Code Smell有：

Duplicated Code 重复代码
Dead Code 死代码，代码没有什么用，但是却没有被移除
Long Method 冗长的方法体
Lazy Class
Feature Envy
Divergent Change
Refused Bequest
Shotgun Surgery
Inappropriate Intimacy
......

常见的代码重构方法

对于重复代码，可以抽离出公共代码，进行类型一般化（从几个类中抽取出公共部分作为这几个类的父类）
对于参数过多的函数，可以将参数封装，通过函数调用获得参数（比如将几个关系较近的参数放在一个类中，传参时传入该类的对象，函数通过调用相关方法获得参数）
对于过于冗长的函数，可以从中抽取出多个子函数，而不是把所有代码堆在一个函数中
对于过于庞大的Switch-Case语句，可以通过策略模式、类型抽象来重构（把Case抽象为一个个类，并为这些类抽象出同一个方法，各个类通过重写方法来实现Case相关的代码，这样只需要调用这个方法而不是写一堆Case语句）
对于嵌套的条件分支，可以提取方法来降低圈复杂度（把嵌套的条件取出来）
对于长调用链（比如a.b().c().d()），可以通过隐藏中间人调用来解决（比如把d()直接提取到a中，实现a.d()）
......

代码评审与代码重构 | 青训营笔记