最近读了关于重构的这本书，突然有个想法，code不是搬砖而是一种艺术，如何写出有艺术感的代码？那就是去研究设计模式和重构。你可以学习很多技术像java的常见特性，框架的技术spring aop原理，但是我认为其实这些都是招式，只有设计模式和重构才是真正的内容，才真正让你的code有了艺术感。所以要成为一个编程艺术家必须精通设计模式和重构。
重构原则：
1. 重构是啥？
不改变软件功能，提供可读性和降低修改成本
2. 为何需要重构，重构能产生哪些价值？
a) 重构改进软件设计，重构就像是在整理代码，越难看出代码所代表的设计意图，就越难保护其中设计，于是设计就消失的越快。经常性的重构可以让代码维持该有的形态。
b) 重构使软件更容易理解， 便于其他人和自己阅读，便于理解原有代码的设计
c) 重构帮助找出bug
d) 重构提高编程速度，良好的设计才能做到快速开发。如果没有良好的设计或许某一段时间你的进展迅速，但是恶劣的设计很快会让你的速度慢下来。
3. 何时重构
a) 添加功能时重构 ，重构能让你更好的理解自己和别人的代码也就越越方便的添加代码，如果代码的设计无法方便的让我添加我的特性那么需要重构。
b) 修补错误时重构，如果收到一份错误报告，这就是需要重构的信号，因为显然代码还不够清晰，没有清晰到让你一眼看出bug。
c) 复审代码时重构，重构别人的代码可以得到最直观的理解。
4. 怎么对项目经理说
受进度驱动的经理需要我们尽快完成，至于怎么完成，那就是我自己的事情，我认为最快的方式是重构，所以我就重构。
6. 重构与设计
仍然做预先设计，但是不必一定找出正确的解决方案。重构让日后的修改成本不再高昂。
7. 重构与性能
开发时不对性能投以必要的关注，直至到性能优化阶段，通常只需要改动一小段代码就可以极大的提高性能，因为90%的性能问题都在10%的代码逻辑处。
坏代码的味道
1. 重复代码 (Duplicated Code)
2. 过长的代码 (Long Method)
3. 过大的类 (Large Class)
4. 过长的参数列表 (Long Parameter List)
5. 发散式变化，一个类多个维度变化（Divergent Change)
6. 霰弹式修改，一个变化设计多个类（Shotgun Surgery)
7. 依恋情节，对别的类的兴趣高过自己类（Feature Envy)
解决：把当前方法移动到另一个类中
8. 数据泥团，多个类的字段同时出现，函数有相同的入参(Data Clumps) （如thirdpartOrderId 和source)
解决：为这些字段创建一个新的对象
9. 基本类型偏执 喜欢基本类型多过对象 (Primitive Obsession)
10.Switch Statement
11.平行继承，为一个类增加子类必须为另一个类增加子类（Parallel Inheritance Hierarchies)
12.冗余类，当前没有作用的类（Lazy Class)
13.夸夸其谈未来性，过度事前设计（Speculative Generality）
过度抽象，很多抽象类和钩子方法，可以在将来发现代码冗余再做抽象。
14.对象的临时变量，只为特殊情况而设（Temporary Field)
实例内的部分变量只为特殊情况存在，这样会给人疑惑，建议重新定义一个新的对象保存这些临时变量。
15.过度耦合的消息链，客户端代码和查找对象高耦合（Message Chains)
16.中间人，类大半的方法都委托给中间人（Middle Man)
17.狎昵关系，两个类过度关注对方的private部分（Inapproriate Intimacy)
18.异曲同工的类(Alternative Classes With Different Interface)
19.不完美的类库，为类库增加新的行为（Incomplete Library Class)
20.纯稚的数据类（Data Class)
21.被拒绝的遗赠，继承无用的属性和方法（Refused Bequest)
22. 过多的注释，过多的注释往往需要重构代码（Comments)
a) 过多的注释往往说明代码很糟糕
b) 如果你不知道该做什么，这才是注释的良好运用时机
c) 此外，注释还可以用来标记你并无十足把握的区域
自动化单元测试
a) 使用自动化测试工具 如junit
b) 每当收到bug报告，为自己添加新的单元测试
c) 测试最可能出错的代码，不用面面俱到