追求代码质量（4）-用代码度量进行重构-java开发java经验技巧

《追求代码质量（4）-用代码度量进行重构-java开发java经验技巧》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、追求代码质虽（4）:用代码度虽进行重构-编程开发技术追求代码质量（4）:用代码度量进行重构原文出处：IBM中国在我上屮学的时候，冇一位英语教师说：“写作就是重写别人口结重写过的东西。”直到大学，我才真正理解了他这句话的意思。而且，当我自觉地采用这个实践的吋候，就开始喜欢上了写作。我开始为我写的东西自豪。我开始真正在意我的表达方式和要传达的内容。当我开始开发人员生涯时，我喜欢阅读有经验的专家编写的技术书籍，而且想知道为什么他们花这么多时间编写代码。那时，编写代码看起来是件容易的工作——有些人（总是比我级别高的人）会给我一个问题，而我会用任何可行的方

2、法解决它。直到我开始与其他开发人员合作人型项H,才开始理解我的技能的真正意义所在。我也就在这个时候起，开始有意识地关心我编写的代码，甚至关心起舆•忍人?编写的代码。现在我知道了，如果不注意代码质量，那么迟早它们会给我造成一团乱麻。我恍然大傑的一刻出现在1999年底，那吋我正在阅读MartinFowler那本影响重大的书Refactoring:ImprovingtheDesignofExistingCode（重构:改进现有代码的设计,这本书对一系列重构模式进行分类，并由此建立了重构的公共词汇。在此Z前，我一直都在重构我的代码（或者-其他人的代码），

3、但是却不知道自己做的就是重构。现在，我开始为我编写和重构的代码感到更加口豪，因为我做的工作正是在促进代码的编写方式并让它们日后更易维护。什么是重构?按照我的观点，重构就是改进口线改进的?代码的行为。实际上，重构是个永不停止的代码编写过程，它的目的是通过结构的改进而提高代码体的可维护性，但刼改变代码的整体行为。重要的是要记住重构与重写?代码明显不同。重写代码会修改代码的行为甚至合约，而重构保持对外接口不变。对于重构方法的客户机来说，看不到区别。事情像以而一样工作，但是工作得更好，主要是因为增强的可测试性或者明显的性能提升。主动和被动重构那么问题就变

4、成了“我怎么才能知道什么时候该进行重构呢?”？一段代码的可维护性是个主观的问题。但是，我们屮的多数人都会发现，维护自己编写的代码要比维护其他人编写的代码容易得多。但在这点上也有争议——在整个职业生涯屮维护自己的代码是最大挑战。没有几个真正的“代码牛仔”足够幸运地能够不断地变换工作，而不必修改其他人的代码。对于我们中的多数人來说，必须维护其他人的代码恰恰是程序员生活的一部分。决定代码是否需要重构的方法,通常是主观的。但是，也自可能客观地判断代码是否应当重构，不论是口己的代码还是别人的代码。在?这个系列前面的文章中，我介绍了如何用代码度量客观地测试代

5、码质量。实际上，可以用代码度量很容易地找出可能难以维护的代码。一旦客观地判断出代码屮有问题，那么就可以用方便的重构模式改进它。提取方法模式MartinFowler的书出版之后的几年屮，增加了许多新的重构模式分类；但是，迄今为止最容易学习的模式，也町能是最冇效的模式，仍然是提取方法(ExtractMethod)?模式。在这个模式中，方法的一个逻辑部分被移除，并被赋予口己的方法定义。现在被移走的方法体被新方法的调用代替，如图1的UML图所示：ACCOLllIAjCtlOll提取方法模式提供了两个关键好处:•原来的方法现在更短了，因此也更容易理解。•移

6、走并放在自己方法屮的逻辑体现在更容易测试。降低圈复杂度在使用的时候，对于被高度圈复杂度值感染的方法来说，提取方法是一剂良药。您可能会记得，圈复杂度通过度量方法的路径数量；所以，可以认为如果魏坎?出其中一些路径，重构方法的整体复杂性会降低。例如，假设在运行了像PMD这样的代码分析工具Z后，结果报告显示其中一个类包含的一个方法冇较高的圈复杂度值，如图2所示：图2.圈复杂度值高达23!Avoidreallylongmethods.28SAvoidreallylongparameterlists.285Themethod'updateContent*ha

7、saCyclomaticComplexityof23.285Avoidreassigningparameterssuchas•title'289Avoidreassigningparameterssuchas*urr291在仔细查看了这个方法之后，发现这个方法过长的原因是使用了太多的条件逻辑。正如我以前在这个系列屮指出的(请参阅？参考资料)，这会增加方法屮产生缺陷的风险。谢天谢地，updateContent()?方法还有个测试用例。即使已经认为这个方法有风险，测试也会减轻一些?风险。另一方面，测试已经精心地编写成可以测试?updateConten

8、t()?方法小的23个路径。实际上，好的规则应当是：应当编写至少23个测试。而且，要想编写一个测试用例，恰好能隔离出方法中的第18个条件