软件分析与设计笔记 26：总结：把整条链路串起来

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。

0 回头看这条链路

整个系列到这里结束。最后这一篇不做新内容的讲解，而是把前面 25 篇串成一条线：每一环在回答什么问题、留下什么产出、由谁验收。

如果只读一篇，这一篇的功能是导航；如果读完了全部，这一篇的功能是复盘。

为了让它具体一点，我把贯穿案例（片区家电维修派单系统）整条链路走完后的产出盘点一遍 —— 你能看到每一环真的留下了东西：

1 完整链路

这张表横着看是顺序，竖着看是每一环都有自己的验收者。如果某一环找不到验收者，那一环的产出大概率没人真正需要。

本例里有一环差点没有验收者，值得记下来：界面设计那一环。最初的计划是「开发自己画个能用的就行」，后来才发现派单台的布局只有小林能判断对错 —— 于是验收者从「开发」改成了「小林」。改完之后，那一环的产出质量立刻不一样了。

2 六条贯穿全系列的原则

把 25 篇里反复出现的东西提出来，其实是六句话。每一句都能在本例里找到落点：

2.1 需求要能被验证

「系统要快」不是需求，「峰值时段 2 秒内返回」才是。这条贯穿了笔记 02、07、15。

本例的版本：「早 9:00–10:00 报修高峰，客户查工单进度的响应时间 95 分位不超过 2 秒」。

2.2 事实和假设必须分开记

用户说的、观察到的、你自己推断的，是三类东西。混在一起，几轮讨论之后假设就变成「大家都知道的事实」。见笔记 04。

本例的落点：「客服日均 80 通电话」是事实；「所以人力是瓶颈」是假设 —— 而后者被数据推翻了（真正的瓶颈是排期不可见）。

2.3 能算出来的不要存

无论是一条需求、一个字段还是一个属性 —— 同一个事实存在两处，就一定会有不一致的那天。见笔记 09、19。

本例的落点：缺料率、平均上门时长、完成率都不建字段；合计金额也不存字段。

2.4 行为跟着数据走

「计算工单金额」属于工单，不属于工具类；「依恋情结」之所以是坏味道，就是因为行为离开了它的数据。见笔记 20、25。

本例的落点：WorkOrder.canRequestParts() 而不是控制器里连取三个 getter。

2.5 让变化集中

高内聚让改动集中，低耦合让改动不外溢。判断一句需求的影响面，看的是「要改几个文件」。见笔记 23、24。

本例的落点：新增「保修单」这个需求，重设计后只需新增一个类。

2.6 没有测试的重构是赌博

结构改善必须以「行为不变」为前提，而这一点只能靠测试来保证。见笔记 14、25。

本例的落点：重构那个 280 行的 dispatch() 之前，先补了五条测试。

3 一份可以拿去用的自查清单

3.1 需求阶段

• 每条需求都能写出一条验收标准吗？
• 用户画像里有行为与痛点，而不只是人口统计？
• 范围里有明确的 out of scope 清单吗？
• 例外流程和负面场景都写了吗？
• 那些「假设与理由」里，有几条已经被数据验证过？

3.2 设计阶段

• 每个用例都能指出由哪些对象协作完成吗？
• 基数（1 对多、多对多）都是问过业务方确认的，不是猜的？
• 有没有存着本可以算出来的字段？
• 每个类的职责能用一句话说清楚吗？
• 加一种新类型，需要改几个文件？
• 外部依赖挂了的时候，业务流程还能继续吗（降级策略）？

3.3 验收阶段

• 非功能需求都带指标、条件、阈值吗？
• 测试数据覆盖了边界值与异常条件吗？
• 一条需求能一路追到代码吗？
• 那几条「只存在于代码里」的规则，补上测试了吗？

最后一条是 25 篇留下的：「紧急单优先」这条规则没写在任何文档里，只存在于代码中。如果它没有测试，那它对团队来说等于不存在 —— 下次重构就会丢掉。

4 结语

4.1 一个最有用的自检问题

如果要从整个系列里挑出一个最有用的自检问题，我选这个：

这个决定，如果三个月后被推翻，代价有多大？

它同时适用于「这条需求要不要问清楚」「这个字段要不要存」「这个类要不要抽抽象父类」。很多设计判断没有标准答案，但「被推翻的代价」这个尺度总是能算的。

本例里用这个问题做过三次决定，结果都不一样 —— 这正好说明它不是一条死规则：

4.2 一个更狠的追问

如果还想再狠一点，可以追问第二句：

这个决定，如果做错了，谁会先发现？

这一问能把「有没有验收者」这件事逼出来。本例里「界面布局对不对」这个决定，做错了第一个发现的人是小林 —— 所以她是验收者。而「表结构合不合理」这个决定，做错了第一个发现的人是三个月后的开发 —— 那时代价已经很高了。

两个问题合起来，就是这套方法论的骨架：算代价，找验收者。

5 系列导航

• 起步与方法：01 课程地图、02 设计思维与数据、03 Agile 与 Scrum
• 需求与分析：04 案例预习、05 用户画像与旅程图、06 数据侧界定、07 用户故事、08 用例与活动图、09 业务实体、10 精炼用例模型、11 Agentic AI
• 质量与交付：12 前端设计、13 需求获取、14 软件测试、15 非功能需求、16 URS 交付物、17 生成式 AI 实践
• 设计与结构：18 数据库分析与 ERD、19 规范化与 LDM、20 面向对象概念、21 UML、22 分析建模、23 设计建模、24 设计原则、25 重构
• 应试：27 Paper 1 完整演算、28 draw.io 作图手册

6 核心概念回顾（术语表）

下面这张表不是新的术语表，而是一次回顾：这些概念的完整解释在前面各自的篇章里，这里只回答一个问题 —— 它们为什么值得记住。