重构！又是这个词！
记得上学的时候，老师强力推荐了一本叫做《重构》的书，我用了一个月读完了，对于这本书中介绍的各个“招式”有了感性的认识。几年的工作下来，有幸参与了几个大的项目，越发的认识到代码多到一定量级之后，写起来就越发的吃力，这时再次拾起这本书细细品味每个招式的使用场景以及使用技巧，突然有种茅塞顿开的感觉。
《大话重构》我仔细的阅读了试读章节，这本书对于重构的背景做了生动的描述，“大布局你伤不起”-“小设计而不是大布局”-“小步快跑是这样玩的”。每个小结的名字都是这么“下里巴人”，却又不失亲切。从HelloWorld开始的一个小demo，我们从中可以学到的却很多：
重构的定义：对软件内部结构的一种调整，目的是在不改变”软件之可察行为“前提下，提高其可理解性，降低其修改成本。重构就是在代码写好之后改进它的设计。 重构和添加新功能并不冲突，但是当开发者身份在两者之间切换时候，不能混淆在一起。
重构的意义：优秀设计的根本是：消除重复部分！（DRY = Don’t repeat yourself）。重构让代码更清晰， 更容易理解 ，清晰的代码可以更方便的找到bug，重构可以写出更强健的代码 ，良好的设计可以在长远时间上提高开发速度。
重构的时间：随时进行重构（在我看来，重构更是一种开发的习惯）。事不过三，代码重复不要超过三次（否则就要”抽“出来）。添加功能时候并一一重构（个人理解是，添加新功能之前，分析并重构，从而更方便添加新功能）；修补错误时；code review时
重构和开发进度 ：重构的意义之一也是提高开发进度。杀手锏是”不要告诉经理“。
重构的难题：
数据层（数据模型）的变更压力
修改接口
那些难以通过重构改变的设计改动
代码不能运行
项目期限压力 dead line
重构与设计： 编程不是机械的开发，（软件开发是艺术行为！） 。设计和重构的平衡（预先设计的难度和重构灵活性的平衡）
重构与性能：重构确实会在短期内降低代码执行效率，但优化阶段是可以调整的，而且调整会更容易。提前优化是万恶之源。
希望可以将以上想法在《大话重构》中得到印证！