Refactoring & Specification

重构

定义：重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。

为什么要重构？

• 时刻保证代码质量。随着代码不停的堆砌，更多的人参与项目，代码会越来越乱，最后重构成本比重新开发还高。

• 优秀的代码都不能一开始就完全设计好，都是迭代出来的，随着系统的演进，重构是不可避免的。

• 避免过度设计。在迭代过程中，真正遇到问题的时候再对代码重构，避免前期投入太多精力。

• 帮助工程师技术成长。

重构什么？

• 大规模高层次重构：对顶层代码设计重构，包括系统、模块、代码结构、类与类之间的关系，手段有分层、模块化、解耦、抽象可复用组件等。主要利用设计思想、原则、模式。影响面较大、难度较大、耗时较长、引入 BUG 风险较大。

• 小规模低层次重构：对代码细节的重构，包括类、函数、变量等，如规范命名、规范注释、消除超大类等。主要利用编码规范。

何时重构：持续重构。平时无事时可以做一下小规模重构；在做功能开发时，遇到不规范的代码，也顺手改了。

解耦

过于复杂的代码可读性、可维护性都不友好。解耦是保证代码松耦合、高内聚、控制代码复杂度的有效手段。

根据模块、类与类之间的关系图的复杂性来判断是否需要解耦。

封装、抽象、中间层、模块化以及一些设计原则与思想（单一职责、基于接口而非实现、依赖注入、多用组合少用继承、迪米特等）是常用的解耦方法。

单元测试

单元测试（Unit Testing）是保证重构不出错的有效手段。单元测试是研发工程师自己编写，用于测试代码的正确性。相对于集成测试（Integration Testing）粒度更小。

写单元测试的好处：

• 能帮你发现代码中的 bug。

• 能帮你发现代码设计上的问题。代码的可测试性是一个重要的质量标准，若代码很难被测试，那么意味着代码设计不合理。

• 对集成测试的有力补充。集成测试很难覆盖全面。

• 写单元测试的过程本来就是代码重构的过程。

• 阅读单元测试能帮你快速熟悉代码。

尽管单元测试的代码量可能是被测代码的 1~2 倍，但并不耗时，因为代码逻辑简单、重复很多。单元测试不会在线上运行，所以代码质量可以降低。不能用覆盖率作为单元测试质量的唯一标准。写单元测试不需要了解代码实现逻辑。

代码的可测试性就是编写单元测试的难易程度。依赖注入是提高可测试性的有效手段。

规范

命名

• 长短：在足够表达含义的情况下，命名越短越好。对于常用的词，可以用缩写，如 str(string), num(number) 等。作用域较小的变量，可以用相对较短的命名。

• 利用上下文简化命名。如 User 类中的成员变量 userName 可以简化为 name。

• 可读、可搜索。可读（容易发音）是为了在项目沟通时方便。可搜索是为了方便在 IDE 中搜索，如大家都用 selectXXX，而你用 queryXXX，那么在 IDE 中药搜索所有查询相关的代码就不方便。

• 接口和抽象类：接口两种方式都可以，一种 IUserService 和 UserService，另一种 UserService 和 UserServiceImpl。抽象类前缀 Abstract。

注释

• 注释的目的是让代码更加容易看懂。注释一般包含：做什么、为什么、怎么做，一些复杂的类和接口还要写如何用。

• 注释也有维护成本，并非越多越好。一般类和函数要写注释，而函数内部注释相对较少。

代码风格

• 函数的行数：不要超过一个屏幕的大小。

• 类的行数：间接判断标准，类读起来头大、实现某个功能不知道用哪个函数、用一个小功能需要整个函数（这个类包含很多无用的函数）时，说明这个类行数过多。

• 一行代码的长度：不要超过 IDE 显示的宽度。

• 善用空行分割代码。

• 缩进：推荐两格，因为可以节省空间。永远不要用 tab 缩进。

• 大括号推荐不另起一行，因为节省空间。另起一行的好处是左右括号可以对齐。

• 类中成员的排列顺序：先成员变量后函数，先静态后普通，先 public、再 protected、最后 private。

编程技巧

• 将复杂的逻辑提炼拆分成函数和类。

• 避免参数过多。可以拆分成多个函数或将参数封装成类的方式。

• 不要使用参数来做代码执行逻辑的控制。包括 null 的情况。

• 函数设计要职责单一。

• 移除过深的嵌套。方法有：去掉多余的 if 或 else；使用 continue、break、return 提前退出嵌套；调整执行顺序；将部分嵌套逻辑抽象成函数。

• 字面量取代魔法数。

• 解释性变量替代复杂表达式。