📄 一句话概括
沟壑有多宽可以数：一件事的 11 个现实事实里，软件只记 5 个，记录率 45%——被丢掉的那 6 个不是漏，是不需要。
📝 本节和前面几节的关系
第八章讲完了【记下来的记号】，这一章讲记什么、怎么决定记什么。沟壑就在现实和软件之间。
一、沟壑不是比喻，是数量差
现实里的一件事带着无穷多的细节：天气、衣服、心情、书放在第几排。 软件只能存有限的东西，所以必然要丢。 沟壑 ＝ 被丢掉的那一部分——它不是缺陷，是软件的定义方式。
二、实测：11 个事实只留 5 个
借书这件事摊开是 11 个事实：谁借的、借的哪本、什么时候借、什么时候还、有没有超期……还有天气、衣服、位置、说了什么话、馆员心情、几点天黑。 必须记录 5 个，直接丢掉 6 个，记录率 45%。 剩下的 55% 不是垃圾——它们是【软件不需要知道】的部分。
三、真正难的是判断哪 5 个
丢掉容易，难的是判断该留哪几个。 判断错了就叫需求错误：留了没用的字段（浪费），漏了要用的（返工）。 9.2 会说明为什么这件事只能人做——计算机不会判断【该不该记】。
四、这一章的走向
9.2~9.5 讲填补沟壑的三个阶段和建模这门技术。 9.6~9.10 讲业务系统怎么写：用例图、概念模型、表结构。 9.11~9.14 讲嵌入式怎么写：它不是记录现实，而是替人干活。 9.15 收口：建模的乐趣在哪。
五、动手 Demo：现实世界和软件之间存在沟壑
把借书这件事的现实事实逐条列出来，标出软件要不要记。 数一数记录率，看沟壑有多宽。
facts = [("谁借的", "要记录"), ("借的哪本", "要记录"),
("什么时候借", "要记录"), ("什么时候还", "要记录"),
("有没有超期", "要记录"),
("那天天气如何", "不记录"), ("读者当时穿什么", "不记录"),
("书放在第几排", "不记录"), ("读者说了什么话", "不记录"),
("馆员心情如何", "不记录"), ("窗外几点天黑", "不记录")]
need = sum(1 for a, b in facts if b == "要记录")
print(len(facts), need, len(facts) - need, 100 * need // len(facts))
# 11 5 6 45
实跑输出：
--------------------------------------------------------------------
现实世界和软件之间存在沟壑
--------------------------------------------------------------------
【沟壑】到底有多宽？拿借书这一件事，把现实里的事实逐条列出来：
现实中的事实 软件要不要
------------------------------
谁借的 要记录
借的哪本 要记录
什么时候借 要记录
什么时候还 要记录
有没有超期 要记录
那天天气如何 不记录
读者当时穿什么 不记录
书放在第几排 不记录
读者说了什么话 不记录
馆员心情如何 不记录
窗外几点天黑 不记录
现实里的事实 11 个
软件必须记录 5 个
直接丢掉 6 个
记录率 45%
**沟壑 ＝ 那 6 个被丢掉的事实**——不是遗漏，是【软件不需要】。
**但要小心**：哪 5 个该记，是【判断】出来的，**判断错了就是需求错误。**
**建模干的就是这件事**：先把事实摊开，再逐个决定记不记。
实测：11 个事实、记录 5 个、丢掉 6 个，记录率 45%。 沟壑就是那 6 个——不是遗漏，是软件不需要。 真正难的是判断哪 5 个该留，判断错了就是需求错误。
30 秒实验
- 拿你熟悉的一个业务，列出 10 个现实事实，标出软件要不要记。
- 把【不该记】的那几个各写一句理由。
常见误区
- 以为沟壑是软件做得不够好。它是软件的定义方式决定的。
- 以为丢掉的是垃圾。它们只是与这次处理无关。
自测三问（点开对答案）
1. 沟壑指什么？ —— 现实事实中软件不需要、因而没被记录的那一部分。 2. 实测记录率是多少？ —— 11 个事实留 5 个，记录率 45%。 3. 为什么说难的是判断？ —— 留错了浪费存储与字段，漏了要用的就要返工——这叫需求错误。- ☐ 9.2 计算机擅长固定工作和记忆工作
相关笔记
- 软件不会直接表示现实世界 — 同一个沟壑的另一种量法
- 通过业务分析、需求定义和设计来填补沟壑 — 怎么填
- UML是表示软件功能和结构的图形的绘制方法 — 填完怎么记
- 🧩 面向对象是怎样工作的 · 索引