跨越重构的鲁比孔河

接近鲁比孔河

在 1999 年，许多人联系我，谈论他们正在开发的用于支持重构的工具。我在 www.refactoring.com 上列出了这些工具（wiki 上还有另一个列表）。虽然 refactoring.com 并不是网络的中心，但人们显然希望被列入重构工具中。

然而，我对在网站上评论重构工具一点也不感兴趣。有很多事情让我感兴趣，但评论软件产品不在其中。我很乐意保留一个列表，但评论我会留给其他人。

话虽如此，一些最低标准是必要的。一些供应商希望我提到他们的工具。我查看了他们的“移动方法”功能，发现虽然他们可以将方法体从一个类移动到另一个类，但他们没有改变调用者。结果，程序在应用转换后无法编译：这几乎不是语义保留的！

有一些工具更诚实地描述了它们的功能。一些工具提供了执行各种重命名的能力，例如 重命名方法。现在，只要调整了调用者，重命名就等同于重构——而且是一个非常有用的重构。此外，一些工具支持移动类，并且由于在 Java 中重新打包很麻烦，因此这是一个非常有用的重构。

所有这些都是令人鼓舞的迹象。但即便如此，我并没有真正兴奋。所有这些都是步骤，但有一个关键的障碍需要跨越。

鲁比孔河

我一直在谈论的重命名类型需要对软件进行一些分析，但它相当浅显。你可以在不深入了解程序结构的情况下进行重命名。事实上，许多人通过编辑器搜索/替换或通过简单的基于正则表达式的脚本手动进行重命名。为了充分利用重构，你实际上必须分析和操作程序的解析树，正如 John 和 Don 在书中所描述的那样。

需要这种能力的重构是 提取方法。虽然亚马逊上的一位评论者将此描述为仅仅是剪切和粘贴，但提取方法实际上需要一些认真工作。你必须分析方法，找到任何临时变量，然后弄清楚如何处理它们。这种分析不是通过正则表达式操作就能完成的。它需要一些细致的工作。

这就是为什么我认为它是一个关键的重构。如果你能做到提取方法，这可能意味着你可以进行更多重构。它是一个标志，表明“我对这件事很认真”。

跨越鲁比孔河

让我觉得有人认真尝试跨越鲁比孔河的第一件事发生在 1999 年年中，当时我收到了 Instantiations 的联系。对于那些不知道的人来说，Instantiations 是 OO 领域最受尊敬的名字之一。这家公司诞生于波特兰 Smalltalk 社区，是 Digitalk 的主要组成部分之一，并在 Smalltalk 领域做了很多严肃的工作。从那时起，他们转向了 Java，并开发了几款产品，包括 Jove——一个原生编译器。

因此，当 Instantiations 说他们开始开发一个重构工具（当时代号为 Alchemy——现在称为 jFactor）时，我很兴奋，因为我知道他们有能力做好这项工作。当他们说他们要解决的第一个重构是提取方法时，我更加鼓舞人心。

然而，他们并不是第一个跨过这条河的人。这个荣誉属于 X-ref：由 Marian Vittek 开发的 emacs 插件。说实话，这对我没有太大影响，因为我不在 emacs 中使用 Java。此外，x-ref 的提取有一些限制，而且 Marian 的团队是一个小型团队。但它做到了，如果你经常使用 emacs，它绝对值得一看。

如果说 X-ref 是划着小船跨越鲁比孔河，那么 Instantiations 就是以风格跨越了这条河。他们的工具 jFactor 支持一个不错的重构列表，包括提取方法，在一个非常专业的工具中。 jFactor 可作为 IBM 的 Visual Age for Java 的插件使用。现在，提取方法只是一个选择代码、选择菜单项并输入名称的问题。重构已经以风格出现。

jFactor 足以让我认为 2001 年 1 月是重构的标志性月份，但我却得到了一个惊喜。有一段时间，IntelliJ 一直在为 Java 构建一个 IDE，它因其类似 Visual Age 的搜索功能而受到喜爱。他们在工具中添加了各种重命名功能，这使得它成为我们六楼的次要最爱，因为我们无法使用 Visual Age。然后在 1 月，我收到了一封意外的电子邮件——他们的 IDEA 工具现在支持提取方法。

更进一步

1 月的热潮让我兴奋，因为我相信重构工具将对软件工程产生重大影响。事实上，我将 John 和 Don 的重构浏览器称为自 IDE 以来开发工具领域的最大进步。我也希望现在跨越了提取方法的鲁比孔河，更多重构将随之而来。我当然敦促你查看这些工具并尝试使用它们的重构功能。

作为旁注，我不会提供这些工具的评论。进行适当的评论太耗时了。我确实与这些供应商保持联系，并将尽我所能帮助他们的开发。但是，我很乐意看到对这些工具的反馈，并将继续在 refactoring.com 上维护一个关于重构工具信息的列表。我也会在供应商与我分享时，在该网站上发布工具新闻。