现行系统中我们存在的问题：
僵化性（Rigidity）：设计难以改变。
脆弱性（Fragility）：设计易于遭到破坏。
牢固性（Immobility）：设计难以重用。
粘滞性（Viscosity）：难以做正确的事情。
不必要的复杂性（Needless Complexity）：过分设计。
不必要的重复（Needless Repetition）：过多的重复。
晦涩性（Opacity）：混乱的表达。
具体来说：例如
1、代码重复；
2、过长的方法（太多的上下文信息，如大量临时变量，使代码不容易理解）；
3、过大类（往往是一个类承担了太多的职责所致）；
4、过长参数列（方法参数一般不要超过7个）；
5、发散式变化（一个类受多种变化的影响）；
6、散弹式变化（一种变化引发多个类的相应修改）；
7、依恋情结（类的某个方法“身在曹营心在汉“）；
8、数据泥团（总是绑在一起的数据）；
9、基本类型偏执（过份依赖于语言内置的类型）；
10、Switch语句（容易导致重复）；
11、平行继承体系（散弹式变化的特例）；
12、冗赘类（一个类承担的职责过少）；
13、夸夸其谈未来性（过分追求代码的灵活性导致很多不必要的事情，增加了系统理解难度和可维护度）；
14、令人迷惑的暂时值域（值域“招聘了临时工”）；
15、过度耦合的消息链（对象之间玩起了“击鼓传花”）；
16、中间转手人（一个类里有过多“不干实事”的方法）；
17、狎昵关系（两个类过于亲密）；
18、异曲同工的类（“马甲”类）；
19、不完美的程序库类；
20、纯稚的数据类（“哑类”，“只吃粮食不干活”的类）；
21、被拒绝的遗赠（这个气味一般不强烈）；
22、过多的注释（感觉需要添加注释前试着让所有注释都变得多余）。
2、过长的方法（太多的上下文信息，如大量临时变量，使代码不容易理解）；
3、过大类（往往是一个类承担了太多的职责所致）；
4、过长参数列（方法参数一般不要超过7个）；
5、发散式变化（一个类受多种变化的影响）；
6、散弹式变化（一种变化引发多个类的相应修改）；
7、依恋情结（类的某个方法“身在曹营心在汉“）；
8、数据泥团（总是绑在一起的数据）；
9、基本类型偏执（过份依赖于语言内置的类型）；
10、Switch语句（容易导致重复）；
11、平行继承体系（散弹式变化的特例）；
12、冗赘类（一个类承担的职责过少）；
13、夸夸其谈未来性（过分追求代码的灵活性导致很多不必要的事情，增加了系统理解难度和可维护度）；
14、令人迷惑的暂时值域（值域“招聘了临时工”）；
15、过度耦合的消息链（对象之间玩起了“击鼓传花”）；
16、中间转手人（一个类里有过多“不干实事”的方法）；
17、狎昵关系（两个类过于亲密）；
18、异曲同工的类（“马甲”类）；
19、不完美的程序库类；
20、纯稚的数据类（“哑类”，“只吃粮食不干活”的类）；
21、被拒绝的遗赠（这个气味一般不强烈）；
22、过多的注释（感觉需要添加注释前试着让所有注释都变得多余）。
重构(Refactoring)
在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构一种有纪律的、经过训练的、有条不紊的程序整理方法。
本质：在代码写好后改进它的设计
重构与哪些技术有关系： 设计模式 类设计 系统架构
设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
类的设计： 单一职责原则（SRP） 开放-封闭原则（OCP） Liskov替换原则（LSP） 依赖倒置原则（DIP） 接口隔离原则（ISP）
就一个类而言，应该仅有一个引起它变化的原因，一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
系统架构的设计 面向组件或是面向服务
下面有时间结合实际项目给大家介绍下我的重构过程。
