設計與程式碼是品質的核心#
軟體品質直接決定可靠性與效能，而設計與寫程式是品質的兩個源頭。SDLC 的核心也圍繞這兩件事。
設計的三個層次#
- 介面設計（Interface design）：高階設計，只關注外部輸入與終端使用者，忽略內部結構
- 架構設計（Architectural design）：定義系統各主要元件與彼此通訊
- 詳細設計（Detailed design）：每個元件規格、資料流、介面細節都要明確
設計是「問題」與「解法」的橋梁，是 SDLC 中最關鍵的一個階段。
軟體設計的最佳實踐#
- 分解每個元件：把系統拆成更小的服務、API、儲存、防火牆、負載平衡器、外部整合等元件，逐一設計與通訊。讓系統能隨需求成長與變更
- 平台不可知（Platform agnostic）：盡量讓底層架構與選擇的雲端平台解耦，未來搬遷時改動最小
- 建立原型（Prototyping）：先做小型原型驗證關鍵概念，發現失敗後在 SDLC 早期修補；對大型系統需評估時間與複雜度
- 非功能性需求（Non-functional requirements）：把效能、擴充性、可維護性與可獲利性等需求納入設計，因為它們會塑造架構與服務行為
設計階段每多花 1 小時釐清資料流、邊界與非功能需求，後期就少 10 小時的事故救火。
Figure 7.1: Software design best practice
程式碼最佳實踐#
- 架構先行：好程式始於好設計；功能性需求與非功能性需求要並列
- 程式碼審查（Code reviews）：清楚定義命名規範、不允許硬編碼、抽出動態值等規則，違反者退件重寫
- 撰寫測試案例：開發者自寫單元測試擴大覆蓋率，雖然單元測試無法提供端對端視角，但能讓小段程式可控
- 效能測試：屬於 QA 或 SRE，但要納入 SDLC 的標準測試流程
- 文件：對每項服務記錄輸入、輸出、資料流圖、排錯指引、使用者手冊；程式中加入扼要的功能註解
- 版本控制：避免多人協作衝突，需要回退時也方便
提升程式碼品質的習慣#
- 練習為每個元件做詳盡設計，幫助開發者掌握資料流
- 練習在程式入庫前進行 code review
- 練習補齊測試案例擴大覆蓋
- 練習規劃非功能性需求，從外部視角看系統
- 練習建立跨團隊的回饋迴路，縮短缺陷修補與恢復時間
Figure 7.2: Software development best practice summary
案例：銀行軟體新功能上線#
一家銀行軟體要上線重要新功能。架構師按業務需求把功能拆成多個元件、設計資料流，並交付給開發。
- 每個元件設計：拆分後便於辨識非功能需求；工程團隊能在服務內加上 failover 與效能測試案例；功能能切成多支微服務並行開發
- 程式碼審查：senior dev review 抓出缺漏的關鍵設定與錯版本合併；不通過直接退件
- 測試：DevOps 把自動化測試掛進 CI/CD，提早抓 bug；QA 進行更廣的整合測試
- 部署上線：SRE 監控發現新功能很少出問題；服務具備自動 failover 與重試
雖然 SRE 仍偵測到一些問題，但設計與開發的最佳實踐已大幅降低營運壓力。
把品質的責任前移到設計與程式碼，是 SRE 最划算的「投資」。系統永遠不可能完美，但能少出包就少耗 SRE 心力。
