Skip to content

fix(architecture): 数据流改为业务分叉到开发+测试并行 #23

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
JohnC-stack merged 1 commit into from
Apr 20, 2026
Merged

fix(architecture): 数据流改为业务分叉到开发+测试并行 #23

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 39 additions & 8 deletions ARCHITECTURE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,6 +88,8 @@ graph TB

## 二、数据流图 · Markdown 在四场景间流动

> ⚠️ 重要: **测试不是开发下游**,测试从 PRD 阶段就**与开发并行**参与(可测性评审)。这是 [`测试篇`](./docs/chapters/04-testing/) 的核心设计 —— 不要把它画成串行链。

```mermaid
flowchart LR
subgraph 业务
Expand All @@ -101,7 +103,8 @@ flowchart LR
end

subgraph 测试
STRATEGY[test-strategy.md] --> CASES[test-cases.md]
TESTABILITY["可测性评审意见<br/>testability-review.md"] --> STRATEGY[test-strategy.md]
STRATEGY --> CASES[test-cases.md]
CASES --> SUBMISSION[submission.md]
SUBMISSION --> REPORT[test-report.md]
end
Expand All @@ -112,23 +115,51 @@ flowchart LR
INC --> PM[postmortem.md]
end

RULES -.->|PRD 变更<br/>link-prd-to-design.js| DESIGN
API -.->|开发变更<br/>recommend-regression.js| CASES
REPORT -.->|测试准出<br/>generate-release-plan.js| PLAN
PM -.->|改进项<br/>incident-to-requirement.js| PRD
%% 业务产出同时推给开发和测试(并行)
PRD -->|需求评审门禁| DESIGN
PRD -->|需求评审门禁| TESTABILITY

%% 开发与测试之间的 API 契约对齐
API <-.->|契约双向锁定| CASES

%% 测试准出 → 运维发布
REPORT -->|准出门禁| PLAN

%% 联动脚本(虚线 = Sprint 4 产出的自动化)
RULES -.->|link-prd-to-design.js| DESIGN
API -.->|recommend-regression.js| CASES
REPORT -.->|generate-release-plan.js| PLAN
PM -.->|incident-to-requirement.js| PRD

style 业务 fill:#e8f5e9
style 开发 fill:#e3f2fd
style 测试 fill:#fff3e0
style 运维 fill:#f3e5f5
style TESTABILITY fill:#fffde7,stroke:#f57f17,stroke-width:2px
```

**关键观察**:
- **实线**: 场景内部产出物演进
- **虚线**: 跨场景联动(Sprint 4 的 4 个联动脚本)
- **闭环**: 运维 → 业务(复盘改进项回流需求池),形成**完整回路**
- **业务产出是"双消费"**: PRD 同时推给开发(开始设计)和测试(做可测性评审)。两条线**并行启动**,不是串行
- **测试是业务的并行下游,不是开发的下游**: 测试可测性评审是一个**门禁**,评审通过后业务才算真正交付
- **开发 ↔ 测试 双向**: API 契约是开发 + 测试共同锁定(测试从用例角度反推 API 是否可测,开发从实现角度反推用例是否可编)
- **实线 = 产出物+门禁**,**虚线 = Sprint 4 联动脚本**(自动检测触发下一环)
- **闭环**: 运维 → 业务(复盘改进项)→ PRD → 开发+测试 并行
- 每个节点都是 **Git 里的 Markdown 文件**,不是数据库记录

### 为什么测试要提前并行参与?

这是测试方法论的核心观点(详见 `docs/chapters/04-testing/FULL.md § 1`):

| 🤔 传统做法 | ✅ 本框架做法 |
|-----------|-------------|
| 业务写完 PRD → 开发写代码 → 给测试 | 业务写 PRD → 开发 + 测试**同时**接手 |
| 测试在提测时才发现"验收标准模糊" | PRD 评审时就卡住模糊需求,回炉重写 |
| Bug 发现在测试阶段,改动成本高 | 把"可测性"作为**PRD 的准出门禁** |
| 开发 - 测试 信息不对称,临近上线才对齐契约 | API 契约从需求阶段就共同设计 |

- `tools/cross-platform/scripts/check-prd.js` + `score-testability.js` 就是这套理念的自动化
- 本仓库 `docs/chapters/04-testing/04-gates/requirements-gate.md` 专门定义了"需求评审门禁"

详细扩展见 [docs/architecture/information-sharing.md](./docs/architecture/information-sharing.md)。

---
Expand Down
134 changes: 98 additions & 36 deletions docs/architecture/information-sharing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,39 +8,101 @@

