重构与模式改善代码三部曲中的第三部

本文主要是介绍重构与模式改善代码三部曲中的第三部，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、改善代码的三部曲

《设计模式》-> 《重构》-> 《重构与模式》。也就是设计->重构->重构出新设计。

《设计模式》主要详细说明20几种模式，为我们带来了常见设计问题的经典解决方案，从而改变了整个面向对象开发的面貌。为设计而著。

《重构》改善既有代码的设计，总结了我们会用到的各种重构手法，为我们带来了一种改进代码的高效过程，从而彻底改变了面向对象设计的方式。侧重去除坏代码的味道。

《重构与模式》是设计模式相关的重构。模式不是设计出来的，是重构出来的。好的设计也不是设计出来的，是重构出来的。不要怕改变，只要改变得法，变就不再是灾难，而是进步的良机。侧重设计模式+重构手段。

在阅读重构与模式之前，最好熟读前面两本：《设计模式》和《重构》。

设计模式代表了传统的软件开发思想：好的设计会产生好的软件，因此在实际开发之前，值得花时间去做一个全面而细致的设计。重构代表了敏捷软件开发的浪潮：软件并不是在一开始就可以设计得完美无缺的，因此可以先进行实际开发，然后通过对代码不断的进行小幅度的修改来改善其设计。二者从不同角度阐述了设计的重要性。

有些人在编写任何代码之前，都要很早地为模式做计划，而有些人在编写了大量代码之后才开始添加模式。
第二种使用模式的方式就是重构，因为是要在不增加系统特性或者不改变其外部行为的情况下改变系统的设计。
有些人在程序中加入模式，只是因为觉得模式能够使程序更容易修改；更多人这样做只是为了简化目前的设计。
如果代码已经编写，这两种情形都是重构，因为前者是通过重构使修改更容易，而后者则是通过重构在修改后进行整理。
虽然模式是在程序中能够看到的东西，但是模式也是一种程序转换。
重构是实现设计模式的一种手段，设计模式往往也是重构的目的。

二、重构与模式的缘由

应该通过重构实现模式、趋向模式和去除模式(refactoring to, towards, and away from pattern)，而不是在预先设计中使用模式，也不再过早的在代码中加入模式。这技能避免过度设计，又不至于设计不足。

1. 过度设计 ：代码的灵活性和复杂性超出所需。有些开始设计的时候，认为某些地方会频繁的改动，甚至开始使用了某种设计模式预留扩展，但是后来却没怎么动，也就是导致了废设计和功能.

2. 设计不足

产生设计不足的原因：
1）程序员没有时间，没有抽出时间，或者时间不允许进行重构

2）程序员在何为好的软件设计方面知识不足
3）程序员被要求在既有系统中快速的添加新功能
4）程序员被迫同时进行太多项目
长期的设计不足，会使软件开发节奏变成“快，慢，更慢”，可能的后果是：
1.0版本很快就交付了，但是代码质量很差
2.0版本也交付了，但质量低劣的代码使我们慢下来
在企图交付未来版本时，随着劣质代码的倍增，开发速度也越来越慢，最后人们对系统、程序员乃至使大家陷入这种境地的整个过程都失去了信心
到了4.0版本时或者之后，我们意识到这样肯定不行，开始考虑推倒重来

3. 测试驱动开发和持续重构，

测试驱动开发和持续重构提供了一种精益、迭代和训练有素的编程风格，能够最大程度的有张有弛，提高生产率。“迅速而又从容不迫”

使用测试驱动开发和持续重构的益处：

1）保持较低的缺陷数量

2）大胆的进行重构

3）得到更加简单、更加优秀的代码

4）编程时没有压力

模式和重构之间存在着天然联系，模式是你想达到的目的地，而重构则是从其他地方抵达这个目的地的条条道路。

4.演进式设计

演进式设计即趋向性设计，主要是避免过度设计。

通过重构产生设计结构，也就是通过重构实现模式或者重构趋向模式。为设计而设计的思路并不适合大项目，循序渐进从重构到设计模式才是设计模式的王道。

敏捷开发中经常采用的演进式架构设计：

很多程序员可能都遇见过这种事：某块代码亟待修改，却没有人愿意接手。为什么会这样？这段代码正巧是两个组件间的接口，修改工作太过困难。而在演进式设计中，我们常常会做这种修改。代码应当是"活的"并且是"可生长"的，决不能无视强烈的变化需求而保持一成不变。正因为如此，演进式设计可以提高设计质量，进而提高整个系统的质量。