用於重建傳統應用程序的策略

我有一個新任務即將推出，我已經在.NET WPF中重新構建了一些遺留COM應用程序。如果可能的話，我需要重新使用功能或存在代碼，但是我懷疑這個範圍是有限的。用於重建傳統應用程序的策略

我需要複製現有的功能，但需要使用現代和可擴展的體系結構來實現它。

有沒有人有任何接近這種類型的項目的一般建議？這個問題上有沒有好的資源？

是否有任何經過驗證的技術或普遍的pifalls？

來源

2009-08-22 Steve

我目前正在做幾乎這個確切的事情。

我能給的最重要的建議是重新規範系統。如果您對將要交付的產品沒有一個全新的期望，那麼您將會遵循舊系統的標準。這些標準不會很好，否則你不會重寫它。

從使用當前系統的人中確定他們實際上想要完成什麼，並且建立了那，而不是一個直接的端口。從長遠來看，參與的每個人都會過得更好。

簡而言之，不要在此過程中添加功能。在您重新構建應用程序之後，這個機會就會來臨。做港口時沒有什麼比接受與現有功能相矛盾的新要求更糟。

來源

2009-08-24 01:47:27

在那裏，做到了 - 我參與了從「規範」（好，有點）重寫一百萬行代碼程序（4GL和C的混合）：它不便宜也不快，結果是值得懷疑的是（爲了取得不錯的結果，又進行了一次重寫）。 – MaD70 2009-10-21 16:33:41

另外：由於系統不符合當前的要求，所以並不總是移植遺留代碼，作爲改變/改進的前奏。有時進行移植是因爲以下平臺過時且維護成本高昂，但是您的軟件系統仍然具有很大的價值。 – MaD70 2009-10-21 17:30:19

最重要的是自動驗證（又稱單元/功能測試）。請參閱this question。因爲很多建議都是simillar。通過這個我並不是指爲新系統編寫測試，我的意思是編寫測試傳遞給舊系統，並且將通過新系統。這將是你將如何驗證你已經重新創建了原始功能。我認爲在一個已經存在的系統中，你可以很容易地（雖然單調乏味）以BDD的風格創建functional specs that could be executed。

來源

2009-08-22 10:19:04

+1：測試驅動的逆向工程。 – 2009-08-22 11:32:39

IT行業對驗證過程的依賴是完全動態的，非常不完整的，沒有很好地建立起來（即通常進行測試的方式）對其產品質量而言是災難性的。我們做了什麼？（我們是否做出正確的事情？），即產品是否做用戶真正需要的東西？）但是對於驗證很弱*（「我們做了什麼？我們試圖製造？「，即產品是否符合規格？）。我知道，時髦的方法蔑視規範，但我認爲他們誤解了規範。 – MaD70 2009-10-21 17:20:23

我同意規格非常有效，但他們正在呼吸。迄今爲止我所遇到的大多數非當前規格都在IT相當於石材的片劑。目前以與軟件本身相同的代碼對它們進行編碼的方式會隨着更適合的工具的出現而通過。 – 2009-10-21 20:02:55

我想說一個常見的陷阱是試圖修復那些沒有被破壞的東西。考慮如何重新使用現有的軟件而不是重新發明它。如果它已經存在了很長一段時間，這可能是因爲它運行得非常好。您將面臨一項艱鉅的任務，以匹配沒有引入新bug的功能。

再次，這可能是因爲你的公司超過了這個遺留系統。想一想爲什麼要你重新設計這一點，以及你需要解決的舊問題有什麼限制。

來源

2009-08-22 10:35:49 tchen

請記住，當您部署新重新構建的系統時，您很可能不得不將整個數據堆從舊的轉換或移植到新的。當你走時考慮這一點，因爲如果你不這樣做，那麼這項工作就會變得和你的重寫一樣大。如果轉換不好，無論可靠還是有效，都可能會在第1天即將推出新系統，即使該功能已被發現。

來源

2009-08-22 10:40:59

Michael Feathers：Working effectively with legacy code提供了許多技術來處理和替換遺留代碼。我發現它很可讀;一些方法（以及許多黑客）對我來說是新手。

來源

2009-08-22 10:56:14 mfx

作者是Michael Feathers - 否則我同意這本書很好，但它特別涉及獲取遺留代碼，而不是從頭開始重寫它的技術。 – 2009-08-23 08:15:44

感謝您的注意，我固定了名稱。 – mfx 2009-08-23 19:51:35

仔細考慮你的目標。你只是想替換COM基礎嗎？您是否也要更改數據庫實現（例如，從索引到SQL？）屏幕（從GUI到Web？）...？

如果這是一個非常小的應用程序，可能會完全用手重寫它。如果大小適中，您可能可以修改現有的應用程序（大概是用一些其他等效的方案替換COM設施）。如果這是中到大的話，你實際上不可能在合理的時間範圍內可靠地重寫或修改它。

對於如此大規模的更改，您可能需要考慮自動化更改。實現這種變化的工具可以在這裏找到：DMS Software Reengineering Toolkit。對於擁有800K SLOC C++代碼的客戶，使用DMS，我們實現了C++到C＃轉換程序的大部分功能，該功能用等效的C＃工具代替了COM接口（鳥籠管理混洗約3/4通過項目失去了興趣譯者儘管接近完整）。

當你這樣做時需要考慮的一件事：在不改變功能的情況下，專注於現代化應用程序。通常管理層無法抵擋範圍蔓延（「好吧，當我們在那裏時，讓我們改變應用去做......」），這是通向災難的道路。請記住，做出所有導致當前問題的變化需要花費數年時間。

來源

2009-08-22 11:18:58

用於重建傳統應用程序的策略

回答

相關問題