读设计模式之美（五）

27：什么情况下要重构？为什么要重构？又该怎么重构？

真正进行代码重构的人不多，而把持续重构作为开发的一部分的人，更是少之又少。

1：重构的目的，为什么重构？

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

为什么重构？

1.重构是保证代码质量的一个极其有效的手段。

2.优秀的代码都是迭代出来的。

3.避免过度设计的有效手段。

重构对一个工程师技术的成长也有重要的意义。

2：重构的对象，到底重构什么？

1.大型重构：系统、模块、代码结构、类与类之间的关系。对应手段：分层、模块化、解耦、抽象可复用组件等。

2.小型重构：类、函数、变量等代码级别。对应手段：规范命名、规范注释、消除超大类或函数、提取重复代码等。

3：重构的时机，什么时候重构？

提倡的策略是持续重构。重构能力很重要，但重构意识更重要。

4：重构的方法，又该如何重构？

1.大型重构时，提前完善重构计划，分阶段进行，需要有经验、熟悉业务的同事来主导。

2.小型重构时，因为影响范围小，改动耗时短，只要你愿意并且有时间，随时都可以重构。

对于重构这件事，资深的工程师，项目leader要负起责任来，时刻保持代码在一个良好的状态。

28：为了保证重构不出错，有哪些非常能落地的技术手段？

1：什么是单元测试？

单元测试由研发工程师自己来编写，用来测试自己写的代码的正确性。

2：为什么要写单元测试？

1.单元测试能有效的帮你发现代码中的bug

2.写单元测试能帮你发现代码中的问题

3.单元测试是对集成测试的有力补充

4.写单元测试的过程本身就是代码重构的过程

5.阅读单元测试可以帮你快速熟悉代码

6.单元测试是TDD可落地执行的改进方案

3：如何编写单元测试？

写单元测试就是针对代码设计各种测试用例，以覆盖各种输入、异常、边界情况，并将其翻译成代码。

1.编写单元测试尽管繁琐，但并不是太耗时。

2.我们可以稍微降低单元测试的代码质量。

3.覆盖率作为衡量单元测试的唯一标准是不合理的。

4.单元测试不要依赖被测代码的具体逻辑。

5.单元测试框架无法测试，多半是因为代码的可测试性不好。

4：单元测试为何难落地执行？

1.单元测试繁琐，技术挑战不大，很多程序员不愿意写。

2.国内开发环境“快、糙、猛”，容易因为开发进度而执行的虎头蛇尾。

3.对单元测试没有正确的认识，觉得可有可无，单凭督促很难执行的很好。

29：什么是代码的可测试性？如何写出可测试性好的代码？

1：什么是代码的可测试性？

所谓代码的可测试性，就是针对代码编写单元测试的难易程度。

如果一段代码，很难为其编写单元测试，或者单元测试写起来很费劲，那往往意味着代码测试的不够合理，代码的可测试性不好。

2：编写可测试性代码的最有效手段

1.依赖注入是编写可测试性代码的最有效手段

2.可以通过mock解依赖外部服务。

3：常见的测试不友好的代码有以下5种：

1.代码中包含未决行为逻辑

2.滥用可变全局变量

3.滥用静态方法

4.使用复杂的继承关系

5.高度耦合的代码

30：如何通过封装、抽象、模块化、中间层等解耦代码？

1：解耦为何如此重要？

解耦保证代码松耦合、高内聚，是控制代码复杂度的有效手段。

2：代码是否需要解耦？

间接的衡量标准有很多，比如看修改代码是否牵一发而动千身。

直接的衡量标准是，把模块与模块、类与类之间的依赖关系画出来，根据依赖关系图判断。

3：如何给代码解耦？

封装与抽象、中间层、模块化、以及一些设计思想和原则如单一职责原则、基于接口而非实现编程、依赖注入、多用组合少用继承、迪米特法则。还有一些设计模式如观察者模式。