Gap Analysis：找出你以為做了但其實沒做的東西
一句話總結：規劃文件寫得再漂亮，如果程式碼裡沒有對應的實作，它就只是一份漂亮的廢紙。
結論先講：「規劃中寫了但沒實作」比「完全沒規劃」更危險——因為你以為有了，所以不會去注意，等到上線才發現少了一塊。
為什麼落差會存在？
在實務中，規劃與實作脫節的情況比你想像的常見：
- 規劃時覺得重要，開發時趕進度跳過了
- 以為別人會做，結果沒人做
- 規劃文件更新了，Proto 程式碼沒跟上
- 實作的時候發現技術難度高，暫時擱置然後忘了
這些落差不會自己消失。不定期檢查，就是在累積技術債——而且是你以為沒有但其實有的技術債。
四步驟找出所有落差
Step 1：列出所有規劃項目。從上一篇的 10 維度檢查清單開始，加上你的 Track 特有項目。
Step 2：逐項檢查程式碼。不只是「檔案存在」，是「功能完整且可用」。一個空的 auth/ 目錄不算「認證機制已實作」。
Step 3：分類每個項目。四種分類：
- Planned & Built：規劃有、實作完整。維護即可。
- Planned but Not Built：規劃有、沒有實作。需要補建。
- Built but Not Planned：實作有、規劃沒提到。補文件或考慮移除。
- Built but Incomplete：有實作但不完整。需要補強。
Step 4：排優先順序。安全（D）> 錯誤處理（E）> 容器化（C）的優先順序最高，因為直接影響生產環境。
一個實際的例子
以 Django Proto 為例：
| 面向 | 項目 | 落差分類 | 優先級 |
|---|---|---|---|
| E | GlobalExceptionHandler | Planned but Not Built | P0 |
| F | JSON 結構化日誌 | Planned but Not Built | P1 |
| C | Dockerfile 非 root 使用者 | Built but Incomplete | P1 |
| I | Swagger 文件 | Built but Not Planned | - |
| G | Testcontainers 整合測試 | Planned but Not Built | P2 |
P0 的東西這個 Sprint 就要做。P1 排進下一個 Sprint。P2 放 backlog。
怎麼防止落差再次出現
做一次 Gap Analysis 不夠，你需要一個節奏：
- 每月：快速掃一遍，確認沒有新的 P0 落差
- 每季：完整的 Gap Analysis，更新所有狀態
- 每次事故後：如果事故跟 Proto 的缺失有關（例如日誌格式不統一導致無法快速定位問題），立刻在 Gap Analysis 裡標記為 P0
這篇的重點回顧
Gap Analysis 用四步驟確保規劃等於實作。分類所有項目、排優先順序、定期執行。最危險的不是「沒規劃」，而是「以為規劃了但其實沒做」。
系列文章：
- Proto 規劃（一）：為什麼需要 Proto
- Proto 規劃（二）：10 維度完整性檢查
- Proto 規劃（三）：各 Track 標準
- 你在這裡 → Proto 規劃（四）：Gap Analysis
- Proto 規劃（五）：多語言延伸與維護
「Gap Analysis 就像對帳——你不會想在年底才發現帳目對不上。」