在我上中学的时候，有一位英语教师说：“写作就是重写别人已经 重写过的东西。” 直到大学，我才真正理解了他这句话的意思。而且，当我自觉地采用这个实践的时候，就开始喜欢上了写作。我开始为我写的东西自豪。我开始真正在意我的表达方式和要传达的内容。
当我开始开发人员生涯时，我喜欢阅读有经验的专家编写的技术书籍，而且想知道为什么他们花这么多时间编写代码。那时，编写代码看起来是件容易的工作 —— 有些人（总是比我级别高的人）会给我一个问题，而我会用任何可行的方法解决它。
直到我开始与其他开发人员合作大型项目，才开始理解我的技能的真正意义所在。我也就在这个时候起，开始有意识地关心我编写的代码，甚至关心起其他人 编写的代码。现在我知道了，如果不注意代码质量，那么迟早它们会给我造成一团乱麻。
提高代码质量
不要错过 Andrew 的附带 讨论组 ，可以在这里得到最迫切问题的答案。
我恍然大悟 的一刻出现在 1999 年底，那时我正在阅读 Martin Fowler 那本影响重大的书 Refactoring: Improving the Design of Existing Code（重构：改进现有代码的设计，这本书对一系列重构模式进行分类，并由此建立了重构的公共词汇。在此之前，我一直都在重构我的代码（或者其他人的代码），但是却不知道自己做的就是重构。现在，我开始为我编写和重构的代码感到更加自豪，因为我做的工作正是在促进代码的编写方式并让它们日后更易维护。
什么是重构？
按照我的观点，重构就是改进已经改进的 代码的行为。实际上，重构是个永不停止的代码编写过程，它的目的是通过结构的改进而提高代码体的可维护性，但却不 改变代码的整体行为。重要的是要记住重构与重写 代码明显不同。
重写代码会修改代码的行为甚至合约，而重构保持对外接口不变。对于重构方法的客户机来说，看不到区别。事情像以前一样工作，但是工作得更好，主要是因为增强的可测试性或者明显的性能提升。
主动和被动重构
那么问题就变成了“我怎么才能知道什么时候该进行重构呢？” 一段代码的可维护性是个主观的问题。但是，我们中的多数人都会发现，维护自己编写的代码要比维护其他人编写的代码容易得多。但在这点上也有争议 —— 在整个职业生涯中维护自己的代码是最大挑战。没有几个真正的 “代码牛仔” 足够幸运地能够不断地变换工作，而不必修改其他人的代码。对于我们中的多数人来说，必须维护其他人的代码恰恰是程序员生活的一部分。决定代码是否需要重构的方法，通常是主观的。
但是，也有可能客观地判断代码是否应当重构，不论是自己的代码还是别人的代码。在 这个系列前面的文章中，我介绍了如何用代码度量客观地测试代码质量。实际上，可以用代码度量很容易地找出可能难以维护的代码。一旦客观地判断出代码中有问题，那么就可以用方便的重构模式改进它。
总是运行测试用例！
重构别人编写的代码的秘诀是不要把它弄得更糟。在我重构生涯的早期，学到的一件事就是在修改一些东西之前 拥有一个测试用例很重要。我是通过艰苦的一夜，在我自己整理得很好的重构方法中苦苦寻觅，只为找到一个我不小心破坏的别人编写的工作正常的代码之后学到这个教训的，不小心破坏的原因就在于重构之前没有对应的测试用例。请注意我的警告，在自己进行重构之前，总是要运行测试用例！
提取方法模式
Martin Fowler 的书出版之后的几年中，增加了许多新的重构模式分类；但是，迄今为止最容易学习的模式，也可能是最有效的模式，仍然是提取方法（Extract Method） 模式。在这个模式中，方法的一个逻辑部分被移除，并被赋予自己的方法定义。现在被移走的方法体被新方法的调用代替，如图 1 的 UML 图所示：
文章来源于领测软件测试网 https://www.ltesting.net/
