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：如何给代码解耦？
封装与抽象、中间层、模块化、以及一些设计思想和原则如单一职责原则、基于接口而非实现编程、依赖注入、多用组合少用继承、迪米特法则。还有一些设计模式如观察者模式。
|