软件开发全流程

这是什么？

PRD（Product Requirements Document） 回答两个问题：我们要做什么？ 和 为什么要做？

不同公司叫法不同：Google 叫 Design Doc，Stripe 叫 RFC，Linear 叫 Project Brief，Celoria 用 SpecKit 叫 spec.md。本质是同一件事。

好的 PRD 长什么样？

核心要素（缺一就是"坏 PRD"）：

为什么不能跳过？

没有 PRD 就写代码 = 在没有地图的情况下开车。你可能写出一个技术上完美但没人要的功能。Google Wave 就是经典案例 — 技术很酷，但没解决真实问题。

这是什么？

CUJ（Critical User Journey） 是用户完成核心目标的最短路径。Google SRE 团队用它来定义"什么是不能挂的"。

EUJ（End User Journey） 是完整的用户体验路径，包含非关键步骤。CUJ 是 EUJ 的子集。

关系层级：一个 EUJ 包含多个 CUJ，一个 CUJ 由多个 User Stories 组成。

BDD 场景 — CUJ 的可执行版本

BDD（Behavior-Driven Development） 用 Given / When / Then 格式把用户旅程写成可执行的测试用例：

为什么不能跳过？

不画用户旅程 = 工程师凭想象构建功能。Shopify VP of Engineering 公开说过：他们最大的几次产品失误都是因为"工程师以为自己理解用户，但没有走过完整路径"。

CUJ 也是测试策略的基础 — E2E 测试应该覆盖所有 CUJ。如果你不知道 CUJ 是什么，你的 E2E 就不知道该测什么。

这是什么？

PRD 回答"做什么"，Design Doc 回答"怎么做" — 系统架构、数据模型、API 设计、技术选型、风险评估。

Google Design Doc 的标准结构

PRD vs Design Doc vs RFC vs Spec — 到底什么区别？

很多公司会合并这些 — Celoria 的 SpecKit 就是把 Spec + Plan + Tasks 三者统一管理。

图的价值

Google 的原则：如果一个系统不能用一张图解释清楚，说明设计太复杂了。

图不是装饰品。Stripe 特别重视 Data Flow Diagram，因为支付系统中资金流向必须绝对清晰 — 他们的安全审计也依赖架构图来识别攻击面。

你需要知道的 6 种图

这是什么？

把 Design Doc 拆成可执行的任务，确定依赖关系和执行顺序。

Shopify 的 "Scope Hammer" 方法

拿到设计后，反复问 "这个能不能更小？"，直到每个任务都能在 1-2 天内完成。

按 dependency graph（依赖关系图）排序 — 先做被依赖最多的模块：

TDD — 先写测试再写代码

TDD（Test-Driven Development） 的核心循环：

1. Red — 先写一个会失败的测试（因为功能还没实现）
2. Green — 写最少的代码让测试通过
3. Refactor — 重构代码，保持测试通过

Stripe 要求："If it handles money, it needs a test before it handles money."（处理钱的代码必须先有测试）

TDD vs BDD — 不是互斥的

最佳实践：Unit level 用 TDD，Feature level 用 BDD。先用 BDD 定义系统行为，再用 TDD 实现每个组件。

Code Review — 比测试更有效的质量保障

微软研究院的数据：Code Review 能发现 60-90% 的缺陷，比测试更有效（测试通常发现 25-35%）。

Google 公开的 Code Review 原则：

1. 小的 PR 优于大的 PR — 200 行以内的 PR 质量最高。超过 400 行，reviewer 注意力显著下降
2. Review 优先级：设计 > 功能正确 > 复杂性 > 测试 > 命名 > 注释 > 风格
3. 24 小时内响应（大多数应在几小时内完成）
4. 区分 "must fix" 和 "nit"（建议但不强制）

经典模型

graph TB
    E2E["🔺 E2E 测试
少量 · 覆盖 CUJ · 最慢"]
    INT["🔶 集成测试
中等 · 验证模块协作"]
    UNIT["🟢 单元测试
大量 · 验证单个函数 · 最快"]

    E2E --- INT --- UNIT

    style E2E fill:#dc262615,stroke:#dc2626,color:#fca5a5
    style INT fill:#f59e0b15,stroke:#f59e0b,color:#fcd34d
    style UNIT fill:#22c55e15,stroke:#22c55e,color:#86efac
    

Google 推荐比例：70% Unit / 20% Integration / 10% E2E

三层分别测什么？

前端的特殊之处（MSW）

前端集成测试经常需要 mock API 响应。Celoria 前端用 MSW（Mock Service Worker） — 它在网络层拦截请求，让组件以为自己在和真实 API 通信。

这比直接 mock fetch 更好，因为它测试了组件的完整请求/响应处理链路。

CI/CD — 自动化流水线

CI（Continuous Integration）：开发者频繁地将代码合并到主分支，每次合并自动运行测试。目标是"尽早发现集成问题"。

CD（Continuous Delivery）：代码随时可以部署到生产环境。可以手动触发（Delivery）或全自动（Deployment）。

Feature Flag — 解耦部署和发布

代码已经在生产环境中，但通过配置决定是否对用户可见。

• 用途：A/B 测试、渐进式发布、紧急回滚（关 flag 比回滚代码快得多）
• 关键：Feature Flag 是临时的。功能稳定后必须清理，否则代码会充满 if (flag.enabled)

Canary Deployment — 金丝雀部署

新版本先部署到 1% 的用户，监控关键指标。正常则逐步扩大（5% → 25% → 100%），异常则自动回滚。

命名来源：矿井中的金丝雀 — 矿工用金丝雀检测有毒气体，金丝雀先倒下，矿工就知道要撤退。

可观测性三支柱

下面是 Celoria SpecKit 流程与大厂流程的对照：

保留的（Non-negotiable）

1. Design Doc / Spec — 但更短更快（1-2 页 vs Google 的 10-20 页）
2. Code Review — 100% 保留，但要快（小时级响应）
3. 自动化测试 — 金字塔底部更重（多 Unit，少 E2E）
4. CI/CD — 必须自动化。手动部署是 anti-pattern
5. Feature Flags — 解耦部署和发布，是快速迭代的基础

简化的

1. PRD → 1 页 Project Brief（不写 50 页文档）
2. User Journey → 只画 critical path（不画所有边缘情况）
3. 架构图 → 白板 + 截图（不用 Visio 画精美图）
4. Task Planning → Linear/GitHub Issues（不用 Jira 完整流程）

砍掉的

1. Architecture Review Board — 用 Slack 讨论代替
2. 独立 QA 团队 — 工程师自己测，自己保证质量
3. Change Advisory Board — 用 CI/CD + Feature Flag 代替人工审批
4. 详细的项目管理文档（甘特图、WBS）— 用 2 周 cycle 代替