你如何處理設計變更？

Question

我剛剛在過去幾個月完成了一個項目的工作。它在線並準備好去。客戶現在回來了，或多或少地完全重寫了應用程序的大部分部分。已經起草了一份新合同併爲所涉及的額外工作付款。

我想知道什麼是開始重做這整個事情的最好方法。你會做的前幾件事是什麼？您如何重新設計這種設計，以確保您正在改變的內容不會破壞其他內容？

總之，你會如何應對效率大幅應用設計變更（包括DB和代碼）？

Answer 1

數據庫設計在這方面與應用程序設計不同。

很多時候，客戶端反思會徹底改變應用程序，但在企業的基礎底層數據模型中幾乎沒有什麼變化。這是因爲客戶傾向於考慮業務流程，而不是基礎數據。業務處理和數據處理緊密結合。數據存儲不太緊密。在經典的數據庫設計時代，設計師通過將其數據庫設計劃分爲（至少）兩層：邏輯設計和物理設計，學會了如何利用這種模式。有很多次業務流程的變化需要對應用程序進行完整的重寫，並對數據庫物理設計進行了重大修改，但對邏輯設計的更改（如果有的話）很少。

如果您的數據庫設計沒有將這些圖層分離出來，很難分辨哪些會受到影響，哪些不會。從你的表格和欄目開始。問問你自己，如果有任何改變需要從表格中刪除任何列，或需要發明新的列。如果答案是否定的，那麼你很幸運。接下來，看看數據庫上的約束條件（像PRIMARY KEY，FOREIGN KEY，UNIQUE和NOT NULL）。客戶的變化可能會加劇或放鬆這些限制。如果沒有，你很幸運。如果您沒有在數據庫中聲明任何約束，並且選擇在應用程序代碼中完成所有完整性保護，那麼您可能運氣不佳。

對於更改表上的索引以及應用程序處理數據的方式，您仍然需要做大量的工作。但是你已經挽回了舊系統的一部分投資。

應用程序本身比數據庫更容易受到客戶端進程更改的影響。如果您的數據庫設計完全由您的應用程序設計驅動，那麼您可能不太順利。

Answer 2

如果這是一個劇烈的變化，最好重新開始。我曾參與過一些經歷了重大變革的項目。

從頭開始讓你有機會使用體驗，因爲最後一個項目的經驗和提供一個比較有效的產品。

我會建議不要試圖重新工作舊址到新的網站，你可能會花更多的時間擺弄周圍改變的東西比你有，如果你剛剛重新寫的。

祝你好運！

Answer 3

您如何以某種方式重新設計設計，以確保您所改變的內容不會破壞其他內容？簡而言之，您將如何有效地應對激烈的應用程序設計更改（數據庫和代碼）？

測試，代碼複雜度/覆蓋率度量和持續集成系統。儘早且經常地運行它們，以便了解哪些部件最危險，以及從哪裏開始寫作。

這些將成爲你的安全網，當你必須做出潛在的問題變化。如果某件事情崩潰了，你的CI系統會告訴你，在你意識到存在問題之前，你將不會花費數週的時間在某個兔子洞中度過。

Answer 4

假設你有單元測試，這只是重構。

如果沒有到位的單元測試，然後

1. 編寫單元測試，你很可能會保留部分。

2. 編寫單元測試，你要改變的部分。

3. 運行測試。 「保持」應該通過。 「改變」應該失敗。

4. 開始重構直到測試通過。

Answer 5

這不是一個軟件中的新事物，人們已經做了這些，並且寫了很多關於這個的東西。

嘗試閱讀

• Working Effectively with Legacy Code
• Refactoring Databases: Evolutionary Database Design

這裏的技術解釋是非常寶貴的支持任何類型的長時間運行的IT項目。

Answer 6

有時候你會第二次做得更好，所以只要保持積極。此外，您將有更多的領域知識這一次。