JBuilder 2005 分布式重構實戰：跨團隊協作的利器

大型軟體常拆分為多個子模組，由不同團隊並行開發。假設系統包含三大模組：

• A 模組：底層處理類庫，由獨立團隊維護（對應獨立 JBuilder 專案）。
• B、C 模組：上層業務模組，依賴 A 模組的 JAR 包。

當 A 模組進行重構時，變更僅限於當前專案。JBuilder 會記錄重構軌跡，並允許將重構資訊封裝進 JAR 包。B、C 專案透過更新類庫引入新 JAR 後，即可自動套用重構變更。這就是 分布式重構——解決關聯專案間重構同步的關鍵技術。

實戰演示：從建立公共庫到跨專案套用重構

1. 建立公共庫專案

創建 common_lib 專案，開發 DateUtils 類：

1. package common_lib;
2. public class DateUtils {
3. public static String getNowTime()
4. {
5. return ""+(new Java.util.Date());
6. }
7. }

將專案打包為 common_lib.jar，置於 myrefactor/extralib 目錄，並在 myrefactor 專案的擴展類庫中引用。

2. 客戶端專案引用

在 myrefactor 中新建 Distribute 類調用 DateUtils.getNowTime()：

1. package myrefactor ;
2. import common_lib.DateUtils;
3. public class Distribute
4. {
5. public void printCurrTime()
6. {
7. System.out.println(DateUtils.getNowTime()) ;
8. }
9. }

3. 公共庫重構並記錄歷史

一段時間後，A 團隊將 getNowTime() 重命名為 getCurrTime()。透過 Refactor → Refactoring History... 查看記錄：

圖 30 重構歷史記錄

對話框列出所有重構歷史，可透過 Remove 移除不想分發的記錄。

4. 打包時攜帶重構資訊

若專案資源樹已有打包節點，右鍵選 Properties，切換至 Refactoring 設定頁：

圖 31 在封存檔中包含重構記錄

重新打包生成 common_lib.jar，覆蓋 myrefactor/extralib/common_lib.jar。

5. 客戶端專案套用分布式重構

打開 myrefactor.jpx，選單 Refactor → Distributed Refactorings...，切換至 Pending Refactorings 頁籤：

圖 32 未決的重構列表

列表顯示待套用的重構記錄（此處僅有方法重命名）。選中記錄點擊 Apply，Distribute 類的調用自動更新為 DateUtils.getCurrTime()：

1. …
2. public class Distribute
3. {
4. public void printCurrTime()
5. {
6. System.out.println(DateUtils.getCurrTime()) ;
7. }
8. }

6. 透過 ErrorInsight 快速修復

當擴展類庫的 API 變更後，引用該類的專案結構窗格會出現圖示。右鍵選擇重構修復選單（如 Refactor Method）：

圖 33 通過 ErrorInsight 進行重構修復的對話框

點擊 OK，JBuilder 不僅修復當前類，還會掃描整個專案中所有引用該方法的位置並一併重構。

切換至 Completed Refactorings 頁籤可查看已完成的重構項目：

總結

有了重構，盡量少用單純的「替換」功能——重構保證了變更的安全性與一致性。JBuilder 的重構支援讓代碼調整行雲流水。重構不是階段性工作，一旦發現代碼結構混亂或聞到「壞味道」，即應重構。即使專案已作為 API 被其他專案依賴，分布式重構也能讓合作團隊以最小成本保持一致性。

工具提供操作，但如何透過重構優化代碼仍需理論指導。強烈推薦 Martin Fowler 的《重構——改善既有代碼的設計》。