优秀代码---改善代码三部曲:重构、设计模式、重构与模式

重构是术，设计是道：

前言

1、好代码的特点

好代码就像 玩笑无需解释。

•内聚Cohesive： 内聚的代码更容易理解和查找 bug

• 松耦合Loosely Coupled： 松耦合的代码让实体之间的副作 用更少，更容易测试、复用、扩展

• 封装Encapsulated： 封装良好的代码有助于管理复杂度， 也更容易修改

•自主 Assertive： 自主的代码其行为和其所依赖的数据放在 一起，不与其它代码互相干预（Tell but not Ask） • 无重复Nonredundant： 无冗余的代码意味着可以只在一个 地方修复bug和进行更改。

内聚：一个模块内各个元素彼此结合的紧密程度 耦合：一个软件结构内不同模块之间互连程度的度量。 松耦合：系统的模块与模块之间，尽可能的使其独立存在，也就是单一职责。 模块与模块之间的接口，尽量的少而简单。 高耦合：模块相互之间依赖性比较多，模块与模块之间的关系也比较复杂。导致的问题是一个模块出现了问题,其他功能模块都不能正常运行，然后定位问题也比较困难。 系统如何“高内聚、低耦合”？将程序积木化。 内聚性越强，则要求的函数越多(每个函数只作一件“事”)，这样，将它们组合成“大”的功能，也就越复杂，就不可能达到松耦合。因此，应在二者之间作出平衡与折衷的选择，这也体现程序员的水平。 应该从系统论的角度来看： 首先系统是有层次的，即系统可以分为子系统。 其次模块化：模块可分为子模块。 “强内聚、松耦合”的“度”的把握，应结合系统的次层性来考虑，即通常应在层次性上作出折衷，如：模块内子程序(下一个层次上)应共享数据(有一定的耦合度)，而减少全局变量能降低子程序性间的耦合性。 　　面向对象的语言进一步强化了“强内聚、松耦合”，类的封装性既强调了相关内容(数据及其操作)的内聚，又强调了类的独立性和私密性。 比如类之间的关系，继承就组合的耦合性强，组合是类与类之间通常通过接口的契约实现服务提供者/服务请求者模式，这就是典型的松耦合。

2、代码质量的重要性：

软件生命周期的各个阶段的时间分布，从需求到最后部署分布情况：

写完代码并不是一劳永逸，而是需要2/3的时间是来维护。

开始写烂代码，可能导致破窗效应：

• 不敢设计：增加了又一个 if，增大圈复杂度。
• 不敢拆分方法：持续增长的方法长度
• 不敢拆分类：持续增长的类大小
• 持续脏代码：“脏”代码诱发增加更多的坏味道
• 不敢抽象：为了适配不同场景拷贝出大量重复代码。

软件源码某部分的圈复杂度就是这部分代码中线性无关路径的数量。 如果一段源码中不包含控制流语句（条件或决策点），那么这段代码的圈复杂度为1，因为这段代码中只会有一条路径；如果一段代码中仅包含一个if语句，且if语句仅有一个条件，那么这段代码的圈复杂度为2；包含两个嵌套的if语句，或是一个if语句有两个条件的代码块的圈复杂度为3。

一、改善代码的三部曲

《设计模式》-> 《重构》-> 《重构与模式》。也就是设计->重构->重构出新设计，改善代码的三部曲：

第一部曲？：《设计模式》主要详细说明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.演进式设计

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

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

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

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