Spec-Driven Development 是什麼？

 

用「規格」驅動開發，而不是靠感覺寫程式

在實務開發中，你是否遇過這些狀況：

  • 功能寫完才發現「跟需求理解不一樣」

  • PM 說「我以為你知道我要的是這個」

  • 文件寫了，但從來沒有人照著文件實作

  • API 文件永遠落後實際程式碼

這些問題的核心，其實都指向同一件事：
👉 規格（Specification）沒有成為開發的核心事實來源（Single Source of Truth）

而 Spec-Driven Development（規格驅動開發），正是為了解決這類問題而出現的一種開發思維與流程。

一、什麼是 Spec-Driven Development？

Spec-Driven Development（SDD） 是一種：

先定義「可驗證的規格（Specification）」，再依照規格進行實作、測試與驗證的開發方式

在 SDD 中：

  • 規格不是附屬文件

  • 規格本身就是開發依據

  • 程式碼必須滿足規格，而不是反過來

規格通常包含哪些內容？

依系統類型不同，Spec 可能是：

  • API 規格（OpenAPI / Swagger）

  • 行為規格（Given / When / Then）

  • 狀態轉移規格（State Machine）

  • 合約規格（Contract / Invariant）

  • Domain 規則（Business Rules）

重點不是「格式」，而是：

規格必須清楚、可討論、可驗證

二、Spec-Driven Development 怎麼使用？（實際流程）

以下是一個典型的 SDD 開發流程：

Step 1：先寫「規格」，不是先寫程式

例如 API 規格（OpenAPI）：

POST /orders
Request:
  {
    productId: string,
    quantity: number
  }

Response 201:
  {
    orderId: string,
    status: "CREATED"
  }

此時你還沒有任何 Controller / Service / DB Code。

Step 2：與利害關係人確認 Spec

  • PM：確認流程與欄位是否正確

  • 前端：確認 request / response

  • QA：確認邊界條件與錯誤情境

👉 規格就是討論的共同語言

Step 3：用 Spec 驅動實作

開發時：

  • Controller → 對應 Spec

  • Validation → 來自 Spec

  • Domain Logic → 不得違反 Spec 定義

很多團隊會：

  • 直接從 Spec 產生 API Stub

  • 或產生 Client SDK / Mock Server

Step 4：用 Spec 驗證結果

  • Contract Test

  • API Test

  • BDD 測試（Spec = Test Case）

👉 測試不是猜需求，而是驗證規格

三、Spec-Driven Development 的優勢

1️⃣ 降低需求誤解成本

規格是：

  • 明確的

  • 可閱讀的

  • 可驗證的

比起「口頭需求」或「模糊文件」，錯誤更早被發現。

2️⃣ 規格成為 Single Source of Truth

  • 不再有「文件一套、程式一套」

  • 規格 = 設計 = 驗收標準

3️⃣ 非同步協作能力大幅提升

前後端可以：

  • 同時開發

  • 用 Mock Server 對接

  • 不互相等待

4️⃣ 測試與驗證更自然

Spec 本身就能轉成：

  • API Test

  • Contract Test

  • BDD Scenario

👉 測試不是額外負擔，而是規格的一部分

5️⃣ 對大型系統、微服務特別友善

  • 合約清楚

  • 服務邊界明確

  • 版本控管容易

四、Spec-Driven Development 與傳統開發差在哪？

面向 傳統開發 Spec-Driven Development
開發起點 先寫程式碼 先定義規格（Specification）
文件角色 事後補寫，容易與實作不一致 核心依據，規格即事實來源
溝通方式 口頭說明或即時討論為主 以規格文件作為共同語言
測試來源 依開發者理解自行撰寫 直接驗證是否符合規格
變更成本 後期才發現問題，修正成本高 規格階段即可發現，成本較低

簡單一句話總結：

傳統開發是「程式碼導向」
SDD 是「契約導向」

五、Spec-Driven Development 的缺點與限制

SDD 並不是銀彈，實務上也有代價。

❌ 1️⃣ 前期成本較高

  • 需要時間寫 Spec

  • 需要訓練團隊閱讀與撰寫規格

👉 對小型、短期專案可能顯得「太重」

❌ 2️⃣ 規格寫不好，反而更痛苦

  • 規格過度抽象 → 沒用

  • 規格過度細節 → 綁死實作

👉 Spec 需要經驗累積

❌ 3️⃣ 需求頻繁變動時，維護成本高

如果需求：

  • 每天改

  • 邏輯尚未穩定

Spec 會一直被推翻，反而拖慢節奏。

❌ 4️⃣ 不適合探索型 / 原型階段

  • PoC

  • 快速試錯

  • 創意探索

👉 比較適合 需求已相對明確的系統

六、什麼情境特別適合用 Spec-Driven Development？

非常適合以下場景：

  • ✅ API / 微服務

  • ✅ 金流、訂單、帳務系統

  • ✅ 區塊鏈 / 跨鏈 / 協議型系統

  • ✅ 多團隊協作

  • ✅ 對正確性要求極高的系統

（這點其實非常符合你目前研究的跨鏈 / 協議 / Relay Chain 類型系統）

七、總結

Spec-Driven Development 的核心精神不是工具，而是一個觀念：

「先把系統要『做什麼』說清楚，再討論『怎麼做』」

它讓：

  • 規格 → 成為契約

  • 程式 → 成為實現

  • 測試 → 成為驗證

如果你曾經因為「需求不清楚」而反覆返工，
那 SDD 會是一個值得嘗試的開發思維。

留言

張貼留言

熱門文章