跨越重構的盧比孔河

接近盧比孔河

1999 年，許多人與我聯繫，討論他們正在開發的支援重構的工具。我在 www.refactoring.com 中列出了這些工具清單（wiki 上還有另一個清單）。儘管 refactoring.com 幾乎不是網路的中心，但人們顯然希望在重構工具中名列前茅。

不過，我一點興趣都沒有要檢閱網站上的重構工具。有很多事情讓我有興趣，但檢閱軟體產品不在其中。我很樂意保留一份清單，但評論我會留給其他人。

話雖如此，一些最低標準是有必要的。有幾家廠商希望我提到他們的工具。我查看了他們的「移動方法」功能，發現雖然他們可以將方法主體從一個類別移動到另一個類別，但他們沒有變更呼叫者。因此，套用轉換後，程式不再編譯：難以保留語意！

有些工具對其功能較為誠實。許多工具提供執行各種重命名的功能，例如 Rename Method。現在，只要調整呼叫者，重命名便可視為重構，而且是非常有用的重構。此外，許多工具支援移動類別，而且由於在 Java 中重新封裝很麻煩，因此這是一個非常有用的重構。

這些都是令人振奮的跡象。但即便如此，我還是沒有感到非常興奮。這些都是步驟，但有一個關鍵障礙需要克服。

盧比孔河

我一直在談論的重命名類型需要對軟體進行一些分析，但這相當淺薄。您可以在不深入探討程式結構的情況下進行重命名。事實上，許多人透過編輯器搜尋/取代或透過基於簡單正規表示式的腳本手動進行重命名。若要全面進行重構，您實際上必須分析和操作程式的剖析樹，正如 John 和 Don 在書中所描述的。

需要此功能的重構是 Extract Method。雖然亞馬遜上的一位評論者將此描述為僅僅剪貼，但 Extract Method 實際上需要一些嚴肅的工作。您必須分析方法，找出任何暫時變數，然後找出如何處理它們。分析不是您可以透過正規表示式操作來執行的。它需要一些仔細的工作。

這就是我將其視為關鍵重構的原因。如果您能執行 Extract Method，這可能表示您可以繼續進行更多重構。這是表示「我對此很認真」的標誌。

跨越盧比孔河

讓我認為有人認真嘗試跨越盧比孔河的第一件事是在 1999 年年中，當時 Instantiations 與我聯繫。對於那些不知道的人來說，Instantiations 是物件導向圈子中備受推崇的名稱之一。該公司誕生於波特蘭 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 維護一份關於重構工具的資訊清單。供應商與我分享工具新聞時，我也會將其發布在該網站上。