重构：提升软件质量，单元测试：为重构提供安全保障

缘起

前面两篇博文，带大家认识了TDD和单元测试。现在来了解重构–改善既有代码的设计。

任何一个软件系统，在最初设计的时候，都很难预测到未来的变化。业务的发展随着公司的发展进行改变。为了能够使日渐复杂的系统更加灵活，简洁，易于修改。大师们引入了重构这一软件技术。重构的目的是为了保证现有模块功能不改变的前提下，使代码更加清晰，简洁，更好扩展。而为了保证重构没有破坏现有功能，需要每次重构后，跑一下单元测试，确保重构后，功能没有受到影响。

原则

既然重构是为了改善代码设计，也就意味着，要重构的代码破坏了设计原则。我们在开发过程中很难一直保证遵守设计原则，有很多原因：赶进度，我们不可避免的减少了对设计的思考，而为了更快（短期看起来快，破坏了长期利益）的完成开发任务，我们抛弃了设计原则。又或者我们很难在设计的初期预见到未来的变化，这时我们就需要重构这一法宝。

软件设计的七大原则：

• 单一职责原则
• 开放封闭原则
• 里氏替换原则
• 依赖倒置原则
• 接口隔离原则
• 合成/聚合复用原则
• 迪米特法则

重构的方式

重构目的是为了使现有软件符合设计原则，在面向对象技术中，我们重构就是在类与类之间，函数之间，域之间。

主要有一下几大块（也是重构这本书的主要目录）

• 重新组织函数
• 在对象之间搬移特性
• 重新组织数据
• 简化条件表达式
• 简化函数调用
• 处理概括关系

单元测试在重构中的表现

为了能够确保，重构没有破坏现有的代码功能，我们需要单元测试这个护盾来确保重构没有造成破坏。

更好的做法，不是在重构之前补单元测试，而是在最初开发的使用就使用TDD，这样重构的工作量能大幅减少，毕竟单元测试的工作量也不小。

为了减少单元测试代码， 我们在开发过程中会使自己写更简洁，逻辑更加清晰的代码，例如在重构–简化条件表达式，减少开发过程中对条件表达式的单元测试用例，我们会在开发过程中就思考简化条件表达式这一重构手法。

学习了重构，那么重构最好使用在哪里呢？

就像上面说的 简化条件表达式，重构的手法，会融入我们的日常开发中，而不是积累很多的技术债务，再专门进行重构，重构应该是伴随开发过程，而不是需要团队特别为重构计划时间。

如果由于业务变化，那么现在的设计不能满足新的业务，那么此时需要进行重构，而这时的重构更多的关注的是类与类之间的关系，而不是像简化条件表达式这样的。

总之，了解学习重构，不仅仅是在系统不堪重负的时候进行重构，而是把重构加入到日常开发中。因为重构很难一蹴而就，并且今天的重构，不一定就符合日后新业务。

总之，重构，单元测试，编码技巧，设计模式，所有的所有都是为了使我们的软件更好，很多时候不要为了重构而重构，为了单元测试而单元测试，这就本末倒置了。