概念概覽
graph TD A[軟體架構] --> B[CI/CD 與版本控制] A --> C[前後端設計] A --> D[監控與日誌] B --> B1[持續整合/部署] B --> B2[Git 流程] B --> B3[Release 流程] C --> C1[後端 MVP 設計] C --> C2[前端 MVP 設計] D --> D1[泛用 Log 設計] A --> E[對服務的要求] A --> F[對團隊的要求]
為什麼要了解架構？
一般工作場域在啟動專案的時候，主要都會專注在怎麼做專案開發。但長期來看，其實不會只有開發上面的討論。
依比重來說，維運才是人力消耗最沉重的地方。
沒有好的 code base review，不論是開發或維運的角度，對整體的人力消耗會達到驚人的程度。常見的情境是開發人員去協助甚至主導 Infra 的議題，干涉導致 R&R 混亂。最好的狀況是重工，慘一點的 on-call 修機器根本家常便飯。
什麼是好的架構？
我們分成幾個主題來切入：
1. CI/CD 與版本控制
2. 前後端設計
3. 監控與日誌
對服務的要求
一個好的架構對服務來說，應該具備：
- 有固定部署頻率且可以被檢視
- 如果部署上遇到問題，怎麼復原或修復的流程團隊有共識
- 版本控制原則清晰
- 程式架構一致，或者有一致目標且正在進行
- 有辦法知道現在運行狀況
對團隊的要求
一個好的架構對團隊來說，應該具備：
- 有明確的角色責任定義
- 有意識地在培養替代人力
- 建立學習型組織