面對新的需求，工程師很容易先想到解法：換一個框架、加一層快取，或把服務拆開。但技術決策的第一步，通常應該是把問題描述得更精確。
先把症狀與原因分開
「頁面很慢」是一個症狀。它可能來自伺服器回應、資料查詢、過大的 JavaScript，或是在瀏覽器裡做了不必要的工作。
在選工具之前，先收集可觀察的資訊：哪個頁面、什麼操作、哪種裝置，以及等待發生在哪一段流程。
觀察：文章列表第一次開啟時等待較久。
假設：主要時間花在下載與解析程式碼。
驗證：比較網路時間、主執行緒工作與載入資源。
決策：根據證據減少對應的成本。
好的假設需要有被推翻的可能。否則我們只是替原本想用的工具找理由。
寫下真正的限制
同一個解法，在不同團隊可能有不同的成本。
- 團隊是否熟悉這個技術？
- 有多少時間可以維運？
- 資料規模是現在的需求，還是尚未發生的想像？
- 失敗時能否容易回復？
把這些限制寫下來，往往比列出框架優缺點更有幫助。
用簡單的決策紀錄保留脈絡
不需要每個選擇都寫一份長文件。對會影響後續工作的決策，保留幾個欄位就足夠：
| 欄位 | 要回答的問題 |
|---|---|
| 背景 | 我們遇到了什麼問題？ |
| 方案 | 考慮了哪些做法？ |
| 選擇 | 這次採用什麼，為什麼？ |
| 代價 | 接受了哪些限制與風險？ |
| 重看時機 | 什麼條件改變時要重新評估？ |
決策也需要到期條件
例如「文章數量超過目前的前端搜尋負荷時，再評估搜尋服務」，就比「先這樣做，以後再說」更有用。它讓未來的討論有共同起點。
保持選擇的可逆性
如果兩個方案都能解決當前問題，可以優先考慮依賴較少、遷移成本較低的方案。這不是永遠選最簡單的實作，而是避免提早承擔沒有必要的複雜度。
技術決策的品質，不只在於採用了什麼，也在於是否理解自己接受了什麼代價。