重點摘要#
- 系統的維護從長遠來看會消耗比初始開發更多的資源
- 初始開發階段走的捷徑會在日後產生顯著的維護成本
- 將現有系統強行用於不適合的用途是嚴重的架構錯誤
- 發現架構缺陷時應立即修正 – 拖延越久，利息支付越高
詳細內容#
維護成本遠超開發成本#
在架構一個系統時，記住一個重要事實：維護從長遠來看會消耗比初始開發更多的資源。在初始開發階段走的捷徑可能導致日後顯著的維護成本。
跳過測試的代價#
例如，你可能聽說單元測試不能直接創造價值，於是告訴開發者可以跳過嚴格的測試。這會導致：
- 交付的系統在未來更難以變更
- 做出變更時信心降低
- 系統需要更多手動測試來驗證較小的變更集
- 導致脆弱性增加和維護費用升高
- 設計品質不如經過完整測試的設計
一個嚴重的架構錯誤是強行將現有系統用於不適合的用途，僅僅因為「使用現有系統可以降低成本」。例如，使用 BPEL 架構元件加上資料庫觸發器來實作非同步訊息系統。在需求明確需要訊息架構的情況下，一開始就應該選擇正確的架構。
及時修正錯誤#
除了在初始開發階段避免走捷徑，及時糾正發現的設計缺陷同樣重要。設計不良的功能可能成為未來功能的基礎，使日後的糾正行動更加昂貴。
例如，如果你發現選用了不適當的函式庫，應該儘快替換它們。否則為了讓它們適應不斷演變的需求，你會需要額外的抽象層來隱藏前一層的不良匹配。你正在為自己建造一團糾結的麻線球 – 每加一層就更難解開。
作為架構師，當你遇到架構問題或設計缺陷時，堅持立即修正，趁現在修正最便宜的時候。你拖延得越久，利息支付就越高。
— By Scot Mcphee