重點摘要#
- 區分本質複雜度（Essential Complexity）與偶發複雜度（Accidental Complexity）
- 架構師的職責是解決本質複雜度中的問題，同時不引入偶發複雜度
- 過度工程化的框架往往增加的複雜度比它們解決的還多
- 優先選擇從實際程式碼衍生出的框架，而非象牙塔式的設計
詳細內容#
本質複雜度 vs. 偶發複雜度#
本質複雜度代表問題本身固有的困難度。例如，協調一個國家的空中交通管制就是一個本質上複雜的問題——每架飛機的位置、速度、方向都必須即時追蹤。
偶發複雜度則是我們在試圖解決本質複雜度時額外引入的複雜度。例如，現今的航空管制系統本身就引入了自己的複雜性，導致系統難以更新，許多地方仍在使用超過 30 年的技術。
許多框架和廠商「解決方案」其實是偶發複雜度的症狀。解決特定問題的框架是有用的，但過度工程化的框架增加的複雜度比它們消除的還多。
開發者與複雜度的關係#
開發者天生被複雜度吸引，就像飛蛾撲火一樣。解謎很有趣，但在大型軟體中，移除偶發複雜度同時保留對本質複雜度的解決方案才是真正的挑戰。
如何避免偶發複雜度#
- 優先選擇從實際運作的程式碼中衍生出的框架
- 檢視程式碼中直接處理業務問題的比例 vs. 僅服務於應用程式與使用者之間邊界的比例
- 對廠商方案保持警覺——它們本身不一定是壞的，但往往會推入偶發複雜度
- 確保解決方案符合問題的規模
架構師的職責是解決本質複雜度中固有的問題，同時不引入偶發複雜度。
— By Neal Ford