|
|
從定義上看，重構意味著改變程序的內部結構，而不改變外部的功能行為。這樣做大多是為了提高程序的非功能性屬性，從而提高代碼的質量。然而，即便是經驗豐富的敏捷開發者，在進行大規模的重構時也是如履薄冰。社區中的成員對掌控大規模重構的幾種方式進行了討論。
在最近的討論中，Andreas想要知道三種可能完成大規模重構的方法中哪種最好。他的方式包括，
- 一次完成——定義最終狀態的結構，然后將代碼一次完成。
- 分而治之——將一大團亂七八糟的代碼分為兩段，然后重復這樣的操作，直至完成……
- 壓制（Strangling）——壓制類
大多數回應者都認為“一次完成”幾乎不會成功的。Aaron Digulla指出他在整個職業生涯中一直使用壓制的方法。這種想法是要慢慢地將不好的代碼變為嶄新的優質代碼，并在過程中用測試來保證轉換的正確性。這種策略的優勢在于，因為你是從小片段慢慢開始的，因此風險很小。David Hall和Shane MacLaughlin強調了分而治之方法的重要性，但也要針對程序所有修改的部分編寫充分的測試。一些人建議完全推倒重寫，但是正如InfoQ之前的一篇文章所說的，那會讓你面臨一系列的挑戰。
Sibylle Peter和Sven Ehrke提到，他們使用的方法是，先對工作進行評估，然后為大規模的重構制定主要計劃。對于每個重構步驟，他們都會遵循以下三步：
另一種讓大規模重構得以進行的方法是“天皇牌”（Mikado）方法。回顧天皇牌方法的歷史，我們會發現它與Daniel Brolund和Ola Ellnestam所做的工作有關，而它的名字來自于天皇牌游戲。根據這個方法，
修改代碼就像進行天皇牌游戲一樣。當你想要對代碼庫做出修改時，幾乎無法以正確的方式做出準確的修改你需要做些準備、移動代碼、抽取類等等。我們很少會第一次就抓到天皇牌。更多的是，在“重構天皇”可用之前，你需要做一系列的變動，有條不紊地向你的牌堆的底部進發，以達到目的。
使用天皇牌方法，首先要記住最終的目的。對于任何需要重構的代碼，我們首先要創建一幅依賴圖，在上面寫下最終的目標。下一步是識別出想要達到目標所需要的直接前提，然后以這種方式繼續識別依賴關系，直到達到沒有任何前提或者依賴的葉子節點。這可能是開始重構最好的方式。一旦有了依賴關系圖，那么核心思想就是從葉子節點一步一步回溯，直到達到目標。
這種方法強調了撤銷操作的重要性，團隊不應該害怕因為回退而拋棄一些改變。他還建議不要停止分析，而應該從最基本步驟開始，然后理解順序。現在他們已經提供了關于“天皇牌”方法的書的草稿版本。
因此，大規模重構很難做，做好這項工作的關鍵在于要識別出起點，然后沿著路線小步前進。
查看英文原文：How To Do Large Scale Refactoring
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
