系統規劃（二）：技術選型別靠直覺，架構設計別靠天賦

技術選型別靠直覺，架構設計別靠天賦

一句話總結：技術選型要用數字說話，架構設計要用文件說話，兩個都不能靠「我覺得」。

結論先講：選錯技術的成本，是在專案中後期才爆發的——那時候換掉它的代價，大概是一開始好好選的十倍。

你有沒有遇過這種狀況：團隊裡某個資深工程師說「我們用 X 框架吧，很潮」，其他人也沒太多意見就通過了。三個月後發現 X 框架在你們的場景根本不合適，社群也沒有現成的解法，然後大家就在那邊硬幹、繞路、疊 workaround。

這不是技術問題，是決策流程問題。

技術選型：把「我覺得」換成「數字說」

技術選型的核心不是找到「最好的」技術——世界上沒有最好的技術，只有最適合你的。而「最適合」需要用結構化的方式來判斷。

評估的七個維度

做技術選型時，至少要考慮這些面向：

團隊熟悉度（權重：高）：學習曲線是真實的成本，別假裝不存在
社群與生態系（權重：中高）：文件品質、第三方套件、StackOverflow 上有沒有人回答
效能表現（依需求而定）：拿 benchmark 數字來看，不要用感覺
營運成本（權重：中）：授權費、雲端資源、維運人力都要算
供應商鎖定（權重：中）：被綁死的感覺，你上一段感情應該體會過了才怪
成熟度（權重：高）：有多少公司在 production 用過？你願意當白老鼠嗎？
招募難度（權重：中）：選了冷門技術，以後找人就是你的噩夢

決策矩陣：讓選型變成數學題

把候選方案放進表格，每個維度給分，加權算出總分：

維度（權重）           方案 A    方案 B    方案 C
團隊熟悉度（30%）        9         6         7
社群生態（20%）          8         9         7
效能表現（15%）          7         8         9
營運成本（15%）          8         6         7
供應商鎖定（10%）        9         5         8
成熟度（10%）            9         8         6
加權總分               8.35      7.00      7.30

數字不需要精確到小數點後三位，但至少讓決策有依據。比起「我覺得 A 比較好」，「A 的加權總分 8.35 勝出」明顯更有說服力。

ADR：把決策的「為什麼」記下來

每個重要的技術決策，都應該寫一份 ADR（Architecture Decision Record）。

ADR 的價值不在於記錄「我們選了什麼」，而在於記錄**「我們為什麼這樣選」**。因為半年後，當你或新同事質疑「為什麼要用這個」的時候，ADR 就是唯一能回答這個問題的東西。

一份 ADR 該有什麼：

背景：我們面臨什麼問題？
考量的方案：列出至少兩個選項，各自的優缺點跟風險
決策：我們選了什麼、為什麼
後果：這個決定帶來的好處跟代價

沒有 ADR 的技術決策，就像沒有判決書的法官——你做了決定，但沒有人知道理由，以後也沒辦法回頭檢視。

架構設計：不是畫圖，是讓所有人看懂

架構設計的目標很簡單：讓任何一個工程師讀完文件之後，都能理解系統的全貌跟設計決策。做不到這一點，你的架構文件就只是裝飾品。

高階架構圖：一張圖勝千言

先畫出系統最粗粒度的結構——用戶端、負載平衡、API Gateway、各個服務、資料庫、快取、訊息佇列、背景工作。不需要把每個 function 都畫上去，但整體的「資料怎麼流動」要一目了然。

重點是：這張圖是溝通工具，不是技術文件。 如果你的架構圖需要花十分鐘才能看懂，那就是畫得太複雜了。

元件拆分：每個方塊都要有主人

架構圖上的每個元件都需要回答四個問題：

它負責什麼？（職責）
用什麼技術做的？（技術棧）
誰負責？（擁有者）
它依賴什麼？（依賴關係）

回答不出這四個問題的元件，代表你還沒想清楚。

API 先行：前後端不要各寫各的

在開始寫 code 之前，API 規格就應該定好。為什麼？因為前後端通常是平行開發的，如果 API 介面沒有事先對齊，到了整合階段就會發現「你給我的跟我以為的完全不一樣」。

API 設計至少要涵蓋：

端點清單：每個 API 的 method、path、request/response 格式
錯誤碼規範：統一的錯誤格式
版本策略：URL versioning 還是 header versioning

詳細的 API 設計原則，可以看 API 設計與認證機制那篇。

資料庫設計：別忘了未來的自己

資料庫設計的四個基本原則：

正規化：減少冗餘，但效能需要時可以適度反正規化
索引策略：根據查詢模式設計，不要亂加也不要不加
分區策略：資料量大的表，提前規劃分區方式
備份與復原：定期備份是基本，但你有驗證過復原流程嗎？

最後一點特別重要。很多人有備份但從沒試過復原——這就像買了保險但沒確認過理賠流程，等到真的需要的時候才發現不能用。

Technical Spec：你的架構設計交付物

架構設計階段的最終產出是 Technical Spec。它跟 PRD 的關係是：PRD 說「做什麼」，Tech Spec 說「怎麼做」。

一份及格的 Tech Spec 包含：

對應的 PRD 或 User Story 連結
架構設計（圖 + 文字說明）
API 規格
資料模型（含 schema）
關鍵設計決策（或連結到 ADR）
安全考量
測試策略
部署計畫
時程估算

是不是覺得很多？但這些東西你遲早都要想，差別只在於你是在寫 code 之前想好，還是在寫 code 的過程中邊撞牆邊想。前者叫規劃，後者叫受苦。

這篇的重點回顧

技術選型用決策矩陣量化比較，用 ADR 記錄決策理由。架構設計從高階架構圖開始，拆解元件、定好 API、設計資料庫，最後產出 Technical Spec。

下一篇是這個系列的最終章——容量規劃、開發計畫跟上線，也就是「用數字算資源」跟「怎麼安全地把東西推上線」。

系列文章：

系統規劃（一）：需求收集
你在這裡 → 系統規劃（二）：技術選型與架構設計
系統規劃（三）：容量規劃、開發計畫與上線

Terry Yao's Blog

分類

目錄