Refactoring(重构),你是否需要？

<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> 你是否遇到过软件熵原则？它提出：对于设计良好的程序，随着少量新功能的不断增加，它们会逐渐失去设计良好的结构，最终变成一大碗意大利空心粉。其中部分是阴翳，你写了一个能很好完成特定任务的小程序，接着用户要求增加程序的功能，程序会越来越复杂。尽管你努力地注意设计，但随着工作的增加，程序更复杂，这种情况仍然会发生。 出现这种情况的一个原因是当在一个程序上增加新功能时，你是在一个已存在的程序上面做工作，而通常这个程序原本没有这样的设计考虑。在这种情况下，你可以重新设计已存在的程序以更好的支持改变，或者在增加时解决解决它们。虽然，理论上，重新设计会比较好一些，但是因为对已存在程序的任何改写都会引入新的错误和问题，所以常常会导致额外的工作。记住一个古老的工程学格言："如果它不会崩溃，就不要修复。（if it ain't broke,don't fix it.）"。然而，如果不重新设计程序，增加的功能将会比它们应该的要复杂得多。逐渐地，额外的复杂性将引起昂贵的代价。因此要有一个平衡：重新设计会引起短痛但可以带来长期的好处。由于进度压力，大部分更愿意将他们的痛苦推迟到将来。 Refactoring是一个描述降低重新设计短期痛苦的技术的术语。Refactor的时候，你不是改变程序的功能，而是改变它内部结构使得它更容易理解和修改。Refactoring的改变通常是小步骤的，重命名方法、将一个字段从一个类转移到另一个类或者在超类中合并两个相似的方法。每一步是很微小的，然而在许多这样的小步骤中，可以给程序带来很大的好处。 Refactoring可以按照下列原则变得更加容易： 不要同时refactoring和增加功能。在两者之间要有明显的界限。可以经过很短的步骤在两者之间进行切换：半小时refactoring，一小时增加新功能，再半小时refactor刚添加的代码。 在开始refactoring之前，保证测试彻底。只要可能就要进行测试。这样，如果修改引起了破坏，你可以很快就知道。 采取小的有计划的步骤：将一个字段从一个类转移到另一个类，在超类中合并两个相似的方法。Refactoring经常包含许多局部的修改，结果是引起大规模的改变。如果保持小步骤，每个步骤后进行测试，你可以避免长时间的调试。 什么时候应该refactoring？ 当给一个程序增加功能，你可能会发现旧代码是个阻碍。当这开始成为一个问题时，停止增加新功能，取而代之的是refactor旧代码。 当查看代码发现难于理解时。Refactoring有助于帮助理解代码并使这份理解延续到将来。 你经常会发现需要refactor其他人写的代码。在这种情况下，和代码的作者一起refactor。编写别人容易理解的代码是很困难的。refactor的最好方法是让别人试图理解代码并将你的理解和他们的不熟悉结合起来。 什么时候使用它？ Refactoring是一门尚未充分利用的技术。它才刚刚开始被认识，主要是在Smalltalk社团。然而我相信无论使用什么样的开发环境，它都是一门提高软件开发的关键技术。确保你的开发者理解怎样以一种有纪律的方式进行refactoring，并让指导者教会他们这些技术。 去哪儿寻找更多资料？ 因为refactoring仍是一门非常新的技术，所以关于它的文章还很少。 William Opdyke's PhD thesis 很可能是关于这个题目的最大资源地，但是它只适合于自动化refactoring工具，而不是人们现在使用的技术。Kent Beck是refactoring最主要地倡导者之一，他的关于模式的书[Beck]包括许多集中于refactoring的模式。如果使用VisualWorks Smalltalk，你可以下载Refactory，一个支持refactoring的工具。

代码太容易变坏，重复代码随处可见，特别是那些初看相似细看又不同的 代码泛滥于整个系统： 条件表达式，循环结构、集合枚举.....信息被共享于系统一些关系甚少的 组成部分之间，通常，这使得系统中几乎所有的重要信息都变成全局或者重复。 解决这个问题的最好办法当然是让它不要发生。然而，要阻止代码的腐化， 你需要付出额外的代价。每次在修改或增加代码之前，你都要看一看手上的这些代码。 如果它很好的话，那么你应该能够很方便地加入新的功能。如果你需要花很长的时间 去理解原来的代码，花更长的时间去增加和修改代码。 那么，先放下手里的活，让我们来做 Refactoring。 一.Refactoring 介绍 二.Refactoring 理由 三.Refactoring 问题 四.Refactoring 困难 五.Refactoring 方法 六.Refactoring 与软件设计 七.Refactoring 场合与命名规则 中文JAVA技术网重新整理发布