第一章 重构，第一个案例
即便如此，这个程序还是能正常工作。所以这只是美学意义上的判断，只是对丑陋代码的厌恶，是么？如果不去修改这个系统，那么的确如此，编译器才不会在乎代码好不好看呢。但是当我们打算修改系统的时候，就涉及到了人，而人在乎这些。差劲的系统很难修改，因为很难找到修改点。如果很难找到修改点，程序员就很有可能犯错，从而引入bug。
你的态度也倾向于尽量少修改程序：不管怎么说，它运行的很好。你心里牢牢记着那句古老的工程谚语：“如果它没坏，就不要动它。” 这个程序也许还没坏掉，但它造成了伤害。他让你的生活比较难过，因为你发现很难完成客户所需的修改。这个时候，重构技术就该粉墨登场了。
如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便的达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。
重构的第一步。每当要进行重构时第一步永远相同：为即将修改的代码建立一组可靠的测试环境。重构需要可靠的测试以避免绝大多数引入bug的情形。
分解长长的函数。代码块愈小，代码的功能就愈容易管理，代码的处理和移动就愈轻松。
重构技术就是以微小的步伐修改程序，如果你犯下错误，很容易便可发现它。