重构概念
重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。在保持功能不变的前提下，利用设计思想、原则、模式、编程规范等理论来优化代码，修改设计上的不足，提高代码质量。
为什么要重构？
重构是时刻保证代码质量的一个极其有效的手段，不至于让代码腐化到无可救药的地步。项目在演进，代码不停地在堆砌，代码总是会往越来越混乱的方向演进。优秀的代码或架构不是一开始就能完全设计好的，随着系统的演进，重构代码也是不可避免的。重构是避免过度设计的有效手段。将一个比较烂的代码重构成一个比较好的代码，会让你很有成就感。对一个工程师本身技术的成长也有重要的意义。初级工程师在维护代码，高级工程师在设计代码，资深工程师在重构代码。
重构的方式：
大型重构指的是对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。小型重构指的是对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名、规范注释、消除超大类或函数、提取重复代码等等。
对重构的态度：
寄希望于在代码烂到一定程度之后，集中重构解决所有问题是不现实的，保持持续重构。
单元测试（Unit Testing）- 最可落地执行、最有效的保证重构不出错的手段：
单元测试是代码层面的测试，由研发自己来编写，用于测试“自己”编写的代码的逻辑的正确性。写单元测试的过程本身就是代码 Code Review 和重构的过程，能有效地发现代码中的 bug 和代码设计上的问题。对集成测试的有力补充、帮助我们快速熟悉代码、TDD 可落地执行的改进方案。如何编写单元测试？写单元测试就是针对代码设计各种测试用例，以覆盖各种输入、异常、边界情况，并将其翻译成代码。写单元测试尽管繁琐，但并不是太耗时；放低对单元测试代码质量的要求；覆盖率作为衡量单元测试质量的唯一标准是不合理的；单元测试不要依赖被测代码的具体实现逻辑；单元测试框架无法测试，多半是因为代码的可测试性不好。单元测试为何难落地执行？写单元测试本身比较繁琐，技术挑战不大，很多程序员不愿意去写；开发进度紧，执行虎头蛇尾。
代码的可测试性：
针对代码编写单元测试的难易程度依赖注入是编写可测试性代码的最有效手段
常见的测试不友好的代码：
代码中包含未决行为逻辑滥用可变全局变量滥用静态方法使用复杂的继承关系高度耦合的代码
解耦 - 大型重构的有效手段
解耦保证代码松耦合、高内聚，是控制代码复杂度的有效手段。代码高内聚、松耦合，意味着代码结构清晰、分层模块化合理、依赖关系简单、模块或类之间的耦合小，那代码整体的质量不会差。是否需要解耦？修改代码是否牵一发而动全身；模块与模块、类与类之间的依赖关系画出来看复杂性给代码解耦的方法有：封装与抽象、中间层、模块化、设计思想与原则（单一职责原则、基于接口而非实现编程、依赖注入、多用组合少用继承、迪米特法则等）、设计模式（观察者模式等）。
摘自：http://gk.link/a/10iey
图：思维导图
