為什麼系統架構這麼難 https://medium.com/@ozanani/software-architecture-is-hard-7… — 矽谷牛的耕田筆記

矽谷牛的耕田筆記@technologynote · 615 subscribers Open in TelegramOpen

為什麼系統架構這麼難
https://medium.com/@ozanani/software-architecture-is-hard-71fe3ddafb60

作者敘述自己有一段時間一直被附近施工的聲音吵醒，因此起了搬家的念頭，為了確保搬家地點不會被施工聲音給干擾，於是作者去尋找該施工相關的文件報告，一看發現對方文件寫得非常清除，未來三年的施工計畫，每個地區估計的時間點都寫得非常明瞭，即使完全不懂都市工程的人都有辦法輕易閱讀。

作者就開始思考，那為什麼軟體架構方便則沒有辦法這麼清晰地去描述？
原因可能有
1. 團隊內負責架構設計的人能力不均
2. 大家對於架構的理解不同，撰寫出來的內容與抽象層度也不一定完全相同
3. 對於非功能面的理解，如 Reliability, Security. Privay, Scale 等不同，因此撰寫的東西也都不同

而過往很常見的作法則是採取 Top-Down 的架構，團隊內會有一個專職的架構師，由該架構師去進行統一的架構設計與規劃，底下的工程團隊根據敘述與藍圖進行施工，這種運行模式下，架構師基本上就負責整個架構權責，包含設計與文件等。
然而現在逐漸有另外一種 Bottom-Up 的運行模式，採取的是去中心化的架構設計分案，讓團隊內所有的工程師一起設計架構，一起完善整個系統，而並非由單一的架構師說了算。

這種流程下，團隊內不同經驗的工程師會負責的不同的領域，譬如比較資淺的可以負責較小的元件設計，而資深的工程師則會設計更大的範疇。該流程希望可以達到
1. 讓所有工程師一起學習成長
2. 提升每個工程師對該專案與的掌握度
3. 消除單點故障（架構師）的影響
4. 團隊內共享更多知識

然後說得好聽實作難，實作上可能會遇到
1. 經驗不一的人設計出來的架構品質不一致，團隊內可能最後會產生出四不像的架構
2. 設計流程過多，不同人的接受程度不同。譬如整個流程過於繁瑣且過大的負擔，可能會讓工程師花費更多時間在處理這些設計而非真正的實作，反過來則有可能根本沒有涉獵過多設計，所料想的優點一個都沒有，因此尺度拿捏上非常難。

作者最後介紹了 C4 Model 的實作範例，推薦所有團隊都先嘗試基於 C4 Model 來描述自己系統的架構，先熟悉這種描述的方式以及理解分四種模型對於整個文件與架構帶來的幫助，熟悉後對於後續的各種流程才會加速並且更游刃有餘。