重構胖客戶端遺留應用程序

Question

我正在研究胖客戶端遺留的C++應用程序，這些應用程序有很多與事物的表示面混合的業務邏輯。我想清理一些問題並完全重構代碼，因此存在明顯的問題分離。我正在尋找MVC或其他合適的設計模式來實現這一目標。

我希望得到誰已經走之前，這條道路的人的建議 -

我用MVP或MVC（或其他方式）？

什麼是做這種事情的最佳實踐（即有用的步驟/檢查）？

Answer 1

無論您選擇哪種模式，最有用的步驟都是創建非常穩健和全套的迴歸測試。

爲了MVP和MVC之間進行選擇，請查看他們的分歧在這太問題：

What are MVP and MVC and what is the difference?

Answer 2

如果MVP對MVC是你的主要問題，你也許可以自由選擇。

影響該決定的因素有三個：您以前的經驗，對框架/庫的支持，以及哪種更適合現有代碼庫。

在我的epxerience中，這兩種模式都適用於C++傳統應用程序，例如結婚蛋糕上的貓嘔吐物。您的主要挑戰將是：

• 沒有破壞任何東西。哎呀，這可能不打破一切
• 注意到，你實際上是在前進
• 做與小的變化，不需要某些組件

---

其餘的三個月改寫處理遺留應用程序非常通用，與您的問題的細節無關。因爲你也有一個通用部分，所以我會把它留在這裏。

改寫與重構你已經說過你的決定，所以我只是提出了親重寫參數來考慮：如果你有一個明確的規範和理解用戶如何使用目前的這個程序，重寫可能會更快，更便宜當30％或更多的代碼需要更改時。 （這並不意味着「改寫一切」，這也可能意味着削減的應用程序只有邏輯，然後在它上面種植了新的表現層）

假設你去重構：

定義你的目標爲什麼你需要重構應用程序呢？很好的理由可能是要實現很多新功能，表示層需要被替換，或者爲了保持理智而需要更多的功能。從這個角度來看，決定需要改變的是什麼，並保持現狀。

你已經選擇了你的目標：MV *。我只想讓你從長遠的角度考慮客戶和代碼所有者的好處。

閱讀代碼。不，真的，請花時間習慣代碼庫。使用調試器進行調試。嘗試理解所涉及的事情。記下你認爲你應該改進的改進。

創建測試 - 主要是針對當前期望的行爲進行迴歸測試。使用遺留代碼庫時，它們通常比手動更不經常，所以創建一個白癡可以遵循的測試協議，並試圖抓住一個不經常犯這樣的錯誤，它可以隨時運行這些測試。嘗試從現有用戶獲取一些用例。

堅持小的可逆變化如果重構步驟出錯，它應該足夠小，可以毫不猶豫地被扔掉。有時候，這並不容易，我典型的最壞情況下的步驟是：
- 決定替換哪個功能。制定新代碼的外觀。 - 移動也適用於新的代碼 接口的後面的現有代碼 - 測試 - 與替代功能的新代碼 - 測試 - 有時，界面是「最終」，somethimes您可以刪除/酌減

總是提高不要接受「稍後可以修復」的功能障礙。

Answer 3

您應該看看Michael Feathers的「有效地使用遺留代碼」。本書概述瞭如何將現有代碼加入測試工具，以及如何安全地破解代碼中的依賴關係。