## 一、核心模型

> ⚠️ 关键:**测试不是开发下游**,测试从 PRD 阶段就与开发**并行**参与可测性评审。
> 这是本框架测试篇的核心设计。下图把这个并行关系画清楚。

```
┌────────────────────────────────────────────────────────────────┐
│ 当前信息共享模式(无中心化服务端) │
├────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 产品 │ → │ 开发 │ → │ 测试 │ → │ 运维 │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │ │
│ PRD.md 设计+ADR 用例+提测单 Runbook/复盘 │
│ 业务规则 API 契约 Bug 报告 发布计划 │
│ │ │ │ │ │
│ └─────────────┴─────────────┴─────────────┘ │
│ ↓ │
│ ┌──────────────┐ │
│ │ Git 仓库 │ ← 唯一真实源 │
│ │ main branch │ │
│ └──────┬───────┘ │
│ ↓ │
│ ┌───────────────────────┐ │
│ │ CI 门禁 │ │
│ │ + 跨场景联动脚本 │ ← 自动触发下一环 │
│ │ + 度量采集 (每周) │ │
│ └──────────┬────────────┘ │
│ ↓ │
│ ┌───────────────────────┐ │
│ │ Jira / 禅道 / IM / │ ← 可选镜像/广播 │
│ │ Confluence / Slack │ (非权威源) │
│ └───────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│ 当前信息共享模式(无中心化服务端 · 测试并行参与) │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ │
│ │ 产品 │ │
│ └────┬────┘ │
│ PRD.md │
│ 业务规则 │
│ │ │
│ ┌───────────┴───────────┐ │
│ │(PRD 推给开发 + 测试) │ │
│ ▼ ▼ │
│ ┌─────────┐ 并行 ┌─────────┐ │
│ │ 开发 │ ◄───────► │ 测试 │ │
│ └────┬────┘ 契约双向 └────┬────┘ │
│ 设计 可测性评审 │
│ ADR 测试策略 │
│ API 契约 测试用例 │
│ │ │ │
│ └───────────┬───────────┘ │
│ 提测 (submission.md) │
│ ▼ │
│ (测试执行 / Bug) │
│ ▼ │
│ 准出报告 test-report.md │
│ ▼ │
│ ┌─────────┐ │
│ │ 运维 │ │
│ └────┬────┘ │
│ Runbook / 发布计划 │
│ 事件报告 / 复盘 │
│ │ │
│ │ (复盘改进项) │
│ ↓ │
│ ↩─── 回流到 产品 backlog │
│ │
│ ───────────────────────────────────────────────────────────────── │
│ │
│ 所有以上产出物都是 Markdown,统一入: │
│ ┌──────────────┐ │
│ │ Git 仓库 │ ← 唯一真实源 │
│ │ main branch │ │
│ └──────┬───────┘ │
│ ↓ │
│ ┌───────────────────────┐ │
│ │ CI 门禁 │ │
│ │ + 跨场景联动脚本 │ ← 自动触发下一环 │
│ │ + 度量采集 (每周) │ │
│ └──────────┬────────────┘ │
│ ↓ │
│ ┌───────────────────────┐ │
│ │ Jira / 禅道 / IM / │ ← 可选镜像/广播 │
│ │ Confluence / Slack │ (非权威源) │
│ └───────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
```

## 二、四个核心特征
### 关键分叉:PRD 的"双消费"

产品写完 PRD 并**不是**先给开发,等开发做完再给测试。PRD 一产出,**立即**:
- 推给 **开发**: 开始技术方案设计、ADR、API 契约
- 推给 **测试**: 做可测性评审(门禁)、起测试策略、列用例大纲

测试可测性评审通过,PRD 才算真正进入"可交付"状态。这是业务篇和测试篇共同约定的**需求评审门禁**(见 `docs/chapters/04-testing/04-gates/requirements-gate.md`)。

### 开发 ↔ 测试 的双向协作

- **开发主导**: API 契约 / 数据模型 / 内部设计
- **测试反推**: 这些设计能不能测? 边界情况够不够清晰? 异常路径覆盖了吗?
- **产出物**: 共同锁定的 `api-contract.md`,两边都有修改权 + 评审权

这个双向箭头在"提测"时合流 —— 开发提交提测单,测试审核通过后进入执行阶段。

## 二、为什么测试要并行参与(对比表)

