追求代码质量 - 用代码度量进行重构 - 编程入门网

追求代码质量 - 用代码度量进行重构

在我上中学的时候，有一位英语教师说：“写作就是重写别人已经 重写过的 东西。” 直到大学，我才真正理解了他这句话的意思。而且，当我自觉地采用 这个实践的时候，就开始喜欢上了写作。我开始为我写的东西自豪。我开始真正在意我的表达方式和要传达的内容。

当我开始开发人员生涯时，我喜欢阅读有经验的专家编写的技术书籍，而且 想知道为什么他们花这么多时间编写代码。那时，编写代码看起来是件容易的工 作 —— 有些人（总是比我级别高的人）会给我一个问题，而我会用任何可行的 方法解决它。

直到我开始与其他开发人员合作大型项目，才开始理解我的技能的真正意义 所在。我也就在这个时候起，开始有意识地关心我编写的代码，甚至关心起其他 人 编写的代码。现在我知道了，如果不注意代码质量，那么迟早它们会给我造 成一团乱麻。

我恍然大悟 的一刻出现在 1999 年底，那时我正在阅读 Martin Fowler 那 本影响重大的书 Refactoring: Improving the Design of Existing Code（重 构：改进现有代码的设计，这本书对一系列重构模式进行分类，并由此建立了重 构的公共词汇。在此之前，我一直都在重构我的代码（或者其他人的代码），但 是却不知道自己做的就是重构。现在，我开始为我编写和重构的代码感到更加自 豪，因为我做的工作正是在促进代码的编写方式并让它们日后更易维护。

什么是重构？

按照我的观点，重构就是改进已经改进的 代码的行为。实际上，重构是个永 不停止的代码编写过程，它的目的是通过结构的改进而提高代码体的可维护性， 但却不 改变代码的整体行为。重要的是要记住重构与重写 代码明显不同。

重写代码会修改代码的行为甚至合约，而重构保持对外接口不变。对于重构 方法的客户机来说，看不到区别。事情像以前一样工作，但是工作得更好，主要 是因为增强的可测试性或者明显的性能提升。

主动和被动重构

那么问题就变成了“我怎么才能知道什么时候该进行重构呢？” 一段代码的 可维护性是个主观的问题。但是，我们中的多数人都会发现，维护自己编写的代 码要比维护其他人编写的代码容易得多。但在这点上也有争议 —— 在整个职业 生涯中维护自己的代码是最大挑战。没有几个真正的 “代码牛仔” 足够幸运地 能够不断地变换工作，而不必修改其他人的代码。对于我们中的多数人来说，必 须维护其他人的代码恰恰是程序员生活的一部分。决定代码是否需要重构的方法 ，通常是主观的。

但是，也有可能客观地判断代码是否应当重构，不论是自己的代码还是别人 的代码。在 这个系列前面的文章中，我介绍了如何用代码度量客观地测试代码 质量。实际上，可以用代码度量很容易地找出可能难以维护的代码。一旦客观地 判断出代码中有问题，那么就可以用方便的重构模式改进它。

总是运行测试用例！

重构别人编写的代码的秘诀是不要把它弄得更糟。在我重构生涯的早期，学 到的一件事就是在修改一些东西之前 拥有一个测试用例很重要。我是通过艰苦 的一夜，在我自己整理得很好的重构方法中苦苦寻觅，只为找到一个我不小心破 坏的别人编写的工作正常的代码之后学到这个教训的，不小心破坏的原因就在于 重构之前没有对应的测试用例。请注意我的警告，在自己进行重构之前，总是要 运行测试用例！

提取方法模式

Martin Fowler 的书出版之后的几年中，增加了许多新的重构模式分类；但 是，迄今为止最容易学习的模式，也可能是最有效的模式，仍然是提取方法 （Extract Method） 模式。在这个模式中，方法的一个逻辑部分被移除，并被 赋予自己的方法定义。现在被移走的方法体被新方法的调用代

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!