1. 重构的目的：为什么重构 ❓

对于项目来言，重构可以保持代码的质量持续处于一个可控状态，不至于腐化到无可救药的地步，对于个人而言，重构非常锻炼一个人的代码能力，并且是一件非常有成就感的事情。它是我们学习的经典设计思想，原则，模式，编程规范等理论知识的练兵场。

2. 重构的对象：重构什么❓

按照重构的规模，我们可以将重构大致分为大规模高层次的重构和小规模低层次的重构。大规模高层次重构包括队代码分层，模块化，解耦，数理类之间的交互关系，抽象复用组件等待。这部分工作利用的更多的是比较抽象，比较顶层的设计思想，原则，模式。小规模低层次的重构包括规范命名，注释，修正函数参数过多。消除超大类，提取重复代码等等编程细节问题，主要是针对类，函数级别的重构，小规模低层次的重构更多的是利用编码规范这一理论知识。

3. 重构的时机：什么时候重构❓

持续重构！重构是开发必不可少的部分，融入到日常开发中，而不是等到代码出现很大问题的时候，再大刀阔斧

4. 重构的方法：如何重构 ❓

大规模高层次的重构难度大，需要组织，有计划的进行，分阶段的小步快跑，时刻让代码处于一个可运行的状态。而小规模低层次的重构，因为影响范围小，改动耗时段，所以只要你愿意并且有时间，随时随地都可以去做

1. 什么是单元测试❓

单元测试是代码层面的测试，由研发自己来编写，用于测试“自己”编写的代码的逻辑的正确性，单元测试顾名思义是测试一个“单元”，有别于集成测试，这个“单元”一般是类或函数，而不是模块或者系统

2. 为什么要写单元测试 ❓

写单元测试的过程本身就是代码code review 和重构的过程，能有效的发现代码中的BUG 和代码设计上的问题。除此之外，单元测试还是对继承测试的有力补充，还能帮助我们快速熟悉代码，是TDD可落地执行的改进方案。

3. 如何编写单元测试❓

写单元测试就是针对代码设计各种测试用例，以覆盖各种输入，异常，边界情况，并将其翻译成代码。我们可以利用一些测试框架来简化单元测试的编写。除此之外，对于单元测试。我们需要建立以下正确的认知：

• 编写单元测试精力繁琐名单不是太耗时
• 我们可以稍微放低对单元测试代码质量的要求；
• 覆盖率作为衡量单元测试质量的唯一标准是不合理的；
• 单元测试不要依赖被测代码的具体实现逻辑；
• 单元测试框架无法测试，多半是因为代码的可测试性不好。

4. 单元测试为何难落地执行❓

一方面，写单元测试本身比较繁琐，技术挑战不大，很多程序员不愿意去写；另一方面，国内研发比较偏向“快糙猛”，容易因为开发进度紧，导致单元测试的执行虎头蛇尾。最后，关键问题还是没有建立对单元测试正确的认识，觉得可有可无，单靠督促很难执行的很好

1. 什么是代码的可测试性 ❓

粗略的讲，所谓代码的可测试性，就是针对代码编写单元测试的难易程度。对于一段代码，如果很难为其编写单元测试，或者单元测试写起来很费劲，需要依靠单元测试框架中很高的特性。那往往就意味着代码设计不够合理，代码的可测试性不好。

2. 编写可测试性代码的有效手段❓

依赖注入是编写可测试代码的最有效手段，通过依赖注入，我们在编写单元测试的时候，可以通过mock的方式解依赖外部服务，这也是再编写单元测试的过程中最有技术挑战的地方

3. 常见的 Ani-Patterns ❗

常见的测试不友好的代码有下面这5种：

• 代码中包含未决行为逻辑
• 滥用可变全局变量
• 滥用静态方法
• 使用复杂的继承关系
• 高度耦合的代码

1. 解耦为何如此重要 ❗

过于复杂的代码往往可读性，可维护性上都不友好，解耦保证代码松耦合，高内聚，是控制代码复杂度的有效手段，代码高内聚，低耦合，也就是意味着，代码结构清晰，分层模块化合理，依赖关系简单，模块或之间的耦合小，那整体的质量就不会差

2. 代码是否需要“解耦”❗

间接的衡量标准有很多，比如，看修改代码是否牵一发而动全身，直接的衡量标准是把模块，类与类之间二点依赖关系画出来，根据依赖关系图的复杂性来判断是否需要重构

3. 如何给代码 “解耦”❗

给代码解耦的方式有： 封装与抽象 ，中间层，模块化，以及一些其他的设计思想 比如：单一职责原则、基于接口而非实现编程、依赖注入、多用组合少用继承、迪米特法则等。当然，还有一些设计模式，比如观察者模式。