應用程序重寫 - 使用哪種開發方法？

Question

我正在準備重寫我們公司過去x年的軟件，而不使用任何框架，慣例或常識。結果是一個非常龐大，功能強大的應用程序，它只是維護，添加和修復的一個噩夢。

足以說，這是一種上應該是模塊化，多功能漂亮的報告，非常方便地配置（包括界面和後端）等

只要有這方面的要求類固醇訂貨系統對於模塊來說，其中大部分都與其他模塊完全互連...

現在我的問題是 - 哪種方法最適合使用？

我傾向於創建宏偉計劃，詳細規範，設計數據庫，爲老客戶編寫遷移腳本的'保守'方法，然後如果一切順利，坐下來開始按計劃編寫。

但是有人指出，要爲整個應用程序（特別是如此複雜）創建一個詳細和真實的計劃是非常困難的，然後就這麼做。有些人建議在我去的時候採用敏捷/迭代和增量方法，選擇一個模塊，爲它設計數據庫，編寫測試，創建後端和前端，然後開始下一個模塊...

這一切似乎要相當好，因爲我們在編寫時可能會有新的'想法'，但不會因爲將模塊彼此集成而不是從頭開始設計而更加痛苦？

如果任何人有任何類似的經驗，請給我幾個指示，指導我在一個正確的方向。

在此先感謝！

Answer 1

這裏有一些關於以前系統重寫的指針，我已經介入了，但是我們需要更多關於您的技術選擇，系統大小等方面的信息，以協助IMO的過程，設計和框架指導。

雖然舊的系統已經變形，但仍需要給予一定的尊重。它仍然有效（這很好 - 它給你時間來重建系統）。大多數情況下，我發現舊系統中的奇怪事情是由於某種原因而完成的。每當你遇到一些看似過分的東西時，你需要弄清楚這個理由（或基本原理）在完全拋棄之前是否仍然有效。

如果可能的話，避免大爆炸，儘量使用新系統 - 嘗試分階段策略，例如，看看你是否可以以並排模式進行生活，某些類別的產品是否會上線等等。另外，如果你可以在舊數據庫中進行搶救/生活，你甚至可以擁有讓駕駛員用戶在任一系統上工作。

數據遷移至關重要。請記住，您的交付物不是遷移的數據庫，它是一系列應該能夠在任何時間點執行的腳本，並且如果您有大量數據，則需要優化腳本以儘可能快地運行，因爲在從舊系統切換的過程中，業務將無法訪問任一系統。爲遷移數據制定一些測試計劃，這些計劃重複檢查所有數據是否已遷移，金錢價值是否平衡等。

屏幕 - 根據您擁有多少用戶，請記住，更改屏幕可能需要重新培訓用戶，這往往會促使你保持與應用程序類似的外觀和感覺。

因爲聽起來應用程序是'內部'的，所以規範文檔過於正式可能是矯枉過正的（你是否需要從任何人簽名？），但是，記錄舊系統的所有功能是一個好主意（因爲舊系統上的任何文檔都可能過時）。在新系統中，記錄設計過程中決策的所有基本原理 - 將所有需求和設計文檔，電子郵件和模型保存在源代碼控制中，或者更好地保存在Sharepoint等文檔管理系統中。

祝你好運！

Answer 2

敏捷是更好的方法。

使用面向對象的方法和設計模式來規劃和實現你的模塊。當你完成所有模塊的所有任務時，優化整個系統結構將會更容易。

而且使用敏捷方法可以完成系統的優化，使用面向對象的方法和設計模式構建系統。

Answer 3

除非你已經做了幾次這樣的重構，如果你做的是正確的事情，那麼計劃會給你完成的中間點和重新考慮的點，迭代聽起來好多了，好多了。即使你有，也有反對重頭開始的有力論據。 Joel Spolsky有一個article on the idea of restarting from scratch。我認爲我沒有太多補充。

Martin Fowler在Refactoring上寫了一本好書，非常值得關注這類工作。

Answer 4

我同意拉斐爾奧西波夫。

使用面向對象的設計，因爲它有助於保持一切都在自己的位置。

並使用敏捷方法，因爲您會做小而快的實現。

而且還要求用戶不斷反饋。

Answer 5

敏捷對於小型和擺脫錯誤的早期增量，因爲這是一個大型系統。

另外，別人說什麼。我想指出一篇指導性文章here。