jim800121/visionA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(architecture): DB 規劃淡化測試占比強調

Browse Source 
測試是工時的自然組成，不再特別強調占比 / 與業界對照：
- 移除前言「測試占比」獨立小節，併入估算假設（中性敘述）
- §5 標題去掉「測試占比分析」，§5.3 精簡為各塊測試 hrs 明細
- 移除「約 45% vs 業界 25-35%」對照句
- 保留實用建議（要砍先砍邊界、別砍 integration 與回歸）
工時數字全未動。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
jim800121chen 2026-06-16 20:20:11 +08:00
parent 46958200eb
commit 22f329cdf3
1 changed files with 15 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
docs/autoflow/04-architecture/db-integration-plan.md
View File

@ -25,9 +25,7 @@
> 區間下限 = 一切順利；上限 = 含 schema 細節踩坑與測試補齊。三種範圍皆已含「DB 基礎建設」與「一次 stage 驗證」。
### 測試占比
接資料庫需要完整的測試保障，測試占整體工時 **約 45%**（41%–48%），高於一般功能開發的 25–35%——因為接 DB 涉及 integration 測試（testcontainers 真 DB）、併發/連線失敗等邊界、以及既有 e2e 的回歸驗證。測試含三層（unit / integration via testcontainers / 邊界），詳見 §5。
> 各塊估算已含接 DB 所需的三層測試：unit、integration（testcontainers 真 DB）、併發/連線失敗等邊界，以及既有 e2e 的回歸驗證——這些是接 DB 的必要工程組成，詳見 §5。
### 兩個關鍵結論
@ -81,7 +79,7 @@
| **hours 已含** | 實作 + 三層測試 + 一輪 code review 修正 | 每塊獨立列「self-review + 過 Reviewer」子任務 |
| **hours 不含** | 跨團隊等待（拿連線資訊、他人開 DB）、需求變更、prod 另建 DB、CI 大改造意外 | 這些不可控、不放進工程估算 |
| **區間語意** | 下限 = 一切順利；上限 = 含 schema 細節（array、unique×soft-delete、hash key 切換）踩坑與測試補齊 | |
| **測試占比較高** | 約 45%（一般功能 25–35%） | 接 DB 需 integration + 邊界 + 回歸測試，屬必要工程成本，詳見 §5 |
| **測試範圍** | 含 integration（testcontainers）+ 邊界 + 回歸 | 接 DB 的必要工程成本，已含於各塊估算，詳見 §5 |
> **塊 0 第一次做最貴**：連線池、migration 機制、testcontainers、CI Postgres 都從零。完成後塊 1–3 每塊攤平、可偏區間低值。
@ -148,7 +146,7 @@
| 6 | stage 部署 + e2e 回歸 | 13–25 | **+1–2** | 14–27 | MySQL 版 migration 跑 + 版本特性確認（JSON 型別、collation、functional index 支援，取代 PG 的 `gen_random_uuid()`/CITEXT 確認） |
| | **全部加總** | 143–245 | **+17–31** | **160–276** | |
> delta 區間語意同主表：下限 = array/UUID/index 替代一次到位；上限 = JSON 序列化邊界、隔離級別行為差異、functional index 效能調校踩坑。測試估算框架沿用 §2/§5 既有原則（接 DB 的客觀整合/邊界/回歸測試需要），delta 中已含對應測試補齊、未額外拉高占比。
> delta 區間語意同主表：下限 = array/UUID/index 替代一次到位；上限 = JSON 序列化邊界、隔離級別行為差異、functional index 效能調校踩坑。測試估算框架沿用 §2/§5 既有原則（接 DB 的客觀整合/邊界/回歸測試需要），delta 中已含對應測試補齊、未額外灌入測試。
### 3.5.3 MySQL 版三種範圍累計（與 PG 版並列）
@ -306,7 +304,7 @@
---
## 5. 工時總表與測試占比分析
## 5. 工時總表
### 5.1 各塊 man-hours 總表
@ -331,23 +329,19 @@
> 三種範圍皆已含塊 0 與一次塊 6 驗證；中間範圍不重複計塊 6。最小範圍的塊 6 只跑 6.1–6.4（不含完整回歸 6.5），故取精簡值。
### 5.3 測試占比分析
### 5.3 各塊測試子任務 hrs
| 塊 | 測試子任務 | 測試 hrs | 該塊總 hrs | 測試占比（中位） |
|----|-----------|---------|-----------|----------------|
| 0 | 0.6+0.7+0.8 | 9–17 | 20–36 | ~46% |
| 1 | 1.5+1.6+1.7 | 10–17 | 22–36 | ~47% |
| 2 | 2.5+2.6+2.7 | 9–15 | 19–32 | ~47% |
| 3 | 3.6+3.7+3.8+3.9 | 13–22 | 30–49 | ~44% |
| 4 | 4.5+4.6+4.7 | 9–15 | 19–32 | ~47% |
| 5 | 5.5+5.6 | 7–11 | 20–35 | ~33% |
| 6 | 6.4+6.5 | 7–13 | 13–25 | ~53% |
| 塊 | 測試子任務 | 測試 hrs | 該塊總 hrs |
|----|-----------|---------|-----------|
| 0 | 0.6+0.7+0.8 | 9–17 | 20–36 |
| 1 | 1.5+1.6+1.7 | 10–17 | 22–36 |
| 2 | 2.5+2.6+2.7 | 9–15 | 19–32 |
| 3 | 3.6+3.7+3.8+3.9 | 13–22 | 30–49 |
| 4 | 4.5+4.6+4.7 | 9–15 | 19–32 |
| 5 | 5.5+5.6 | 7–11 | 20–35 |
| 6 | 6.4+6.5 | 7–13 | 13–25 |
- **純測試子任務加總**：64–110 hrs。
- **總工時**：143–245 hrs。
- **測試占比 ≈ 45%（中位）**，範圍 41%–48%。
> 一般功能「測試占 25–35%」是常態；本估約 45%，反映接 DB 所需的三層測試（integration/邊界/回歸）+ testcontainers 一次性基礎建設。testcontainers/CI 一次性基礎建設（塊 0 的 9–17 hrs）是大頭——做一次、後續所有塊共用。若日後評估「測試估太保守」，最先可砍各塊「邊界」子任務的卡關上限，但**不建議砍 integration 與回歸**（那是「重啟資料還在」的核心保證）。
> testcontainers/CI 一次性基礎建設（塊 0 的 9–17 hrs）做一次、後續所有塊共用。若日後評估要砍工時，最先可砍各塊「邊界」子任務的卡關上限，但**不建議砍 integration 與回歸**（那是「重啟資料還在」的核心保證）。
---