《重构》

[size=large][b]Martin Fowler[/b][/size]
用一个词来形容作者 [url=http://en.wikipedia.org/wiki/Martin_Fowler]Martin Fowler[/url]，那就是牛逼！他是作家，演说家，企业应用架构专家，敏捷宣言发起人之一。专注于OO、UML、领域建模和敏捷软件开发。他写的[url=http://book.douban.com/subject/5333564/]《重构》[/url]出版于1999年，[url=http://book.douban.com/subject/4826290/]《企业应用架构模式》[/url]出版于2002年，都可以算是程序员必读的书。

[size=large][b]Refactoring[/b][/size]
对《重构》心仪已久，某天见到同事带了一本到公司，还是英文版的，就马上抢了过来读。这是除了大学教材之外，我第一次完整地读完一本英文技术实体书。读完之后我才发现，网上有个[url=http://sourcemaking.com/refactoring]在线版[/url]，内容基本与实体书一致。

全书可以划分为三大部分：第一部分讲解了重构的基础，包括一个例子、一些原则、code smell讲解和如何构建测试；第二部分是重点，讲解了各种重构方法；第三部分是关于重构的其它一些话题，例如大型重构、重构工具等。

整本书读下来，我觉得收益最大的，就是知道了各种各样的 code smell 和相应的重构解决方法。以后在写新代码时，在一些细节设计上可以规避已知的这些 code smell 问题，提高代码质量。在维护旧代码时，也能记起，哦，这个问题可以用XX方法来重构解决～

要说缺点的话，我觉得作者对每个重构方法都详尽地列出了操作步骤，似乎有些冗长。我不知道是否有人真的完全按照作者的步骤去做重构，反正我一般都没有做得那么细，可能工具的支持比较好吧，Eclipse 的重构功能真的很好用。
本文就不列出那些 code smell 和重构方法了，只记一些重构相关的原则。

[size=large][b]什么是重构[/b][/size]
重构就是为了让软件更易于理解和维护，对软件的内部结构进行的、不影响外部行为的修改。

这个定义有两个重点：目标是“让软件更易于理解和维护”，所作的修改必须“不影响外部行为”。

[size=large][b]为何做重构[/b][/size]
[list]
[*]重构能改进软件设计。随着代码被修改，软件的设计会慢慢退化，会过时。重构能让代码保持其原来的结构。
[*]重构让软件更易于理解。我们写代码时总是不考虑代码的后续维护者，致使代码难于理解。
[*]重构能帮你找bug。因为重构让代码变得更清晰，清晰的代码更便于发现问题。
[*]重构能提高编程效率。重构可能会降低你目前的开发效率，但它能提高你以后的开发效率，物有所值。[/list]
[size=large][b]何时做重构[/b][/size]
[list]
[*]“三振出局”原则：第一次写一段代码，就直接写。第二次又写这段代码，你要皱一下眉头，但还是可以照常写。第三次还是写这段代码，那你就得重构了。
[*]当增加功能时，重构。
[*]当修 bug 时，重构。
[*]做代码审查时，重构。
[*]何时不应重构？问题太多的代码，最好直接重写。因为重构的代价很可能比重写还大。[/list]
[size=large][b]重构的其它一些原则[/b][/size]
[list]
[*]重构的第一步永远都相同：为被重构代码编写一组可靠的自动化测试。人始终会犯错，而测试是避免错误的好方法。注意，必须是“自动化”的测试。
[*]重构时应该小步前进，频繁地运行测试，这样当出现问题时就能快速定位。
[*]进行重构时，不要增加新功能，反之亦然。
[*]用“易于重构”的设计代替“十分灵活”的设计，能让设计简化，降低成本。
[*]一般来说，重构都会让程序变慢（例如有更多的方法层级、更多的循环）。但经过重构，代码会更清晰，也就更易于优化性能。
[/list]