| 🤔 传统做法 | ✅ 本框架做法 | 好处 |
|-----------|-------------|------|
| PRD 完稿 → 开发写代码 → 代码完成 → 给测试 | PRD 完稿 → **开发 + 测试 并行启动** | 测试不等代码,提前 40% 时间 |
| 测试在提测时才发现"验收标准模糊" | PRD 评审就卡住模糊需求,打回重写 | 返工成本从"修代码"降为"修文字" |
| Bug 发现在测试阶段,改代码 | 问题发现在需求阶段,改文档 | 修复成本按阶段递增 10 倍 |
| 开发独立设计 API,测试临近上线才对齐 | API 契约从需求阶段共同锁定 | 开发-测试信息对称,减少 integration bug |

相关自动化:
- `tools/cross-platform/scripts/check-prd.js` - PRD 结构校验(测试视角)
- `tools/cross-platform/scripts/score-testability.js` - PRD 可测性打分(0-100)
- `tools/cross-platform/scripts/coverage-analysis.js` - 用例 ↔ 需求 关联检测
- `tools/cross-platform/scripts/link-prd-to-design.js` - PRD 变更影响面(业务 → 开发)
- `tools/cross-platform/scripts/recommend-regression.js` - 代码改动推荐回归(开发 → 测试)

## 三、四个核心特征

### 2.1 Git = 唯一真实源

Expand Down Expand Up @@ -77,7 +139,7 @@ Jira / Confluence / 企业微信 / 钉钉 等**是镜像**,不是权威:

---

## 三、按场景详述产出物流向
## 四、按场景详述产出物流向

### 3.1 业务产出

Expand Down Expand Up @@ -119,7 +181,7 @@ Jira / Confluence / 企业微信 / 钉钉 等**是镜像**,不是权威:

---

## 四、跨场景联动(Sprint 4 产出)
## 五、跨场景联动(Sprint 4 产出)

4 个脚本把上面的"单向流动"串成**闭环**:

Expand Down Expand Up @@ -151,7 +213,7 @@ flowchart LR

---

## 五、优点 vs 缺点 · 坦诚分析
## 六、优点 vs 缺点 · 坦诚分析

### ✅ 优点

Expand Down Expand Up @@ -186,7 +248,7 @@ flowchart LR

---

## 六、最小起步 · 某团队用这套方法论的 Day 1
## 七、最小起步 · 某团队用这套方法论的 Day 1

**假设**: 一个 5 人团队,有 GitHub 企业账号,用企业微信。

Expand All @@ -200,7 +262,7 @@ flowchart LR

---

## 七、反模式 · 不要这样用
## 八、反模式 · 不要这样用

| ❌ 反模式 | 为什么不行 | 正确做法 |
|---------|----------|---------|
Expand All @@ -212,7 +274,7 @@ flowchart LR

---

## 八、相关文档
## 九、相关文档

- [ARCHITECTURE.md](../../ARCHITECTURE.md) · 本文的上层视图(四层架构)
- [PLAN.md § Phase 2 ⑤](../../PLAN.md) · 本文的初稿来源
Expand Down
19 changes: 15 additions & 4 deletions docs/chapters/00-adoption/mode-a-greenfield.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,14 +13,25 @@

## 推荐的时序

按"业务 → 开发 → 测试 → 运维"顺序展开，每个阶段完成前置产出物后再进入下一阶段。
业务先行产出 PRD;**PRD 一出 → 开发 + 测试并行启动**(测试不在开发下游,详见 [ARCHITECTURE.md § 数据流](../../../ARCHITECTURE.md#二数据流图--markdown-在四场景间流动)),两条线汇合到提测,再推进到运维。

```
Week 0 Day 1-3 Day 4-7 Week 2 Week 3+
立项 → 业务 → 开发设计 → 测试设计 → 实施迭代
Kickoff PRD完成 设计完成 用例完成 按周 Sprint
Week 0 Day 1-3 Day 4-7 Week 2 Week 3+
立项 → 业务 PRD → ┌─ 开发设计 / ADR ─┐
Kickoff PRD 完成 │ ├─→ 提测 → 测试执行 → 实施迭代
└─ 测试策略 / 用例 ─┘ Week 2 末 按周 Sprint
(两条并行)
↑
PRD 评审门禁(测试主导可测性评审)
不过,开发 + 测试 都不启动
```

关键节奏:
- **Day 1-3**: 业务做 PRD · 测试做可测性评审 · 开发提前看 PRD 了解范围
- **Day 4-7**: 开发写设计+ADR · 测试写测试策略+用例大纲(**并行**,互不等)
- **Week 2 末**: 开发提测,测试审核提测单,进入执行
- **Week 3+**: 实施迭代,运维准备发布

---

## 起步清单（按顺序执行）
Expand Down
Loading