Architecture Audit Methodology¶
概念概覽
審計流程¶
核心知識¶
審計流程¶
- 交叉驗證：對照設計文檔與實際代碼，識別設計假設與實作現況的 gap
- 四維分類：將 findings 分為「確定 correctness bug / 容量假說 / 交付阻塞 / 平台技術債」，嚴格不混淆
- 工作流收斂：不把 findings 直接開票，而是收斂成有依賴關係的 WF（Workflow），明確 owner、順序、阻塞關係
簽核決策標準¶
- 容量簽核前提：WF-1（Reward Claim 統一）+ WF-2（Schema 補齊）完成，且 WF-5 benchmark 達標
- 不能因「功能尚未完整實作」而跳過容量/上線審核
關鍵區分¶
「設計文檔層面的問題」（schema 欄位缺失、查詢模型對不上）與「代碼層面的確定 bug」必須分開處理，優先級不同。
經驗教訓¶
-
確定 bug 與容量假說優先級不同，混淆會導致執行順序錯誤
-
17 個 findings 平鋪開票不如收斂成 5 個有依賴關係的工作流，執行排程更清晰
-
容量簽核是獨立 gate，不能在 schema/bug 問題未修前通過
常見陷阱¶
-
把「設計文檔描述的功能」當作「代碼已實作的事實」——審計時必須讀實際代碼
-
直接從 findings list 開票，缺少 blocking 關係導致並行執行時互相干擾
最佳實踐¶
-
每個 WF 明確標注前置依賴（如 WF-3 depends on WF-½）
-
四維分類後，correctness bug 優先、容量假說需 benchmark 驗證、平台債排獨立支線
相關概念¶
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Redis Sorted-Set TTL GC Capacity Bomb — 共享：
capacity-planning/ 獨特：event-system,game-server - PostgreSQL Write Capacity Planning — 共享：
capacity-planning/ 獨特：1m-ccu,database
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-31 | c903e4ed-15e4-4a39-b7b8-30b428e38075 | 建立「設計文檔 vs 實作代碼交叉驗證 → 四維分類 → 工作流收斂」的可複製審計框架 |