1. 首頁
  2. 問答
  3. 大規模重構策略

大規模重構策略

2008-12-01 55 views
22

我目前在一段代碼中，其中邏輯和數據訪問都存在於GUI類中。顯然，我想改善這種情況。大規模重構策略

目前的結構基本上是：

  • 大泥球

的最終目標是實現DDD狀結構：

  • DAL
  • 領域模型
  • 服務層
  • 演示模型
  • GUI

那麼，你會如何進攻的問題？

來源

2008-12-01 Andreas

回答

15

永遠不要嘗試「大爆炸」。它幾乎總是吹在你的臉上，因爲當一切都失敗時，這是一種高風險，絕望的措施。

分而治之：這個效果很好......如果你的世界只有兩面。在真正的軟件中，你必須同時征服這麼多的戰線，你幾乎不能承受黑白的幻想。

我想我在職業生涯中大部分時間都在使用「Strangling」這樣的東西：逐漸將不好的舊代碼轉化爲閃亮的新代碼。這裏是我的食譜：

從某處開始，它在哪裏並不重要。編寫幾個單元測試，看看代碼如何表現。瞭解它多久做一次你認爲它的作用，以及它多長時間不這樣做。使用您的IDE重構代碼，以便測試它。

第一天過後，猜猜你是否已經開始在正確的地方將這個怪物分開。如果是這樣，繼續。如果沒有，找到一個新的地方，並重新開始。

這個策略的優點：它的工作步驟很小，所以風險可以控制在一定的範圍內，如果有事情發生，如果必須在上週的代碼中。

缺點：需要花費很多時間，你會感到沮喪，因爲通常情況下，進度會顯得非常緩慢，直到「結」突然出現，突然間，所有東西都像魔法一樣開始落伍。

來源

2008-12-01 08:32:34

0

是完全重寫的選項？根據我的經驗，從頭開始重寫通常比試圖清理現有的混亂更有效。你冷漠仍然保留現有代碼的一部分，但在一個新的情況下。如果有的話，gui和數據庫也是一樣的。從頭開始重寫，隨身攜帶你可以使用的東西。

來源

2008-12-01 07:38:53

1

取決於您是否必須始終處於工作狀態，以便您可以在需要時進行錯誤修復和部署，然後Devide and Conquer將是一個很好的解決方案。如果您可以在維護舊代碼的同時開發新代碼（並且將代碼修復應用到代碼庫中），那麼重寫可能是更好的解決方案。

來源

2008-12-01 07:55:10

6

我從來沒有聽說過'Strangler Application'這個詞 - 我喜歡它。在可能的情況下，這總是一個很好的方法，它可以最大限度地降低風險，並且非常務實，一塊一塊削減大型建築物。

根據我的經驗，哪裏工作不正常是需要馬上進行合理的重大更改 - 需要一點重構（或大量黑客攻擊）的更改。在那種情況下，我經常發現我需要做的改變是在大泥球的中心，沒有其他選擇，但是變得骯髒 - 即使是標準維護或微小的增強改變也是可怕的，而且主要的重構是最好的選擇。

對於這些情況，我會用分而治之 - 我一直追求的第一個目標就是可測試性，一旦你讓所有其餘的都變得容易了。事實上，這通常是我從重大泥土中重構的主要驅動因素之一 - 這類代碼通常幾乎不可測試，希望有示例UI輸入和輸出，但有時甚至缺少這些代碼。

因此，當遇到代碼將所有內容都集中到UI中的情況下，我通常首先將分離的功能單元分解爲類和方法，然後將這些代碼部分推入域或服務層。一點點做，大大減少了打破某些東西的機會，並且可以更容易地指出事情發生錯誤時破壞代碼的位置。

在每次更改結束時運行任何可用的測試用例，並確保您仍然滿足某種基準。

如果你隨時編寫好的單元測試，你可以開始減小問題的規模，我發現採用扼殺者方法很快就會變得實用 - 通過合適的單元測試或者至少允許正確的框架允許體面的單元測試的寫作變得更加實用，逐漸取代部分功能。

來源

2008-12-01 07:56:09

1

如果通過重構，你的意思是在不修改功能的情況下改進代碼，我首先創建一個自動化的迴歸測試基線。有很多工具可以幫助解決這個問題。我使用TestComlete，雖然有很好的便宜替代品。

建立了一個迴歸測試基線後，我個人會隨着分而治之，因爲根據我的經驗，它最有可能成功。一旦你有了一個測試基準，那麼你選擇的方法就更少了。

來源

2008-12-01 08:00:53

-1

從一個乾淨的新架構開始，將代碼中的舊代碼逐塊移動到這個新的架構中，並重構它以適應新的拱架將是一個不錯的選擇。移動功能時我認爲採取自下而上的方法會很好。

來源

2008-12-01 08:08:14 Manoj

1

對我來說這取決於情況。

如果這是一個非常小的項目，我會試圖從零開始重寫它......但是你並不經常擁有這種奢侈品。

如果不這樣做，我會一塊一塊地去打碎它。我會編寫單元測試來驗證現有的功能，並慢慢地使用TDD將代碼轉換爲一個優雅且設計良好的系統。取決於這個過程需要多長時間，它可能會開始看起來像你上面提到的StranglerApplication。

BigBang風險很大，因爲您沒有簡單的方法來驗證更新後的系統是否與舊版系統執行相同的操作。

分而治之風險比BigBang風險小...但如果它的系統足夠大，它可能會像BigBang一樣存在問題。

來源

2008-12-01 08:41:30 mezoid

1

大爆炸/大重新設計/重寫SW ......或任何其他名稱將不適合生活SW。 原因是：

  • 你仍然需要支持（可能）你有同樣的資源，現有的SW。

  • 您可能沒有重寫的要求。您的舊代碼具有嵌入其中的所有要求。您的工程師都不知道所有的軟件領域和所有要求。

  • 重寫需要時間。在這段時間結束時，你會發現現有的軟件已經改變，以支持在這段時間內需要的東西。 你的新SW實際上是從原來的分裂和合並將需要（這也將需要時間）。

來源

2015-09-17 08:47:29

相關問題

 相關問題