重點摘要#
- 偉大的軟體不是「建造」出來的，而是**「生長」**出來的
- 軟體失敗的最大預測因子是規模——從大型系統開始幾乎沒有好處
- 從最小的可運行系統開始，讓它隨著需求逐步演化
- 不要試圖一開始就設計一個完整的大型系統來「滿足或超越」所有已知需求
詳細內容#
作為架構師，你負責提供軟體系統的初始結構和安排。這些系統會隨時間成長和變化、需要被重構、需要與其他系統溝通——而且幾乎總是以你和利害關係人未曾預見的方式。即使我們被稱為「架構師」，從建築和工程中借用了許多比喻，但偉大的軟體不是被建造的，而是被培育的。
規模是失敗的最大預測因子#
軟體失敗的最大預測因子是規模。 從大型系統設計開始幾乎沒有任何好處，但我們都會在某個時刻受到這種誘惑。從大型設計開始的問題：
- 容易產生附帶複雜度和慣性
- 更容易失敗、更難測試
- 更容易變得脆弱、更可能有多餘的部分
- 更昂貴、更容易有政治問題
抵制試圖設計一個大型完整系統來「滿足或超越」所有已知需求的誘惑。擁有宏大的願景是好的，但不要做宏大的設計。
從小開始，逐步成長#
確保軟體系統能演化和適應的最佳方式，就是從一開始就讓它演化：
- 從一個小型可運行系統開始——預期架構中最簡單的可行版本
- 這個初始系統有很多好處：
- 更容易測試，表面積小因此耦合更少
- 需要更小的團隊，降低協調成本
- 更容易觀察其特性、更容易部署
- 在最早的時間點告訴你什麼可行、什麼不可行
- 對利害關係人來說更容易理解和觸及
不要將演化式方法與「丟掉需求」、「分階段交付」或「做一個用完即丟的原型」混淆。這是一種有意識的、漸進式的成長策略。
讓系統自己告訴你#
一個小型運行系統能教你很多大型架構文件永遠無法告訴你的事情——系統在哪裡難以演化、在哪裡容易固化、在哪裡可能會崩壞。設計你能設計的最小系統，幫助交付它，然後讓它朝著宏大的願景逐步成長。
設計最小的系統，交付它，讓它成長。你的利害關係人最終會感謝你的。
— By Bill de hOra