SOLID 架構原則 × PD / RD / QA 角色分工 × Agentic SDLC——系統化建立可量測、可追溯、可改善的工業級開發生命週期。整合 Claude × Gemini × GPT 三模型分析，以 ISO / Google / OpenAI / NIST 官方文件為基準。
業界成熟的軟體開發流程不應只用「需求 → 開發 → 測試 → 上線」描述，而應設計成一個可量測、可追溯、可改善的生命週期系統。
可維護、可擴展程式碼的設計基礎
從探索到維護的完整生命週期
RACI 邊界與跨職能協作
AI Agent 融入開發全流程
DoD、DORA、SLO、安全門檻
Robert C. Martin（Uncle Bob）提出的五項物件導向設計原則，目標是防止程式碼產生 rigid（難以修改）、fragile（一動就壞）、non-reusable（無法複用）三大症狀。
Single Responsibility
一個 class / module 只有一個改變理由。禁止建立承載過多業務邏輯的「God Class」。
訂單處理應將「價格計算」「資料庫持久化」「發送通知」拆分為各自獨立的類別。
違反症狀：修改 A 功能導致 B 壞掉
Open / Closed
對擴充開放，對修改關閉。新增功能透過增加新程式碼，而非修改已通過測試的既有邏輯。
依賴多型（Polymorphism）與介面（Interface）架構設計達成。
違反症狀：新需求必須改動既有邏輯
Liskov Substitution
子類別可完全替換父類別。禁止修改父類別既有的不變行為或拋出未預期 Exceptions。
確保繼承體系在語意上完全相容。
違反症狀：繼承後行為不可預測
Interface Segregation
客戶端不應依賴不需要的方法。將臃腫的通用介面拆分為多個職責單一的微型介面。
將 MultiFunctionPrinter 拆為 Printer、Scanner、Fax。
違反症狀：Fat interface，大量空實作
Dependency Inversion
依賴抽象，不依賴具體實作。高層模組不應直接 new 低層具體實現，透過抽象介面 + IoC / DI 管理依賴。
落地方式：優先使用 Dependency Injection 容器。
違反症狀：難以替換 DB / third-party
| 原則 | Code Review 檢查問題 | 重構觸發條件 |
|---|---|---|
| SRP | 這個 class / module 是否只有一個改變理由？ | 修改一處邏輯連帶影響多個不相關功能 |
| OCP | 新增行為時能否透過擴充而非修改核心邏輯？ | 每次新增功能都需修改多處現有程式碼 |
| LSP | 子類型是否能安全替代父類型而不破壞行為？ | 繼承後出現 if instanceof 判斷 |
| ISP | 呼叫方是否被迫依賴不需要的方法？ | 介面中出現大量空實作（throw not implemented） |
| DIP | 高層政策是否依賴抽象，而非直接依賴低層實作？ | 高層模組直接 new 具體資料庫 / 服務 |
避免過度抽象（Premature Abstraction）：先解決業務問題，再 refactor 對齊 SOLID 原則。不要為了套 SOLID 而過度抽象；以可讀性、測試性、變更頻率為判斷依據。SOLID 是目標，不是教條。
ISO/IEC/IEEE 12207:2026 將軟體生命週期涵蓋 conception → development → operations → support → retirement，並明確可套用於 Agile，但不強制指定單一開發模型。每個階段需定義責任人、輸入、輸出、品質門檻。
分析市場與用戶痛點，界定核心商務目標，定義 MVP 範疇。輸出：Problem Statement、Target User、Success Metrics、Scope/Non-scope、Prototype / Flow。可用 Google Design Sprint + HEART Framework
技術選型、Schema Design、Threat Modeling（Secure by Design）。輸出：ADR、API Contract、Data Model、Sequence Diagram、Threat Model、Test Strategy
將需求拆解為 User Stories 與 Backlog，排定迭代時程。共同定義 Definition of Ready 與 Definition of Done。ISO/IEC/IEEE 29148:2018 規範需求工程流程
功能實作、API 定義、單元測試、Code Review。2026 普遍引入 AI Pair Programming。PR 必須通過 lint / type-check / unit test 才可 merge
多層級自動化測試、Regression 防護、資料隱私合規掃描。ISTQB CTFL v4.0：測試活動可迭代並行，不應簡化為「最後測一下」
CI/CD Pipeline 自動化上線，部署生產環境 Telemetry 監控（log / metric / trace / alert）。SRE / DevOps 準備 rollback plan、feature flag、SLO 告警
基於生產數據效能調優、Refactoring、弱點修補。Post-release review → 指標回饋 → 下輪探索。Incident Response + Postmortem
每個 Feature 的標準流程（GPT 報告 §11）：PD 定義問題 → PD+RD+QA 釐清需求 → RD 技術設計 → QA 設計測試策略 → RD 實作 + PR → Code Review 通過 → QA 驗收 → SRE 準備發布 → Feature flag 小流量 → 觀察指標 + Post-release review
專業分工（Segregation of Duties）與共享責任（Shared Responsibility）的動態平衡是成功關鍵。每個角色有核心職責，也有「不應承擔的錯誤責任」。
| 角色 | 核心職責 | 核心交付物 | 不應承擔 |
|---|---|---|---|
| PD / PM / PO | 定義問題、使用者價值、目標指標、需求優先級、驗收條件 | PRD、User Story Map、Wireframe、Success Metrics | 指定低階技術實作細節 |
| UX / Design | 使用者流程、互動設計、可用性驗證、設計規格 | Prototype、Flow Chart、Design Spec | 只在開發後補 UI |
| RD | 架構設計、技術拆解、實作、單元測試、可維護性、效能與可觀測性 | Source Code、ADR、API Spec、Unit Tests | 需求不清時盲目開發；繞過 QA gate |
| QA | 測試策略、風險分析、測試設計、自動化測試、驗收把關、缺陷分析 | Test Plan、Automation Scripts、Bug Report、Quality Dashboard | 只做開發後手動點擊測試；替 RD debug |
| SRE / DevOps | CI/CD、部署、監控、SLO、Incident Response | Pipeline、Runbook、SLO Dashboard | 成為所有線上問題的唯一責任人 |
| Security | 威脅建模、資安需求、供應鏈安全、弱點管理 | Threat Model、Security Test Cases、SBOM | 只在上線前掃描一次 |
| 工作項目 | PD / PM | RD | QA | SRE | Security |
|---|---|---|---|---|---|
| 產品目標與成功指標 | A/R | C | C | I | I |
| 使用者研究與需求探索 | A/R | C | C | I | I |
| PRD / User Story | A/R | C | C | I | C |
| 驗收條件 | A/R | C | C/R | I | C |
| 技術架構 | C | A/R | C | C | C |
| 測試策略 | C | C | A/R | C | C |
| 實作與單元測試 | I | A/R | C | I | C |
| Code Review | I | A/R | C | I | C |
| CI/CD Pipeline | I | C | C | A/R | C |
| Release Go/No-Go | A | R | R | R | C |
| Incident 事故處理 | I | R | C | A/R | C |
| Postmortem 事後檢討 | C | R | C | A/R | C |
Shift-Left Testing（左移測試）：QA 需在 PD 釋出 PRD 初稿階段即介入審查，從測試視角找出邏輯漏洞。採用 Shift-Left 的團隊非計劃性工作減少 22%，可將 49% 時間用於新功能開發（vs 傳統團隊 38%）。
| 需求品質 | 合格標準 |
|---|---|
| 明確性 | RD 與 QA 能用同一理解拆任務與測試 |
| 可驗收 | 有可觀察結果（Given / When / Then 格式） |
| 可測試 | QA 能設計測試條件與邊界案例 |
| 可追溯 | 可回連產品目標、設計稿、測試案例、發布紀錄 |
| 有邊界 | 明確列出 non-scope 與例外情境 |
Google Engineering Practices 定義 Code Review 目的是維持程式碼與產品品質；ISTQB 強調測試流程可依情境調整，且應前移到需求與設計階段。
| 層級 | 責任主體 | 目的 | 工具示例 |
|---|---|---|---|
| Unit Test 單元測試 | RD 主導 | 驗證函式、class、module 行為 | Jest / pytest / JUnit |
| Integration Test 整合測試 | RD + QA | 驗證服務、DB、外部 API 整合 | Testcontainers / Supertest |
| Contract Test 契約測試 | RD | 驗證服務間介面相容性 | Pact / Spring Cloud Contract |
| E2E Test 端對端測試 | QA + RD | 驗證核心使用者流程 | Playwright / Cypress |
| Exploratory Test 探索式測試 | QA | 找出規格外風險與體驗問題 | 手動 + Session-Based |
| Performance Test 效能測試 | QA + SRE | 驗證延遲、吞吐、資源使用 | k6 / Locust / JMeter |
| Security Test 安全測試 | Security + RD | 驗證弱點、權限、資料保護 | OWASP ZAP / Burp Suite |
| Gate | 必要條件 |
|---|---|
| PR 前 | 需求明確、任務可驗收、影響範圍清楚；有 Definition of Ready 確認 |
| PR 內容 | 小批量（單一目的）、附測試、附說明；AI 生成程式碼與人寫同等對待 |
| Code Review | 至少一位熟悉模組的人審查；檢查 design / functionality / complexity / tests / naming（Google 準則） |
| 自動檢查 | lint / type-check / unit test / security scan 通過；Coverage 達標；未通過自動封鎖 merge |
| QA 驗收 | 關鍵路徑與風險場景通過；探索式測試執行 |
| 發布前 | rollback plan / feature flag / 監控指標 / 告警設定完成；SBOM + 簽章 |
品質指標不只是覆蓋率：測試覆蓋率被當作唯一指標會被遊戲化。應搭配 Escaped Defects（逃逸缺陷率）、Defect Reopen Rate（缺陷重開率）、Flaky Test Rate（不穩定測試率）綜合評估品質。
NIST SSDF SP 800-218 建議將安全軟體開發實務整合進任何 SDLC；OWASP SAMM 提供安全成熟度模型。安全不是上線前補掃描，而是每個階段都有控制點。
| SDLC 階段 | 安全控制 |
|---|---|
| 需求 | 資料分類（PII / 機密 / 公開）、權限模型設計、合規需求確認（GDPR / 個資法） |
| 設計 | Threat Modeling（威脅建模）：識別攻擊面、攻擊者、威脅行為；設計防禦措施 |
| 開發 | Secret scanning（禁止硬編碼 API key）、SAST 靜態分析、dependency scanning（供應鏈安全） |
| 測試 | AuthZ / AuthN 驗證測試、輸入驗證測試、OWASP Top 10 測試案例 |
| 發布 | SBOM（軟體物料清單）、Artifact 簽章、部署審批、Artifact Registry 存取控制 |
| 營運 | 弱點修補 SLA（高危 <7 天）、Incident Response 計畫、Audit Log、定期滲透測試 |
2025–2026 年關鍵轉變：從工具導向的 Copilot 轉向工作流整合的 Agent。Spec-Driven Development（SDD）將規格書作為 SDLC 的一等公民（first-class citizen）。
| 規則 | 說明 |
|---|---|
| AI 產出不得繞過 Code Review | AI-generated code 與人寫程式碼同等審查；不因「AI 寫的」而降低標準 |
| Repo 必須有 AI instructions | AGENTS.md（Codex）/ CLAUDE.md（Claude Code）或等效文件；定義工作協議、禁止操作、測試指令 |
| 必須明確列測試指令 | 讓 coding agent 知道如何驗證變更（Build / Test / Lint 指令） |
| 禁止讀取敏感資料 | .env、金鑰、客戶資料需 permissions allow/deny 控管；不靠自然語言「提醒」 |
| AI 修改需小批量 | 降低 review 與 rollback 成本；避免 AI 一次大範圍改動難以審查 |
| AI 只能輔助決策 | 架構選型、風險判斷、Release Go/No-Go 仍由人負責；critical script 建議三模型 audit |
過度依賴 AI 的風險：RD 直接接受 AI 建議而不理解底層邏輯，處理複雜新問題的能力會下降。研究顯示在需要創新解法的場景中，過度依賴 AI 會抑制創造力。AI 是增強工具，不是替代思考的機器。
程式碼設計哲學，驅動架構決策。這一層決定程式碼的長期可維護性。
Agile Sprint 迭代 + CI/CD 自動化。這一層決定交付速度與品質的可預測性。
AI 生成 + 人類 audit；不單模型 ship critical work。這一層決定 AI 時代的生產力槓桿。
DORA（DevOps Research and Assessment）歸納五個核心軟體交付績效指標；Google SRE 以 Error Budget 平衡可靠性與創新速度。指標應用於服務層級的持續改善，不應跨不同上下文硬比較。
| 類別 | 指標 | 目的 |
|---|---|---|
| DORA 交付 | Change Lead Time（變更前置時間）/ Deployment Frequency / Failed Deployment Recovery Time / Change Fail Rate / Deployment Rework Rate | 衡量軟體交付效能，識別瓶頸 |
| 產品 | Adoption / Retention / Task Success / 轉換率（Google HEART Framework） | 衡量產品對用戶的實際價值 |
| 穩定 | SLO 達成率 / Error Budget 消耗速率 / MTTR（平均恢復時間） | 平衡可靠性與功能交付速度 |
| 品質 | Escaped Defects / Defect Reopen Rate / Flaky Test Rate / Code Coverage（輔助） | 評估品質工程成效 |
| 安全 | 高風險弱點修補時間 / 依賴風險數 / Secret Leakage 次數 | 追蹤安全改善進度 |
| 團隊 | Review Time / WIP / Blocked Time / Retro Action 完成率 | 識別協作與流程瓶頸 |
整合三模型報告中共同指出的高頻反模式，是教學重點也是流程防雷點。
| 反模式 | 後果 | 正確修正 |
|---|---|---|
| PD 丟一句需求給 RD | 反覆返工，需求失真 | 需求需有驗收條件（Given/When/Then）、成功指標、non-scope |
| QA 最後才加入 | 缺陷晚期爆發，修復成本 10x | QA 參與需求與設計（PRD 初稿階段即介入） |
| RD 只追求實作完成 | 可維護性下降，技術債累積 | Code Review 加入設計（SOLID 檢查）與測試檢查 |
| 每次改動過大 | Review 困難、回歸風險高 | 小批量 PR；AI 任務也要小範圍、可驗證 |
| 覆蓋率被當唯一品質指標 | 指標被遊戲化，品質假象 | 搭配 Escaped Defects、Defect Reopen Rate、Flaky Test Rate |
| 沒有 SLO 與 rollback | 上線不可控，風險不透明 | 發布前定義 SLO、feature flag、監控告警、回滾策略 |
| AI 工具直接改大範圍程式 | 難審查、難追責、難 rollback | AI 任務必須小範圍、可驗證；與人寫程式碼同等 Code Review |
| 安全只在上線前掃描 | 修復成本高，系統性漏洞難修 | Threat Modeling 在設計階段；SAST + secret scan 在開發階段 |
| Context 越長越好（AI） | 效能下降、成本高、中段資訊遺忘 | 良好上下文管理；用 AGENTS.md 定義工作協議 |
| 過度套用 SOLID | 過度抽象，可讀性反而下降 | 先解決業務問題，以可讀性 / 測試性 / 變更頻率為判斷依據 |
最小可行制度：清楚需求、明確分工、小批量開發、強制 Code Review、自動化測試、可觀測發布、持續量測改善。（GPT 報告核心原則）
最終原則（GPT 報告 §14）：PD 對價值負責 / RD 對技術解法與可維護性負責 / QA 對品質策略與風險揭露負責 / SRE 對發布與可靠性負責 / Security 必須內嵌 SDLC / AI coding agent 必須納入同一品質門檻。