MIT 6.031 软件构造

课程：MIT 6.031 — Software Construction（软件构造），Spring 2022 课程主页：https://web.mit.edu/6.031/www/sp22/ 授课形式：每周一、三、五，各 90 分钟（MWF 11:00–12:30） 先修课程：6.009（Fundamentals of Programming） 本笔记基础：对课程公开站点 sp22（Spring 2022，主讲站点）与 sp21（Spring 2021，Java 版同一课程）的全部公开页面进行系统抓取后撰写，覆盖 Reading 1–29 全部章节。

关于本笔记的语言说明（请先读这段）

MIT 6.031 在 Spring 2022（sp22） 学期把授课语言从 Java 切换为 TypeScript。因此：

• 你指定的 sp22 站点上，所有代码示例都是 TypeScript。
• 但本笔记按你的要求，全部代码示例提供 Java 版本。
• 这些 Java 示例并非杜撰：它们来自 MIT 6.031 的 sp21（Spring 2021）Java 版同一门课、同一套讲义。sp22 与 sp21 的阅读材料在讲解文字上几乎逐段对应（例如 Reading 11 的正文两版高度一致，只有代码从 Java 换成了 TypeScript），所以 Java 示例与 sp22 的讲解是精确对应的，只是换了语言载体。
• 少数 sp22 特有的机制（Promise/async/await、结构化类型系统、readonly）在 Java 中没有一一对应的孪生章节，笔记中会明确标注为「Java 类比 / 补充说明」。
• 每篇笔记开头的引用块都会说明该讲的语言对应情况。

结论：你可以把本笔记当作「用 Java 讲的 6.031」来学——概念、术语、章节结构完全忠实于 sp22 原版，代码可以在 JDK 17+ 上编译运行。

课程概览

一、这门课到底在教什么

6.031 的目标可以用一句话概括：学会写出好的代码。而”好”被精确定义为三个可检验的属性，它们贯穿全课程、出现在每一次作业评分、每一次代码审查、每一道测验题中：

这三个目标（6.031 内部常缩写为 SFB / ETU / RFC，或”the big three”）是本课程最重要的单一思想。每一个设计原则、每一种语言特性、每一条编码规范，最终都要回答同一个问题：它如何让代码更 SFB、更 ETU、或更 RFC？ 在本笔记中，你会反复看到这个三元组被用来评估一个做法是好是坏。

值得强调的是：这三个目标经常互相冲突。过度抽象会让代码难以理解；为了让代码容易修改而引入的间接层可能引入 bug；为了安全性做的防御性拷贝可能损害性能。软件构造的核心技能，正是在具体语境下做出有意识的权衡，而不是机械套用规则。

二、课程范围：一张知识地图

6.031 的知识体系可以分成四个层次，这也是本笔记 29 讲的推进顺序：

第一层：代码层面的正确性与表达力（Reading 1–9）

• 静态检查（R1）：让编译器在运行前抓住错误。类型系统是最廉价的测试。
• 基础语言机制（R2）：原始类型与引用类型、final、快照图（snapshot diagram）。
• 测试（R3）：测试优先编程（test-first programming）、输入空间划分、边界值、代码覆盖率——测试不是事后验证，而是设计活动。
• 代码审查（R4）：DRY、fail fast、魔法数字、命名、作用域。
• 版本控制（R5）：Git 的对象图模型，为什么版本控制同时服务于三大目标。
• 规格说明（R6–R7）：本课程的第一个理论高峰。规格说明是方法与其调用者之间的契约，由前置条件与后置条件构成；规格说明的强弱可以比较；应当使用声明式而非操作式规格；应当允许实现自由度（underdetermined）。
• 可变性与不可变性（R8）：别名（aliasing）是可变对象危险的根源；防御性拷贝；不可变对象天然免于 bug。
• 避免调试（R9）：把 bug 消灭在设计阶段——让 bug 不可能、让 bug 显而易见、让 bug 尽早失败。

第二层：数据抽象——本课程的核心（Reading 10–17）

• 抽象数据类型（ADT）（R10）：用操作集合而非内部表示来定义类型；creators / producers / observers / mutators 四类操作的划分；表示独立性（representation independence）。
• 抽象函数与表示不变量（R11）：全课程最重要的两个概念。AF 回答”内部表示代表什么抽象值”，RI 回答”内部表示的哪些状态是合法的”。二者必须写在代码注释里，由 checkRep() 检查。
• 接口、泛型与枚举（R12）：接口与实现分离、子类型、Liskov 替换原则。
• 调试（R13）：科学方法式调试——观察、假设、实验、重复。
• 递归（R14）：递归分解、基础情形与递归步骤、辅助函数。
• 相等性（R15）：等价关系三性质；引用相等 vs 值相等；equals()/hashCode() 的契约。
• Map / Filter / Reduce（R16）：一等函数、高阶函数、用函数抽象控制流。
• 递归数据类型（R17）：不可变列表 ImList、递归类型的 AF/RI。

第三层：从数据到系统（Reading 18–27）

• 正则表达式与文法（R18）、解析器（R19）：用文法描述输入语言，用解析器生成器把字符序列变成解析树，再转成抽象语法树。
• 回调与 GUI（R20）：控制反转、事件循环、观察者模式——并在此引入并发的动机。
• 并发（R21–R24）：本课程的第二个理论高峰。
  • 共享内存 vs 消息传递两大模型（R21）；
  • 竞态条件与交错（R21、R23）；
  • 异步计算与 Promise（R22）；
  • 互斥：锁、synchronized、临界区、死锁与锁顺序（R23）；
  • 消息传递：阻塞队列、生产者-消费者模式（R24）。
• 网络（R25）：客户端/服务器架构、套接字、字节流协议。
• 小语言（R26–R27）：把文法、递归数据类型、解释器、访问者模式串成一条完整链路——这是全课程的”毕业设计级”综合应用。

第四层：工程与社会（Reading 28–29）

• 软件工程伦理（R28）：四种道德透镜（后果主义、义务论、美德伦理、社会契约）、ACM 道德准则、伦理案例分析。
• 团队版本控制（R29）：功能分支、拉取请求、合并与冲突解决、团队工作流。

三、课程哲学：为什么 6.031 这样设计

1. 软件构造的本质是”管理复杂性”。 课程反复强调：代码是写给人读的，只是顺便让机器执行。随着系统变大，唯一能限制复杂度的武器是抽象（abstraction）与模块化（modularity）。ADT、规格说明、不变量的共同目的，都是把”需要同时考虑的东西”变少。

2. 规格说明优先于实现。 6.031 的观点是：在写实现之前，你必须先能精确说出这个函数”做什么”（而不是”怎么做”）。规格说明让调用者与实现者解耦（decoupling）——调用者只依赖契约，实现者可以自由更换算法与数据结构。这就是 RFC 的技术基础。

3. 正确的做法是让错误不可能发生，而不是事后检查。 这条原则贯穿全课程：静态类型检查优于运行时断言，不变量优于临时检查，不可变对象优于防御性拷贝，编译期错误优于运行期错误。”Fail fast”（尽早失败）是它的一种表现：错误越早暴露，定位成本越低。

4. 测试是设计活动，不是收尾工作。 测试优先编程（test-first programming）要求先写测试再写实现。这不仅提高测试质量，更重要的是强迫你在写代码前想清楚规格说明和边界情况。

5. 迭代与反馈是学习的核心机制。 课程刻意压缩讲授时间、增加练习时间。每周 3 次课、每次课先来一个 3 分钟 nanoquiz；每个 Problem Set 走 alpha → 同伴代码审查 → beta 迭代 的流程；最后还有三人团队项目（Star Battle）。课程引用了 Wieman 等人的 Course Transformation Guide 和 Deslauriers 等人的物理课堂研究来论证这一设计。

6. 工程决策包含伦理维度。 最后一讲（R28）提醒：写出”技术上正确”的软件还不够，工程师要对软件的社会后果负责。这在三大目标之外增加了一个维度：软件是否对使用者与社会负责任。

四、6.031 的核心方法论：一句话总结每一层

五、评测与学习方式

给自学者（如你）的建议：6.031 的知识密度很高，但它的学习曲线设计得很友好——每一讲都建立在前面几讲之上。建议的学习路径是：

1. 按顺序读本笔记的 Reading 1–15，把 AF/RI（R11）和规格说明（R6–R7）读三遍，这两处是整门课的地基。
2. 每读完一讲，把笔记里的错误代码先自己改对，再看正确代码。
3. Reading 16–19 是”数据 → 语言”的桥梁，务必动手写一个小的解析器。
4. Reading 21–24 是并发，必须动手跑代码：写一个 counter++ 的竞态程序，亲眼看它出错，比读十遍文字都有效。
5. 最后用 Reading 26–27 的小语言把前面所有知识串起来。

文档结构导航

第一部分：课程资料获取与结构化整理记录

1.1 数据获取范围与方法

本次整理对 MIT 6.031 的两个完全公开的课程站点进行了系统性抓取与文本抽取：

为什么要抓两个站点？ 用户要求提供 Java 代码示例，而 sp22 学期的 6.031 已把授课语言从 Java 切换为 TypeScript。所幸 sp21（Spring 2021）是同一门课、同一套讲义的 Java 版本， 其讲解文字与 sp22 几乎逐段一一对应（例如 Reading 11 “Abstraction Functions & Rep Invariants” 两版正文高度一致，只有代码从 Java 换成了 TypeScript）。 因此本笔记采用 sp22 的章节结构、主题顺序与术语体系，同时以 sp21 的 Java 原文 作为全部代码示例的权威来源，从而既满足”以 sp22 为准”的要求，又满足”提供可运行 Java 代码”的要求。

抓取到的原始材料保存在 /home1/runguoli/learning/mit6031_data/：

mit6031_data/
├── sp22/          # 53 个页面：29 篇 Reading + 5 个 Problem Set + Project + Quiz Archive
│                  # + General/FAQ/协作政策/代码审查政策/评分政策/公告存档
├── sp21/          # 54 个页面：30 篇 Reading（Java 版）+ 作业与政策页
├── readings_index.json   # 29 条结构化阅读记录（见 1.6）
├── build_index.py        # 结构化提取脚本
└── crawl.py              # 抓取与 HTML→文本 抽取脚本

抽取出的纯文本（.txt）保留了原文的正文、代码块、表格与列表结构，用于后续笔记撰写。

1.2 公开性说明（哪些能拿到、哪些受限）

说明：受限资源的处理方式遵照任务要求——仅记录名称并注明”未公开”，不尝试绕过任何访问限制。

1.3 公告（Announcements）记录

sp22 学期共 35 条公告，按时间倒序排列如下（完整正文已保存于 mit6031_data/sp22/announcements.txt）：

公告中体现的关键学期节点：

• Wed Jan 19：欢迎来到 6.031（课程开始）
• Sun Jan 30 / Mon Jan 31：Getting started、Problem Set 0 发布、阅读练习与 nanoquiz 机制说明
• Wed Feb 9 / Fri Feb 11：PS0 代码审查开放（周五 11am 截止）→ PS0 alpha 报告发布
• Mon Feb 14：Problem Set 1 发布
• Thu Feb 24：因暴雪周五停课（说明课程会因天气调整）
• Thu Mar 17 / Fri Mar 18：Quiz 1
• Mon Mar 28：Quiz 1 成绩发布
• Fri Apr 15：项目分组报名（Project group signup）
• Sun Apr 24：项目分组与项目 Handout 发布
• Mon Apr 25：团队契约（team contract）截止
• Fri May 6：最后一节课 + 项目截止（22:00）+ 个人反思截止（22:00）
• Fri May 13：Quiz 2（1:35–2:25pm，期末考试时段）
• Thu May 19：项目成绩、Quiz 2 成绩、最终成绩归档

公告中还明确了考试纪律：Quiz 闭卷、闭笔记，允许携带 一张 8.5×11 英寸双面手写/打印笔记纸；Quiz 2 覆盖 Reading 1–29，重点为 Reading 17–29。

1.4 课程日程与阅读材料映射

6.031 每周三次课（周一/周三/周五，各 90 分钟）。大部分课程要求课前完成阅读 + 在线练习（课前晚 10pm 截止），每次课以 3 分钟 nanoquiz 开始。 下表给出 sp22 的 29 篇阅读材料、主题、对应作业，以及本笔记使用的 Java 源章节：

关于 Quiz 覆盖范围：Quiz 1 覆盖 Reading 1–16；Quiz 2 覆盖 Reading 1–29（重点 17–29）。

1.5 作业、项目与测验记录

Problem Sets（共 5 个，占总成绩 54%）

每个 PS 采用 alpha → 同伴代码审查 → beta 迭代 的流程：alpha 提交后接受评分与同学代码审查，beta 需根据审查意见与失败测试修订代码。总评成绩约各占一半。

Project（占总成绩 7%）：名称为 ⭐️⚔️（Star Battle），三人一组，要求设计、实现、测试、文档全面参与，团队统一评分。 里程碑：团队契约（Apr 25）→ Iteration #0（Apr 28）→ Iteration #1（May 3）→ 项目截止与个人反思（May 6, 10pm）。

Quizzes（占总成绩 24%）：Quiz 1（12%）与 Quiz 2（12%，期末考试时段）。春季学期 Quiz 1 在 Mar 17 左右，Quiz 2 在 May 13。 Quiz 通过 quiz.mit.edu 在线进行，闭卷，允许一张双面笔记纸。Quiz Archive 公开（Fall 2021、Spring 2021 的 Quiz 1/Quiz 2 及解答 PDF，以及 Fall 2020 及更早的 Java 版测验）。

1.6 结构化阅读记录（readings_index.json）

按照任务要求，每篇阅读材料都建立了一条结构化记录。完整 JSON 保存于 /home1/runguoli/learning/mit6031_data/readings_index.json，字段格式如下：

{
  "reading_number": 11,
  "topic": "Abstraction Functions & Rep Invariants",
  "sp22_url": "https://web.mit.edu/6.031/www/sp22/classes/11-abstraction-functions-rep-invariants/",
  "key_concepts_raw": ["invariants", "representation exposure", "abstraction functions", "representation invariants"],
  "related_problem_set": "Problem Set 2",
  "primary_language_sp22": "TypeScript",
  "java_source_url": "https://web.mit.edu/6.031/www/sp21/classes/11-abstraction-functions-rep-invariants/",
  "available_public_info": "阅读材料页面完全公开，含完整讲解文本、代码示例、练习题与解答。"
}

全部 29 条记录的关键概念（key_concepts_raw，从各 Reading 的 “Objectives” 小节自动提取）：

1.7 课程政策与评分标准记录

评分构成（摘自 General Information 的 Grading 小节）

字母等级默认分界：≥90 为 A，≥80 为 B，≥70 为 C；分界线只可能下调，绝不上升，且无名额限制、不按比例给分。

课堂与考勤政策

• 每周三次 90 分钟课程，必须出席并积极参与；需自带笔记本电脑。
• 每次课以 3 分钟闭卷 nanoquiz 开始，考查本次阅读与近期课堂内容。
• 自动丢弃最低 5 次课堂成绩（相当于自动豁免最多 5 次课），也可按流程补课获得部分学分。
• 课程刻意减少讲授时间、增加练习时间，因为「练习与反馈是学习的关键」（引用 Wieman 等、Deslauriers 等的研究）。

协作与公开分享政策（Collaboration and Sharing）

核心精神：讨论思路可以，逐步算法说明（含伪代码）不可以；帮助别人时，自己的代码不应可见（”帮助同学时先关掉自己的代码”）。 代码审查中会看到同学的解答，可以受启发，但不能抄袭。

代码审查政策（Code Reviewing）：课程鼓励 “review-before-commit”（Google 源码仓库要求任何一行代码都必须被另一位工程师阅读、反馈并签署）。 审查的目标是 safe from bugs / easy to understand / ready for change。审查清单包括： bug 或潜在 bug、重复代码（DRY）、代码与规格不一致、off-by-one、全局变量与过大的变量作用域、魔法数字、可以更防御性或更快失败的代码、 不清晰的代码、糟糕的命名、不一致的缩进、可简化的控制流、单行/单方法塞入过多内容、晦涩代码缺注释、与代码冗余的琐碎注释、一变量多用、 语言误用（如 == vs ===、var vs let、for...in vs for...of），以及对课程已讲授设计概念（ADT、规格说明、不变量等）的误用或未使用。

求助渠道政策：一般问题走 Piazza（不要把代码贴到 Piazza）；成绩问题不走 Piazza，也不直接联系助教，而是通过专门流程； TS Tutor 的 bug 用练习内的 “Report a Problem” 上报；提问时须给出可点击的精确 URL（课程网站每个段落都可链接）。

第二部分：分讲学习笔记（Reading 1–29）

以下按阅读材料编号顺序呈现全部 29 讲。每讲严格遵循统一结构： 概述 → 核心概念与设计原则详解 → 代码示例与对比分析 → 与其他设计原则的关联 → 关键要点 → 常见陷阱与注意事项 → 思考题（带答案）。

每讲开头的说明块会指出该讲在 sp22（TypeScript 原版）与 sp21（Java 版）之间的语言对应关系。

Reading 1: 静态检查（Static Checking）

说明：本讲 sp22 原版使用 TypeScript，本笔记按用户要求提供 Java 代码示例；类型/API 与 sp21（6.031 Java 版）原文保持一致。

概述

本讲包含两个主题：静态类型（static typing） 与 好软件的三大性质（the big three properties of good software），并以冰雹序列（hailstone sequence） 作为贯穿全讲的运行示例。核心问题是：怎样让错误尽可能早地、尽可能自动地被发现？答案是把手动检查变成编译期（compile time） 的机器检查，也就是静态检查。这一思想直接服务于课程的第一个目标「Safe from bugs」（在程序运行之前就拦住一整类错误），同时通过把类型、final、前置条件等假设显式写进代码而服务于「Easy to understand」，并通过让编译器指出所有需要同步修改的位置而服务于「Ready for change」。

核心概念与设计原则详解

冰雹序列（Hailstone Sequence）

• 定义与目的：从正整数 n 出发，若 n 为偶数则下一项为 n/2，若 n 为奇数则下一项为 3n+1，序列在到达 1 时结束。例：3, 10, 5, 16, 8, 4, 2, 1。它是本讲的「小白鼠」：一个足够简单、可以完整读懂的循环，却同时暴露出类型声明、整数运算、数组越界、参数前置条件等一连串软件构造问题。
• 直观解释（”它是什么？”）：因为奇数规则 3n+1 会把数「弹上去」，序列会先上下跳动，最后落回地面——就像云中的冰雹反复上下翻滚，直到足够重才落地。数学上至今没有人能证明所有起点最终都会落到 1（Collatz 猜想仍未解决），这个「连数学家都证明不了它一定停机」的性质，正好说明为什么我们不能靠推理替代测试（见 Reading 03）。
• 关键规则与最佳实践：
  • 用整数运算写循环时，先想清楚「这个表达式是在 int 域还是 double 域里求值」，n / 2 与 n / 2.0 完全不同。
  • 序列长度不可预测（n=27 需要 112 项才能降到 1），因此绝不能用固定长度的容器去装它。
  • 规格说明里必须写清前置条件，冰雹序列要求 n > 0；n = 0 或 n < 0 会造成无限循环（0 永远是偶数，-5 → -14 → -7 → -20 → -10 → -5 形成死循环）。
  • 循环体内修改参数会让规格说明中「n 是起始值」的假设失效，应使用独立的循环变量。

类型（Type）

• 定义与目的：类型是一组值的集合，以及可以在这些值上执行的操作。类型的作用是让编译器知道哪些操作是合法的，从而把「把操作施加到错误类型的参数上」这一类 bug 彻底挡在编译期之外。它服务的首要目标是 Safe from bugs，其次是 Easy to understand（类型就是写在代码里的假设）。
• 直观解释（”它是什么？”）：把类型想成「容器上的标签」。标着 int 的盒子里只装 32 位整数，标着 String 的盒子里装字符序列。你在 String 盒子上按「乘法」按钮时，编译器会在你按下运行按钮之前就告诉你：「这个按钮在这个盒子上不存在」。
• 关键规则与最佳实践：
  • Java 的原始类型（primitive types）：int（约 ±2³¹）、long（约 ±2⁶³）、boolean、double、char，一律小写。
  • Java 的对象类型（object types）：String（字符序列）、BigInteger（任意精度整数）、以及你自定义的类，按约定首字母大写。
  • 每个原始类型都有对应的包装类型（wrapper type）：int/Integer、long/Long、double/Double，泛型参数必须用包装类型。
  • 变量声明要「能写就写」：把类型写下来既是给编译器的承诺，也是给未来读者的文档。

操作的三种书写形式与重载（Overloading）

• 定义与目的：操作（operation）是「吃进输入、吐出输出、有时还会改变自身值」的函数，无论语法怎么变，我们都把它当函数看。识别这三种形式有助于读懂 API 文档，也是理解重载的前提。
• 直观解释（”它是什么？”）：同一个「加法」概念，可以写成中缀运算符 a + b、对象方法 bigint1.add(bigint2)、或者类里的静态函数 Math.sin(theta)。它们在语法上长得完全不同，在语义上都是「函数」。
• 关键规则与最佳实践：
  • 运算符形式：a + b 调用的是 + : int × int → int，箭头前是输入类型，箭头后是输出类型。
  • 对象方法形式：bigint1.add(bigint2) 调用 add : BigInteger × BigInteger → BigInteger，接收者对象是隐含的第一个参数（Java 中叫 this，Python 中叫 self）。
  • 静态函数形式：Math.sin(theta) 调用 sin : double → double；此时 Math 不是对象，而是包含该函数的类。
  • 属性/实例变量形式：数组用 a.length（无括号，因为是实例变量），字符串用 str.length()（有括号，因为是方法调用），二者语法不同，别记混。
  • 重载（overloading）：同一个名字对应不同参数类型的多个函数。Java 中 + - * / 对数值原始类型重载，方法的参数列表不同也可以重载。重载让代码更易读（+ 对字符串就是拼接），但也是 == 在对象上语义突变的根源（见 Reading 02）。

静态类型（Static Typing）

• 定义与目的：静态类型语言在程序运行之前就知道所有变量的类型，因而编译器能推断出所有表达式的类型。它消灭的是一大类 bug：把操作施加到错误类型的参数上。这直接对应 Safe from bugs。
• 直观解释（”它是什么？”）：想象一位在你身边盯着你打字的助教。你刚写完 "5" * "6"，他就说：「字符串不能相乘。」你还没运行程序，错误就已经被拦住了。Eclipse / VS Code 在你打字时就在做这件事。
• 关键规则与最佳实践：
  • 静态检查能抓：语法错误（多余的标点、错字）、拼错的名字（Math.sine(2)）、参数个数错误（Math.sin(30, 20)）、参数类型错误（Math.sin("30")）、返回值类型错误（声明返回 int 却 return "30";）。
  • 静态检查不能抓：与具体值有关的错误，比如除零、下标越界、非法转换（Integer.valueOf("hello")）。因为编译器只知道「y 是 int」，不知道「y 恰好是 0」。
  • 静态类型保证「变量一定持有该类型中的某个值」，但不保证是哪一个值；值相关的检查属于动态检查。
  • 类型越精确（如用 List<Integer> 而不是裸 List），编译器能替你抓的错误就越多。

静态检查、动态检查、不检查（Static Checking, Dynamic Checking, No Checking）

• 定义与目的：语言可以提供的三种自动检查档次——静态检查（运行前发现）、动态检查（运行时发现）、不检查（语言完全不管，你自己盯着，否则就得到错误答案）。三者优先级为：静态优于动态，动态优于不检查。这三档构成了本讲最重要的判断框架。
• 直观解释（”它是什么？”）：把它想成机场安检的三道关：静态检查是登机前的行李检查（还没上飞机就被拦下），动态检查是飞行中的警报（出问题立刻报警并迫降），不检查是根本没有报警器（飞机安静地飞向错误的方向，直到撞山）。
• 关键规则与最佳实践：
  • 写代码时反复问自己：「这个错误会在编译期被抓住、运行期被抓住、还是完全抓不住？」抓不住的错误要有额外的防御（断言、显式检查、更安全的类型）。
  • 静态检查面向类型，动态检查面向具体值；这是一条极为有用的心智分界线。
  • Java 做了不少动态检查（数组越界抛 ArrayIndexOutOfBoundsException、除零抛 ArithmeticException、null 上调用方法抛 NullPointerException），这比 C/C++ 安全得多——C/C++ 的数组越界是不检查的，正是缓冲区溢出漏洞与网络蠕虫的温床。
  • TypeScript 在运行期的行为完全由 JavaScript 提供，而 JavaScript 在很多场合选择「不检查」：越界返回 undefined，除零返回 Infinity。错误值会一路传播，直到离原始错误很远的地方才爆发——这让调试变难。

原始类型不是真正的数（Primitive Types Are Not True Numbers）

• 定义与目的：Java 的数值原始类型有一些不符合直觉的角落，导致某些本该被动态检查的错误变成了「静默的错误答案」。理解这些角落是避免「数值 bug」的关键。
• 直观解释（”它是什么？”）：int 是一条首尾相接的环形跑道，跑到最右端会突然跳回最左端；double 是一个只有 53 位有效二进制数字的标尺，太长的小数只能被截断。
• 关键规则与最佳实践：
  • 整数除法：5/2 得到 2 而不是 2.5，小数部分被直接丢掉（截断），不报错。
  • 整数溢出（overflow）：int/long 是有限集合，超出范围会静默回绕，得到一个合法范围内的错误数字。
  • 浮点特殊值：double 有 NaN（Not a Number）、POSITIVE_INFINITY、NEGATIVE_INFINITY。除零或对负数开平方不会抛异常，而是得到这些特殊值，继续算下去会得到错误的最终结果。
  • 精度限制：double 只能精确表示 2⁵³ 以内的整数，超过之后相邻可表示整数之间的间隔大于 1，x + 1 可能等于 x（这正是 sp22 中 TypeScript 的 number 陷阱）。
  • Java 补充说明：Math.abs(Integer.MIN_VALUE) 返回的仍是 Integer.MIN_VALUE（一个负数！），因为 -2³¹ 的相反数超出了 int 的范围。

数组与集合（Arrays and Collections）

• 定义与目的：把冰雹序列存起来而不是打印出来，需要数据结构。Java 提供定长数组和可变长 List 两类「列表状」容器；选择哪一个直接影响安全性。
• 直观解释（”它是什么？”）：数组是一排固定编号的储物柜，造好之后柜子数量就定死了；List 是一根可以随时加长缩短的伸缩杆。
• 关键规则与最佳实践：
  • 数组声明与构造：int[] a = new int[100];，一旦创建长度不可变；操作有下标 a[2]、赋值 a[2] = 0、长度 a.length。
  • List 声明与构造：List<Integer> list = new ArrayList<Integer>();，操作有 list.get(2)、list.set(2, 0)、list.size()、list.add(n)。
  • 为什么左边写 List 右边写 ArrayList：List 是接口（interface），只规定必须提供哪些操作；ArrayList 是具体类，提供实现。声明变量与返回类型时优先用接口，代码更通用、更灵活。
  • 为什么不能写 List<int>：泛型参数必须是对象类型，所以要用包装类型 Integer。Java 会在 int 与 Integer 之间自动装箱/拆箱，所以 Integer i = 5; 合法。
  • 定长数组 + 魔法数字是经典的 bug 来源：冰雹序列长度不可预测，new int[100] 对 n=27（需要 112 项）就会越界。这种错误叫缓冲区溢出（buffer overflow），在 C/C++ 中是安全灾难，在 Java 中会被动态检查为异常。

迭代（Iterating）

• 定义与目的：for-each 循环让「遍历容器中的每个元素」这一最常见任务变得简洁、不易出错。
• 直观解释（”它是什么？”）：for (int x : list) 读作「对 list 中的每一个 x」，你不需要自己维护下标计数器，也就没有机会把 <= 写成 <、把起始值写成 1。
• 关键规则与最佳实践：
  • Java 写法：for (int x : list) { max = Math.max(x, max); }，数组和 List 通用。
  • 循环变量优先用原始类型 int 而不是 Integer，因为原始类型的 == 更简单、更不易出错（见 Reading 02）。
  • 只有在确实需要下标时才写 for (int i = 0; i < list.size(); i++)，这种写法冗长且藏 bug 的地方更多。
  • 绝不要在迭代过程中修改正在遍历的集合（增、删、替换），这会破坏迭代器，甚至让程序崩溃。

方法与规格说明（Methods and Specifications）

• 定义与目的：Java 中语句必须放在方法里，方法必须放在类里。方法上方的 /** ... */ 注释是规格说明（specification），它描述操作的输入与输出，是模块与客户之间的契约。
• 直观解释（”它是什么？”）：规格说明是「说明书」，不是「实现日记」。说明书只写调用者需要知道的事，不写内部怎么实现。
• 关键规则与最佳实践：
  • public 表示任何代码都可以引用；private 等访问修饰符用来获得更强的安全性，并保证不可变类型的不可变性（Reading 08 会展开）。
  • static 表示这个方法不带隐含的 this 参数，用类名调用：Hailstone.hailstoneSequence(83)。
  • 规格说明要简洁、清晰、精确，只写类型声明没说的事：不必写「返回一个整数列表」（List<Integer> 已经说了），但必须写「序列以 n 开始、以 1 结束」以及「要求 n > 0」。
  • 有前置条件（precondition）时一定要写出来，并用防御性检查兜底；注释是给人看的，编译器不看注释。

改变值 vs. 重新赋值变量（Mutating Values vs. Reassigning Variables）

• 定义与目的：这是两个必须严格区分的概念：改变变量指向哪里（重新赋值）与改变值本身的内容（修改）。不可变性（immutability） —— 有意禁止某些东西在运行时改变 —— 是本课程的核心设计原则。
• 直观解释（”它是什么？”）：在快照图（snapshot diagram，Reading 02 详述）里，变量是一支箭头。赋值是让箭头指向别处；修改是让箭头指向的那个气泡内部发生变化。
• 关键规则与最佳实践：
  • 不可变类型（immutable type）：值一旦创建就不能改变。String 在 Java 和 Python 中都是不可变的。
  • 不可重新赋值的引用（unreassignable reference）：用 final 声明，变量只被赋值一次。若编译器无法确信它只被赋值一次，就报编译错误——所以 final 提供的是静态检查。
  • 好习惯是对方法参数和尽可能多的局部变量加 final：这些声明既是文档，又被编译器静态检查。
  • 注意两个容易混淆的组合：final 引用可以指向可变对象（final StringBuilder sb = new StringBuilder("a"); sb.append("b"); 合法）；非 final 引用也可以指向不可变对象（String s = "a"; s = "ab"; 合法，只是箭头改指了）。

记录假设（Documenting Assumptions）

• 定义与目的：写下一个变量的类型，就是在记录一条假设：「这个变量永远指向一个整数」。Java 在编译期检查这条假设。写下 final 是另一条假设：「这个变量初始化后不会再被赋值」，Java 同样静态检查。
• 直观解释（”它是什么？”）：程序里满是假设，而人的记忆不可靠。假设不写下来，三个月后的你（以及接手你代码的同事）只能靠猜。
• 关键规则与最佳实践：
  • 能自动检查的假设优先用语言机制表达（类型、final），因为机器检查永不疲倦。
  • 不能自动检查的假设（例如 n 必须为正）必须写进规格说明，必要时用运行期检查兜底。
  • 程序要同时服务两个目标：与计算机沟通（先让编译器相信程序语法与类型正确，再让逻辑在运行时给出正确结果）和与人沟通（让程序易于理解，以便将来有人能修好它、改进它、改造它）。

黑客式编程 vs. 工程化编程（Hacking vs. Engineering）

• 定义与目的：本讲写的冰雹代码其实相当「黑」。区分「黑」与「工程」的判断标准，是乐观主义与悲观主义的分野。
• 直观解释（”它是什么？”）：黑客相信「一次就能写对、bug 一眼就能找到」；工程师相信「一定会错，所以要提前布防」。
• 关键规则与最佳实践：
  • 坏：写一大堆代码才第一次测试；把所有细节记在脑子里；假设 bug 不存在或很容易修。
  • 好：一次写一点、边写边测（Reading 03 的测试优先编程）；把代码依赖的假设写下来；用静态检查替自己防御「愚蠢的错误」——尤其是自己的。

好软件的三大目标（The Big Three）

• 定义与目的：本课程的全部内容都围绕三个性质展开，每个语言特性、每种编程实践、每个设计模式都要问「它如何服务于这三点」。
• 直观解释（”它是什么？”）：把三大目标当成三把尺子，任何设计决策都拿它们量一量。
• 关键规则与最佳实践：
  • Safe from bugs（免受 bug 之害）：正确性（现在行为正确）与防御性（将来行为也正确）。静态检查、final、动态检查都有贡献。
  • Easy to understand（易于理解）：代码要与未来的程序员沟通，那个人很可能是几个月后的你自己。显式类型、写明假设的注释都有贡献。
  • Ready for change（为变化做好准备）：软件永远在变。静态检查在你改名字或改类型时，会立刻在所有使用处显示错误，提醒你同步修改；函数与接口把可变的部分隔离起来。
  • 还有其他重要性质（性能、可用性、安全性），它们可能与三大目标冲突，但三大目标是 6.031 最优先考虑的。

为什么这门课用静态类型语言（以及 TypeScript 与 Java 的取舍）

• 定义与目的：sp22 选择 TypeScript、sp21 选择 Java，理由高度一致：安全性与普遍性。
• 直观解释（”它是什么？”）：静态检查把安全性「调高」，让你先在一个安全的、被静态检查的语言里学会好的工程习惯，再迁移到动态语言。
• 关键规则与最佳实践：
  • 动态类型语言也在向静态化靠拢：Python 3.5+ 的类型注解 + Mypy，JavaScript + 类型声明 = TypeScript。这反映了工程界的普遍信念：静态类型是构建与维护大型系统的必需品。
  • 渐进类型（gradual typing）：同一份代码中，一部分有静态类型声明，另一部分没有——这让小原型可以平滑地长成大型可维护系统。
  • sp22 认为 TypeScript 相比 Java 类型系统更丰富、样板代码更少、更适合现代 Web 界面；Java 的优点则在于生态成熟、List/Set/Map 等 API 稳定、工具链完善。
  • 双方共同的缺点：语言都很大、背负历史包袱（switch 语句、原始类型），且都有内部不一致之处（如 Java 的 final 在不同上下文中含义不同，static 关键字与静态检查毫无关系）。
  • 最重要的一点：本课程教的不是语言特性，而是可迁移的能力——安全、清晰、抽象、工程直觉。

代码示例与对比分析

场景 1：把「值相关的错误」误当成「类型相关的错误」——大整数溢出

❌ 错误代码

// 错误：以为把两个 int 相乘就能得到 40 亿
public class Overflow {
    public static void main(String[] args) {
        int big = 200000;          // 200,000
        big = big * big;           // 期望 40,000,000,000
        System.out.println(big);   // 实际打印 1345294336 —— 完全错误的答案
    }
}

【错误代码的问题】

1. 编译期没有任何错误：int * int 类型完全正确，静态检查帮不上忙。
2. 运行期也没有任何错误：Java 对整数溢出不做动态检查，结果静默回绕成一个仍落在 int 范围内的错误数字。
3. 错误值会继续参与后续计算，直到某个完全无关的地方才暴露成怪现象，调试成本极高。
4. 如果在真实系统中这段代码用来算金额、速度、坐标，错误答案可能造成难以挽回的后果（见下文 Ariane 5 的故事）。

✅ 正确代码

// 正确：先想清楚取值范围，再选足够宽的类型
import java.math.BigInteger;

public class OverflowFixed {
    public static void main(String[] args) {
        long big = 200000L;              // 用 long 容纳 4e10
        big = big * big;
        System.out.println(big);         // 40000000000

        // 需要任意精度时用 BigInteger（对应 Python 的 int）
        BigInteger b = BigInteger.valueOf(200000);
        System.out.println(b.multiply(b));   // 40000000000
    }
}

【为什么这样更好】 这里的关键变化不是「写对了一个运算符」，而是先把假设写下来：200000² ≈ 4×10¹⁰，远超 int 的 2.1×10⁹。long 把可表示范围扩大到这个假设成立；BigInteger 则让假设「永不溢出」彻底成立。类型选择本身就是一条可被读者检验的文档。

【代码对比解说】 注意 200000L 里的 L：如果写成 long big = 200000; big = big * big;，Java 会先把 big 提升为 long 再做乘法，结果是正确的；但若写成 long big = 200000 * 200000;，右边两个 int 会先按 int 相乘溢出，再把已经错误的 1345294336 提升为 long——这是极其经典的陷阱。规则是：溢出发生在表达式求值的那一步，而不是赋值的那一步。

【设计原则透视】 对应 sp22 中的 Number.MAX_SAFE_INTEGER 陷阱：类型只界定「值的集合」，该集合的边界是表示不变量（representation invariant, RI）的一部分。静态类型系统保证「值属于某个类型」，但不保证「值落在有意义的范围内」。这正是「静态检查面向类型、动态检查面向具体值」这条分界线的具体体现——而当语言连动态检查都不做时，责任就落回程序员的设计上。在 Reading 11（抽象函数与表示不变量）中，我们会把「取值范围」正式写成 RI，并用测试去覆盖边界（Reading 03）。

场景 2：整数除法——最容易被静态检查放过的一类错误

❌ 错误代码

// 错误：5/9 在 int 域里求值，结果是 0
public class Celsius {
    public static double fahrenheitToCelsius(double f) {
        return (f - 32) * (5 / 9);   // 括号让它看起来像「先算比例」，实际先算出了 0
    }

    public static void main(String[] args) {
        System.out.println(fahrenheitToCelsius(212.0));   // 打印 0.0，而不是 100.0
    }
}

【错误代码的问题】

1. 编译期无错误：(double) * (int/int) 类型合法。
2. 运行期无异常：整数除法 5/9 == 0 是语言的正常行为，不抛错。
3. 结果为「看起来很像正确答案」的 0.0——比崩溃更危险，因为它可能被当成「温度本来就是 0 度」而流向生产环境。
4. 这个 bug 只会被某些输入触发；任何只用冻结温度（f = 32）的测试都无法发现它。

✅ 正确代码

// 正确：把常量写成 double，强制在浮点域求值
public class CelsiusFixed {
    public static double fahrenheitToCelsius(double f) {
        return (f - 32) * (5.0 / 9);   // 5.0/9 == 0.5555...
    }

    public static void main(String[] args) {
        System.out.println(fahrenheitToCelsius(212.0));   // 100.0
    }
}

【为什么这样更好】 5.0 是一个 double 字面量，因此 5.0 / 9 触发二元数值提升，在浮点域求值得到 0.555…，整条表达式随后都在 double 域中进行。更稳妥的写法还有 (f - 32) * 5 / 9（乘法先行，天然保持 double），但显式写 5.0 / 9 的可读性最好，因为它把「这是一个比例」这一意图直接写在了代码里。

【代码对比解说】 两种写法在字符上的差别只有两个字符（5 改成 5.0），语义差别却是「100 度」与「0 度」。这类 bug 的可怕之处在于它同时躲过了静态检查与动态检查：类型没错，值也没「非法」。唯一的防线是测试（Reading 03）：只要针对「非冻结温度」这一输入子域取一个测试用例，212.0 → 100.0 立刻失败。

【设计原则透视】 这是「原始类型不是真正的数」的教科书案例：int 上的 / 与数学上的除法不是同一个函数。从设计原则看，它同时违反了三目标中的两个——不安全（错误答案）且不易理解（5/9 的读者必须自己推断求值域）。修复它的手段（写 5.0）本质上是在代码里显式记录求值域的假设，这正是本讲「记录假设」的实践。

场景 3：固定长度数组造成缓冲区溢出——用 List 替代

❌ 错误代码

import java.util.List;
import java.util.ArrayList;

// 错误：用魔法数字 100 装一个长度不可预测的序列
public class HailstoneBuggy {
    public static int[] hailstoneSequence(int n) {
        int[] a = new int[100];     // <==== DANGER, WILL ROBINSON!
        int i = 0;
        while (n != 1) {
            a[i] = n;
            i++;
            if (n % 2 == 0) {
                n = n / 2;
            } else {
                n = 3 * n + 1;
            }
        }
        a[i] = n;
        i++;
        return a;                   // 返回长度恒为 100 的数组，有效元素只有 i 个
    }
}

【错误代码的问题】

1. 100 是魔法数字：hailstoneSequence(27) 需要 112 项，立刻抛出 ArrayIndexOutOfBoundsException——一个只在特定输入下才发生的运行期错误。
2. 返回值的契约模糊：数组长度恒为 100，调用者无法判断哪些元素有效；一旦调用者用 a.length 去遍历，就会读到一堆无意义的 0。
3. 在 C/C++ 里这不再是异常而是缓冲区溢出：越界写入会破坏相邻内存，历史上造成过大量网络安全事件与网络蠕虫。
4. 代码把「序列有多长」这一假设硬编码进来，任何关于序列长度的新事实（例如数学上的新结果）都需要改动多处。

✅ 正确代码

import java.util.List;
import java.util.ArrayList;

// 正确：用自动扩容的 List，长度由数据自己决定
public class Hailstone {
    /**
     * Compute a hailstone sequence.
     * @param n starting number for sequence; requires n > 0.
     * @return hailstone sequence starting with n and ending with 1.
     */
    public static List<Integer> hailstoneSequence(final int n) {
        final List<Integer> list = new ArrayList<Integer>();
        int current = n;
        while (current != 1) {
            list.add(current);
            if (current % 2 == 0) {
                current = current / 2;
            } else {
                current = 3 * current + 1;
            }
        }
        list.add(current);
        return list;
    }
}

【为什么这样更好】 List 会自动随元素增加而扩容（直到内存耗尽），因此「序列长度」这一假设彻底从代码中消失，也就没有了 ArrayIndexOutOfBoundsException。返回类型 List<Integer> 的 size() 精确等于有效元素个数，调用者不再需要猜。同时规格说明明确写出了前置条件（requires n > 0）与后置条件（以 n 开始、以 1 结束），把类型表达不了的假设写了下来。

【代码对比解说】 这里有三处修改值得逐条体会：第一，容器从定长数组改为可变长 List，把「长度」这个不可控因素交给容器管理；第二，声明类型用接口 List 而不是实现类 ArrayList，让实现可以随时替换而不影响客户代码（对应 Reading 12 的接口与实现分离）；第三，在规格说明中显式写出 n > 0。第三点尤其重要：Java 编译器不会检查 n > 0，它是一条纯文档假设，但是它的缺失会导致 n = 0 时无限循环（0 是偶数，永远除以 2 还是 0），n = -5 时陷入 -5 → -14 → -7 → -20 → -10 → -5 的死循环。

【设计原则透视】 数组版本暴露的是表示不变量被破坏：0 <= i < a.length 是这段代码必须始终成立的 RI，而代码没有任何机制保证它（见 Reading 11）。List 版本把这个不变量交给容器自身承担，从而在抽象边界上把「不可能出错」变成结构性事实。此外，接口类型 List 让客户不依赖具体表示，这是「为变化做好准备」的直接体现：把 ArrayList 换成 LinkedList 时，客户代码无需改动。

场景 4：final 把「不重新赋值」的假设交给编译器

❌ 错误代码

import java.util.List;
import java.util.ArrayList;

// 错误：循环体反复重写参数，规格说明中的假设在循环里悄悄失效
public class HailstoneMutating {
    /**
     * @param n starting number for sequence; requires n > 0.
     * @return hailstone sequence starting with n and ending with 1.
     */
    public static List<Integer> hailstoneSequence(int n) {
        List<Integer> list = new ArrayList<Integer>();   // 从未被重新赋值，却不是 final
        while (n != 1) {
            list.add(n);
            if (n % 2 == 0) {
                n = n / 2;          // 参数被重新赋值
            } else {
                n = 3 * n + 1;      // 参数被重新赋值
            }
        }
        list.add(n);
        return list;
    }
}

【错误代码的问题】

1. 参数 n 在循环中被反复改写，规格说明里「n 是序列的起始值」这一说法在循环体内部不再成立，读者必须时刻跟踪它的当前含义。
2. list 明明从未被重新赋值，却声明为可变引用：读者要通读整个方法体才能确认这一点，编译器也无法替他确认。
3. 这类「顺手复用参数」的习惯在方法变长以后极易演变成真正的 bug，例如某次改动把循环后的 n 当成起始值使用。
4. 假设没有被写下来，也就没有被检查——一旦有人后来往循环里加了一行改写 n 的代码，没有任何提示。

✅ 正确代码

import java.util.List;
import java.util.ArrayList;

// 正确：参数只读，循环用独立的局部变量；能加 final 的都加上
public class HailstoneFinal {
    /**
     * @param start starting number for sequence; requires start > 0.
     * @return hailstone sequence starting with start and ending with 1.
     */
    public static List<Integer> hailstoneSequence(final int start) {
        final List<Integer> list = new ArrayList<Integer>();
        int current = start;                 // 唯一的可变变量，职责清晰
        while (current != 1) {
            list.add(current);
            if (current % 2 == 0) {
                current = current / 2;
            } else {
                current = 3 * current + 1;
            }
        }
        list.add(current);
        return list;
    }
}

【为什么这样更好】 参数 start 与容器 list 都加了 final：编译器会静态检查它们从不被重新赋值，这条「不会变」的假设从此不需要读者去验证。方法里只剩一个可变量 current，它的含义在整个方法内保持稳定（「当前正在处理的冰雹数」），读者可以放心地只看它的名字。若将来有人误在循环里写 start = ...，编译器会立刻报错，把 bug 挡在编译期。

【代码对比解说】 变量数量没有变（仍然是三个），但职责边界变清晰了：start 是只读输入，list 是只读引用（内容可变），current 是唯一的状态载体。final 的代价几乎为零（多打六个字母），收益是编译器替你守护一条不变量。注意 final List<Integer> list 只保证引用不被重赋，list.add(...) 完全合法——这正是「不可重新赋值的引用」与「不可变的值」之间的区别，Reading 02 会用快照图把这一点画清楚，Reading 08 会讨论如何用 Collections.unmodifiableList 让值本身也不可变。

【设计原则透视】 final 是本讲「记录假设」原则的语言化表达：类型记录「值属于哪个集合」，final 记录「引用不再改变」，规格说明记录「值必须满足什么条件」。三者构成一个从强到弱的假设梯度：类型由编译器完全检查，final 由编译器完全检查，前置条件必须靠文档加运行期检查。一个成熟的工程师会把尽可能多的假设推到「编译器能检查」的那一端。

场景 5：把「值相关的错误」写进规格说明并用防御性检查兜底

❌ 错误代码

// 错误：规格说明里什么都不说，调用者只能靠猜
public class Average {
    public static double average(int sum, int n) {
        return sum / n;          // n == 0 时抛 ArithmeticException
    }
}

【错误代码的问题】

1. 方法契约完全没有说明 n 不能为 0，调用者无法从签名或注释中得知这个约束。
2. 一旦传入 0，运行期抛出 ArithmeticException；如果传入的是 double 类型的 0，则连异常都没有，直接得到 NaN 或 Infinity 并继续传播。
3. 错误在离调用点很远的地方才暴露，定位成本高。
4. 规格说明缺失会让测试无从下手：不知道哪些输入是「合法的」，也就无法写出正确的测试套件（Reading 03 强调「测试套件必须是规格说明的合法客户」）。

✅ 正确代码

// 正确：把前置条件写进规格说明，并在运行期显式检查
public class Average {
    /**
     * @param sum the sum of the values being averaged
     * @param n how many values were summed; requires n > 0
     * @return the arithmetic mean sum / n
     * @throws IllegalArgumentException if n <= 0
     */
    public static double average(int sum, int n) {
        if (n <= 0) {
            throw new IllegalArgumentException("n must be positive, but was " + n);
        }
        return (double) sum / n;
    }
}

【为什么这样更好】 规格说明把「n > 0」这条编译器无法检查的假设写了下来，调用者读一眼就知道自己的责任。运行期检查把「不检查」变成「动态检查」：错误在出错的那一行立刻以清晰的异常信息暴露，而不是变成一个 NaN 传染给整个程序。注意 (double) sum / n：显式转换避免了整数除法带来的截断，这是场景 2 的教训在这里的复现。

【代码对比解说】 关键转变是把一条隐式假设变成三层显式声明：注释（给人看）、异常声明（给调用者看）、运行期检查（给运行时看）。有人会认为运行期检查「浪费性能」，但对于一个 n <= 0 就完全无意义的函数，这正是「工程师是悲观主义者」的具体体现——防御性检查的成本是几纳秒，收益是不必在半夜排查一个 NaN。

【设计原则透视】 这段代码展示了本讲全部三条主线的交汇：类型（int sum, int n）由编译器静态检查，前置条件（n > 0）只能靠文档与运行期检查，而「把假设写下来」直接服务于 Easy to understand。到了 Reading 06（规格说明）我们会把前置条件、后置条件、异常行为形式化成更严格的契约；到了 Reading 07（设计规格说明）我们会讨论「前置条件该由谁负责检查」这一经典权衡。

（sp22 原版 TypeScript 写法对照）

// sp22 原版 TypeScript 写法：const 提供「不可重新赋值」的静态检查
const n: number = 5;          // 终生指向 5
let m: number = 5;            // 可重新赋值
m = m + 1;                    // 合法
// n = n + 1;                 // 静态错误：Cannot assign to 'n' because it is a constant.

// const 只固定引用，不冻结值：数组内容仍可变
const array: Array<number> = [];
array.push(5);                // 合法：引用没变，值变了

// TypeScript 的静态类型在编译后会被丢弃，生成的是纯 JavaScript：
//   function hello(name: string): string { return 'Hi, ' + name; }
// 编译为
//   function hello(name) { return 'Hi, ' + name; }
// 所以运行期的一切行为仍由 JavaScript 的（常常不做检查的）语义决定。

这组 TypeScript 写法与 Java 的 final 形成精确对应：const ↔ final，都只约束引用而不冻结值；而 TypeScript 编译后丢弃类型信息这一点，提醒我们「静态检查只存在于编译期」，运行期的安全仍需靠设计与测试（Reading 03）来保证。

与其他设计原则的关联

• 与 Reading 02（基本 Java / Basic Java）：本讲只把类型当作「值的集合 + 操作」来介绍，Reading 02 会把它落到具体语法上——原始类型与对象类型的区别、== 与 .equals()、List/Set/Map、final 与可变对象的组合，并用快照图把「重新赋值 vs. 改变值」可视化。本讲场景 3 中的 List<Integer> 在 Reading 02 会展开为完整的集合 API。
• 与 Reading 03（测试 / Testing）：本讲反复强调「静态检查抓不到与具体值相关的错误」。如何抓住它们？答案是系统化测试。Reading 03 的输入空间划分与边界值正对应本讲中的整数溢出、Integer.MIN_VALUE、空字符串、空集合——本讲场景 2 的整数除法 bug 只有靠一个「非边界温度」的测试用例才能发现。
• 与 Reading 04（代码审查 / Code Review）：本讲说「写一点点、测一点点」「把假设写下来」，代码审查是把这两条落到团队流程上的实践：让另一个人用本讲的三把尺子（安全、易理解、可修改）来读你的代码。
• 与 Reading 06（规格说明 / Specifications） 和 Reading 07（设计规格说明 / Designing Specifications）：本讲第一次出现了「规格说明」与「前置条件」，正式的契约式设计在那里展开。
• 与 Reading 08（不可变性 / Immutability）：本讲区分了「不可重新赋值的引用」与「不可变的值」，Reading 08 会系统化不可变性的设计原则，并说明它为什么是「Ready for change」的核心武器。
• 与 Reading 09（避免调试 / Avoiding Debugging）：本讲提出的「工程师是悲观主义者」在 Reading 09 中被系统化成一系列构造性建议（如 assert、快速失败、把假设变成检查）。
• 与 Reading 11（抽象函数与表示不变量 / Abstraction Functions & Rep Invariants）：本讲场景 3 中的 0 <= i < a.length 是一条尚未命名的表示不变量，Reading 11 会给出 RI/AF 的正式框架。
• 与 Reading 21–23（并发 / Concurrency、线程安全 / Thread Safety、锁 / Locks）：本讲「避免改变」的直觉在并发中变成硬性要求——共享可变状态是线程安全问题的根源。

关键要点

• 把检查尽量往左移：静态检查优于动态检查，动态检查优于不检查。写每一行代码时都问自己「这个错误会在哪一档被抓住」，抓不住的地方必须额外布防。
• 区分「面向类型」与「面向值」的错误：编译器能保证变量持有某个合法值，但永远不知道是哪一值。除零、越界、非法转换、溢出、精度丢失都只能靠测试与设计来防。
• 假设必须写下来：类型和 final 交给编译器检查；前置条件写进 Javadoc，并用运行期检查兜底。没写下来的假设，未来一定会被忘记。
• 优先选择「不变量由结构保证」的设计：用自动扩容的 List 代替 int[100]，永远不要让魔法数字承担正确性责任。
• 用三大目标检验每一个设计决策：Safe from bugs / Easy to understand / Ready for change。

常见陷阱与注意事项

1. 以为「编译通过」就等于「正确」：big = big * big; 与 (f - 32) * (5 / 9) 都能顺利编译。→ 后果：静默的错误答案，且会继续向程序下游传播。
2. 把 int 当成数学上的整数：忘记 5/2 == 2、超出 ±2³¹ 会回绕、double 超过 2⁵³ 后 x + 1 == x。→ 后果：数值结果错误，且错误只在特定数值范围内出现，测试容易被「恰好选中安全值」而漏过。
3. 用 == 比较对象（本讲铺垫，Reading 02 详述）：== 在 Java 中对对象重载为「是否指向同一对象」。→ 后果：字符串内容相同却返回 false，或因为字符串驻留（interning）而「偶尔正确」，成为最难查的一类 bug。
4. 把参数当作可随意改写的临时变量：在循环里反复修改参数。→ 后果：规格说明中「参数是起始值」的假设失效，后续维护者读到循环后的参数值时会得到错误结论；也无法对它加 final。
5. 忽略前置条件：hailstoneSequence(0) 或 hailstoneSequence(-5) 会无限循环；average(sum, 0) 会抛异常。→ 后果：程序挂死或崩溃，而且发生在与错误源头无关的位置。
6. 依赖 C/C++ 式的「数组越界无所谓」直觉：Java 会抛 ArrayIndexOutOfBoundsException，但不代表可以靠它兜底。→ 后果：把本该在编译期或设计期解决的问题留到生产环境的运行期。

思考题（带答案）

问题 1：下面这段 Java 代码在编译期、运行期分别会出什么问题？如果没有问题，结果是否等于 8.0？

double x = 16.0;
double y = 2;
double z = x / y;      // 期望 8.0
int w = 5 / 2;         // 期望 2.5

答案：x / y 没有任何问题：x 是 double，二元数值提升让 y 也变成 double，结果是 8.0。int w = 5 / 2; 编译通过、运行通过，但结果是 2 而不是 2.5——两个 int 之间的 / 是整数除法，小数部分被截断，这是「不检查」的典型例子：既不是静态错误，也不是动态错误，只是错误答案。这正对应本讲判断框架中的第三档。

问题 2：为什么 Math.sin("30") 是静态错误，而 Integer.valueOf("8000000000") 是动态错误？请用「类型 vs. 具体值」这条分界线解释。

答案：Math.sin 的签名是 sin(double)，参数类型是 double，而 "30" 的类型是 String。这种不匹配在编译期就完全可见，编译器不需要知道任何运行期的值就能判定它非法，因此是静态错误。相反，Integer.valueOf(String) 的参数类型就是 String，类型完全正确；错误只发生在这个具体字符串无法被解析成 int 范围内的十进制整数时——"8000000000" 是 80 亿，超出了 int 的合法范围。编译器无法预知运行时收到哪个字符串，只能由运行期抛出 NumberFormatException。这条分界线可以概括为：静态检查面向类型（值的集合），动态检查面向具体值。

问题 3：本讲的 hailstoneSequence 规格说明写了 requires n > 0。为什么不能像类型那样让编译器检查它？如果不写这条前置条件，可能出现什么后果？你能想出两种让这条假设被强制检查的手段吗？

答案：n > 0 是一个关于值的约束，而编译器只知道 n 是 int；int 的合法值集合包含负数和 0，因此「正整数」不是一个可以用 Java 类型表达的集合（除非定义一个 PositiveInt 类，把约束编码进构造过程——这是 Reading 11 中表示不变量的思路）。不写这条前置条件，调用者可能传入 0（0 是偶数，0/2 == 0 永远循环）或 -5（进入 -5 → -14 → -7 → -20 → -10 → -5 的环），程序静默挂死。两种强制检查手段：其一，在方法开头写运行期检查 if (n <= 0) throw new IllegalArgumentException(...)，把「不检查」升级为「动态检查」；其二，在规格说明中把它变成调用者的义务，并由测试套件保证只使用合法输入（这个「让违反前置条件的调用成为调用者的 bug」的立场将在 Reading 06/07 中正式讨论）。

Reading 2: Java 基础（sp22 原版为 Basic TypeScript）

说明：本讲 sp22 原版使用 TypeScript，本笔记按用户要求提供 Java 代码示例；类型/API 与 sp21（6.031 Java 版）原文保持一致。文中凡涉及本讲之外、属于 Java 生态的额外知识，均以「补充说明」标注。

概述

本讲的目标是从 Python 平滑过渡到静态类型语言的日常写法：学会基本语法与语义，掌握快照图（snapshot diagram） 这一描述运行时状态的通用工具，并建立「原始类型 vs. 对象类型」「重新赋值 vs. 改变值」「可变 vs. 不可变」三组贯穿全课程的核心区分。它同时服务于三大目标：泛型与静态类型让集合操作免受 bug 之害（Safe from bugs），快照图与 final 让「谁在什么时候改了什么东西」变得易于理解（Easy to understand），而「声明接口类型、选择实现类」的习惯让代码为变化做好准备（Ready for change）。

核心概念与设计原则详解

快照图（Snapshot Diagram）

• 定义与目的：快照图是程序在某一时刻的运行时内部状态的图示，包含栈（stack）（正在进行的方法及其局部变量）与堆（heap）（当前存在的对象）。它让我们能用图而不是用嘴来讨论「不可变的值 vs. 不可重新赋值的引用」「指针别名（aliasing）」「栈 vs. 堆」「抽象 vs. 具体表示」这些微妙问题。
• 直观解释（”它是什么？”）：把变量画成一支持有箭头的标签，箭头指向一个值；原始类型的值直接写在箭头旁边，对象类型的值是堆上的一个圆圈（气泡），圆圈里可以写字段名与字段值。给引用加双箭头表示「不可重新赋值」（final），给对象圆圈加双边框表示「不可变值」（如 String）。
• 关键规则与最佳实践：
  • 语法是灵活的，不必画出全部细节：只画与当前讨论相关的部分。讨论字符串内容时画字符，讨论对象身份时只画一个圆圈。
  • 赋值（x = ...）改变箭头的指向；修改（list.add(...)、sb.append(...)）改变箭头所指气泡的内部。
  • 双线（双箭头 / 双边框）只在需要强调「不可变」时使用；当可变性显而易见或不相关时，保持单线，避免图画得太吵。
  • 快照图的记法适用于任何现代语言（Python、Java、C++、Ruby），并在后续课程中泛化为对象模型。
  • 在 6.031 中，快照图是团队沟通工具：课堂讨论、结对编程、代码评审时都可以画。

原始类型与对象类型（Primitive Types vs. Object Types）

• 定义与目的：Java 把值分成两类，理解这个区分是理解 ==、参数传递、内存布局的前提。它首先服务于 Safe from bugs（选错类型会导致错误的相等性判断）。
• 直观解释（”它是什么？”）：原始类型的值就是值本身（一个小方块里写着 5）；对象类型的值是一个「指针」，指向堆上的一个气泡。因此原始类型没有内部结构，而对象类型可以有内部结构（引用其他原始值或对象）。
• 关键规则与最佳实践：
  • 原始类型：int、long、boolean、double、float、char 等，约定全部小写，占用固定的小块内存。
  • 对象类型：String、BigInteger、List、Turtle 以及自定义类，约定首字母大写，占用可变且可能很大的内存。
  • 判别规则（来自本讲练习）：原始类型并不只是「数值」，char 是原始类型而 String 不是；判别的可靠依据是约定的大小写、是否有内部结构、是否占用固定小内存。
  • 每个原始类型都有包装类型（wrapper type）：int/Integer、long/Long、double/Double。Java 会在两者之间自动装箱（boxing）与拆箱（unboxing），所以 Integer i = 5; 合法。
  • 泛型参数只能是对象类型，因此写 List<Integer> 而不是 List<int>；遍历时优先用原始类型 int num，因为原始类型的 == 更简单可靠。

改变值 vs. 重新赋值变量（Mutating Values vs. Reassigning Variables）

• 定义与目的：这是本讲最重要的一组区分。混淆它们会直接导致共享可变状态引发的 bug，也会让人误以为 final 就意味着「不可变」。
• 直观解释（”它是什么？”）：重新赋值是把变量的箭头指向另一个气泡；改变值是让同一个气泡里的内容发生变化。前者改变「谁」，后者改变「什么」。
• 关键规则与最佳实践：
  • String s = "a"; s = s + "b"; 是重新赋值：s 从指向 "a" 改为指向新对象 "ab"（String 不可变，原对象没变）。
  • StringBuilder sb = new StringBuilder("a"); sb.append("b"); 是改变值：箭头没动，气泡内部从 "a" 变成 "ab"。
  • 参数传递永远是「按值传递引用」：方法内对参数重新赋值不影响调用者；对参数所指对象修改会影响调用者。因此 void f(String s, StringBuilder sb) { s.concat("b"); s += "c"; sb.append("d"); } 在调用 f(t, tb) 之后，t 仍是 "a"（s += "c" 只是让局部变量 s 改指新对象，s.concat("b") 的返回值被丢弃），而 tb 变成 "ad"。
  • 只读方法（如 concat）返回新对象而非修改原对象；修改方法（如 append）返回 this 并改变内部状态。API 文档会写明是哪一种。

不可变值与不可重新赋值的引用（Immutable Values vs. Unreassignable References）

• 定义与目的：Java 提供两种「不变」的保证，分别作用于值和引用。理解它们正交组合出的四种情况，是安全设计的基础。
• 直观解释（”它是什么？”）：不可变类型（immutable type）：值一旦创建就永远不变（String）。不可重新赋值的引用：变量只被赋值一次（final）。二者相互独立，可以任意组合。
• 关键规则与最佳实践：
  • final int n = 5;：n 终生指向 5，重新赋值会产生编译错误——final 提供的是静态检查。
  • final 引用可以指向可变对象：final StringBuilder sb = new StringBuilder("a"); sb.append("b"); 完全合法。
  • 非 final 引用可以指向不可变值：String s = "a"; s = "ab"; 合法，只是箭头改指了。
  • 优先用 final 声明方法参数与尽可能多的局部变量：它既是给读者的文档，也被编译器检查。
  • 不可变性是 Safe from bugs 的基石：不可变对象可以被自由共享（别名不再是威胁），也天然线程安全（见 Reading 21）。

== 与 .equals()：两种相等性

• 定义与目的：Java 对原始类型与对象类型使用不同的相等性测试，用错会得到「内容相同却不相等」的结果。这是本讲最直接对应 Safe from bugs 的一条规则，也是 Python 背景学生最容易踩的坑。
• 直观解释（”它是什么？”）：== 对原始类型比较值（5 == 5 为 true，'a' == 'a' 为 true）；对对象类型比较身份（两个箭头是否指向同一个气泡），在 Python 中对应的是 is。.equals() 对对象比较内容（"abc".equals("abc") 为 true）。
• 关键规则与最佳实践：
  • 比较原始类型（int、char、double）用 ==；比较对象（List、数组、String、其他对象）用 .equals()。
  • 在原始类型上调用方法（如 5.equals(5)）是静态错误，因为 Java 不允许在原始类型上调用方法——这算是幸运的，错误很容易被发现。
  • 反过来，在对象上用 == 不会报错，只会安静地给出错误答案，这才是真正危险的方向。
  • 危险点还在于「优化会掩盖 bug」：String s = "foobar"; String t = "foobar"; 时 s == t 很可能返回 true，因为 Java 复用了同一个字符串对象（字符串驻留）。这会让写错的代码在测试中「碰巧通过」。
  • char 是原始类型，字面量用单引号（'a'）；String 是对象，字面量用双引号（"abc"、""），二者不可混用。

集合：List、Set 与 Map（Java Collections）

• 定义与目的：三门「日常数据结构」，分别对应有序可重复序列、无序不重复集合、键值映射。它们的共同价值是：把「容器大小管理」这件容易出错的事交给库去承担（回忆 Reading 01 的 int[100] 缓冲区溢出）。
• 直观解释（”它是什么？”）：List 像 Python 的 list（有顺序、可重复）；Map 像 Python 的 dict（键必须可哈希）；Set 像数学集合（要不就在里面，要不就不在）。
• 关键规则与最佳实践：
  • List：lst.size()、lst.add(e)、lst.isEmpty()、lst.contains(e)、lst.get(i)、lst.set(i, e)。
  • Map：map.put(k, v)、map.get(k)、map.containsKey(k)、map.remove(k)。
  • Set：s1.contains(e)、s1.containsAll(s2)（判断 s1 ⊇ s2）、s1.removeAll(s2)。
  • 快照图记法：List 画成带下标字段的对象，Map 画成含键/值对的对象，Set 画成一组无名字段的对象。
  • 键必须可哈希：Map 的键与 Set 的元素必须是「适合做键的类型」；在 Java 中这意味着它们必须正确实现 hashCode 与 equals（Reading 15 会详细展开）。

字面量（Literals）与不可变集合

• 定义与目的：快速构造集合的语法糖，同时引入「不可变集合」这一安全默认值。
• 直观解释（”它是什么？”）：Java 没有 Python 那样的 list/dict 字面量，但有数组字面量，以及 List.of / Set.of / Map.of 这些静态工厂方法。
• 关键规则与最佳实践：
  • 数组字面量：String[] arr = { "a", "b", "c" };——注意这创建的是数组，不是 List。
  • List.of("a", "b", "c") 创建不可变 List：不能添加、删除或替换元素。
  • Set.of("a", "b", "c")、Map.of("apple", 5, "banana", 7) 同理，创建不可变集合。
  • 需要「已初始化但可变」的 List 时，用拷贝构造：new ArrayList<>(List.of("Huey", "Dewey", "Louie"))。这比连续调用多次 add() 简洁得多。
  • 在测试中优先使用不可变字面量，可以防止测试用例之间通过共享集合互相污染。

泛型（Generics）：声明集合变量

• 定义与目的：泛型让集合限制元素的类型，从而让编译器静态检查「只加入正确类型的元素」，并在取出元素时保证类型正是所期望的。这是 Reading 01「静态检查」在容器上的直接应用。
• 直观解释（”它是什么？”）：List<String> 读作「装着 String 的 List」。它是给容器贴标签，而不是给元素贴标签。
• 关键规则与最佳实践：
  • 声明形式：List<String> cities;、Set<Integer> numbers;、Map<String,Turtle> turtles;。
  • 不能创建原始类型的集合：Set<int> 非法，必须写 Set<Integer>。
  • 自动装箱/拆箱让包装类型几乎无感：sequence.add(5); 把 5 包装成 Integer；int second = sequence.get(1); 自动拆箱为 int。
  • 构造时的菱形语法省略右侧参数：List<String> names = new ArrayList<>();。
  • 补充说明：raw type（裸类型，如 List numbers）会关闭泛型检查，只在维护遗留代码时才会遇到；新代码一律使用泛型。

接口与实现类：ArrayList、LinkedList、HashSet、HashMap

• 定义与目的：Java 帮我们区分规格说明（这个类型做什么）与实现（代码长什么样）。List、Set、Map 都是接口（interface），只规定行为，不提供实现；使用者可以在不同场景选择不同实现。
• 直观解释（”它是什么？”）：接口是「插座标准」，实现类是「具体的插座」。你的电器（客户代码）只依赖标准，因此可以随时换插座。
• 关键规则与最佳实践：
  • 创建：List<String> firstNames = new ArrayList<>();、List<String> lastNames = new LinkedList<>();。
  • ArrayList 与 LinkedList 都完整提供 List 的全部操作，行为完全一致，只是性能不同；互换它们不会破坏代码。
  • 在 6.031 中：拿不准就用 ArrayList；Set 默认用 HashSet（需要有序时用 TreeSet）；Map 默认用 HashMap。
  • 声明变量与返回类型时永远写接口类型（List 而非 ArrayList），这样实现可以随需求变化而替换。
  • 用另一个集合初始化：new ArrayList<>(Set.of("Duck"))。

迭代（Iteration）

• 定义与目的：遍历集合是最常见的任务，for-each 语法让这件事简洁且不易出错。
• 直观解释（”它是什么？”）：for (String city : cities) 读作「对 cities 中的每个 city」。底层使用 Iterator 设计模式（本课程后段会展开）。
• 关键规则与最佳实践：
  • List 与 Set 都可以直接 for-each；Map 不能直接 for-each，需要遍历 turtles.keySet()（或 values()、entrySet()）。
  • 循环变量写原始类型：for (int num : numbers) 而不是 Integer num，因为原始类型的相等性判断更简单、更不易出错。
  • 绝不要在迭代过程中修改正在遍历的集合：添加、删除或替换元素会破坏迭代，甚至让程序崩溃（ConcurrentModificationException）。这条警告对 Python 同样成立。
  • 需要下标时才写 for (int ii = 0; ii < cities.size(); ii++)；这种写法冗长，且藏 bug 的地方更多（起始值写成 1、用 <= 而不是 <、某处变量名写错等）。

变量声明与作用域（Variable Declarations and Scope）

• 定义与目的：Java 的局部变量作用域是它所在的那一对花括号，这与 Python「函数级作用域」不同，会导致一类「在分支里声明、在分支外使用」的编译错误。
• 直观解释（”它是什么？”）：花括号是一道墙，墙内声明的变量出了墙就不存在。
• 关键规则与最佳实践：
  • int b = 2; 写在 if 块里，块外的 b *= 3; 就是静态错误（cannot find symbol）。
  • 正确的修法是在分支之前声明并初始化：int b = 0; if (...) { b = 2; } else { b = 4; } b *= 3;。注意 Java 要求局部变量在使用前确定被赋值，所以如果注释掉 else 分支，编译器会在最后一行报「变量可能未初始化」——这是编译期发现的错误，而不是运行期。
  • TypeScript 对照（sp22 原版写法）：TypeScript 用 let（可重新赋值）与 const（不可重新赋值）声明局部变量，const 提供不可重新赋值的静态检查；let/const 的作用域同样是所在花括号，而老式的 var 是函数级作用域，已被强烈不推荐。Java 中最接近 const 的机制是 final，其作用域规则本质上与 let 相同（都在花括号内），没有 var 那样的函数级作用域问题。
  • 补充说明：Java 10+ 提供 var 关键字做局部变量类型推断（var x = 5;），但它仍是静态类型——类型在编译期被推断出来，与 JavaScript 的 var 完全无关，不要因同名而混淆。

枚举（Enumerations）

• 定义与目的：当一个类型只有小的、有限的一组不可变取值时（月份、星期、罗盘方位、可选颜色），枚举让这些取值成为命名常量，并且是一个全新的类型，因而可以被静态检查。
• 直观解释（”它是什么？”）：枚举把「一堆散落的常量」升级为一个类型。以往用 int 或字符串常量表示时，任何整数或任何字符串都能被塞进去；枚举则只接受它自己列出的那几个值。
• 关键规则与最佳实践：
  • 声明：public enum PenColor { BLACK, GRAY, RED, PINK, ORANGE, YELLOW, GREEN, CYAN, BLUE, MAGENTA; }
  • 使用：PenColor drawingColor; drawingColor = PenColor.RED;——像命名静态常量一样引用。
  • 枚举比数值常量更类型安全：int month = TUESDAY; 不会报错（如果用的是整数常量），而 Month month = DayOfWeek.TUESDAY; 是静态错误。
  • 枚举能抓住拼写错误：String color = "REd"; 不会报错，而 PenColor drawingColor = PenColor.REd; 是静态错误。
  • Python 3 也有枚举，但不做静态类型检查——这正是 Java 枚举的优势。

API 文档与规格说明（API Documentation and Specifications）

• 定义与目的：API（application programming interface）是别人提供的、你可以编程调用的方法与类。API 文档中的详细描述就是规格说明（specification），它让你无需阅读实现代码就能正确使用 String、Map、BufferedReader。
• 直观解释（”它是什么？”）：文档是「黑盒说明书」，实现是「白盒内部」。规格说明的存在，正是抽象边界得以成立的前提。
• 关键规则与最佳实践：
  • 读文档的顺序：类描述 → 构造器摘要 → 方法摘要 → 点击具体方法看方法签名（返回类型、方法名、参数、可能抛出的异常）、完整描述、参数说明、返回值说明。
  • 类层次与方法摘要能帮你发现「HashMap 是 Map 的实现」这类关系。
  • 用搜索框直接跳到类、接口或方法，是查阅 API 的最快路径。
  • TypeScript 对照（sp22 原版写法）：TypeScript 的三处文档来源是 MDN JavaScript 参考（通用特性与浏览器 API）、Node.js 参考（非浏览器 API，如 fs.readFileSync、os.homedir）以及 TypeScript Handbook（TypeScript 特有特性）。Java 的对应物是 Java API 文档中的 java.lang.String、java.util.List、java.util.Map、java.io.BufferedReader 等。

TypeScript 与 Java 语法对照速查（本讲 sp22 内容的 Java 对应写法）

代码示例与对比分析

（sp22 原版 TypeScript 写法对照：变量声明、作用域与 record type）

// sp22 原版 TypeScript 写法
let a: number = 5;              // 可重新赋值     ↔ Java: int a = 5;
const b: number = 5;            // 不可重新赋值   ↔ Java: final int b = 5;

if (a > 10) {
  let c: number = 2;            // 作用域仅限这一对花括号   ↔ Java: int c = 2;
} else {
  // c 在这里不可见：TypeScript 与 Java 一样是块级作用域
  // c = 4;                     // 静态错误：Cannot find name 'c'
}

// 对象字面量与 record type
let point: { x: number, y: number } = { x: 5, y: 2 };
// Java 没有对象字面量；最接近的是 Java 16+ 的 record：
//   record Point(int x, int y) { }
//   Point point = new Point(5, 2);

// 解构赋值（Java 没有对应语法）
// const { quotient, remainder } = integerDivision(23, 7);

两者的块级作用域规则是一致的，所以「在 if 分支里声明、在分支外使用」在两种语言里都是编译错误；差别在于 Java 没有对象字面量、record type 与解构赋值，需要写一个显式的类（或使用 record）来打包多个返回值。

场景 1：用 == 比较对象内容——最典型的「不报错的 bug」

❌ 错误代码

// 错误：用 == 比较字符串内容
public class NameCheckBuggy {
    public static void main(String[] args) {
        String s = "foobar";
        String t = "foobar";
        System.out.println(s == t);            // 打印 true —— 靠的是字符串驻留，纯属运气

        String u = new String("foobar");
        System.out.println(s == u);            // 打印 false —— 内容一样却「不相等」
    }
}

【错误代码的问题】

1. s == t 返回 true 不是因为内容相同，而是因为 Java 复用了同一个字符串对象（字符串驻留）。这个「优化」会让写错的代码在测试中碰巧通过。
2. s == u 返回 false：内容完全相同却判定不相等，逻辑随之走错分支。
3. 正确性依赖于「字符串从哪里来」这一与语义无关的实现细节，属于典型的不可靠代码：把字面量换成从文件或网络读入的字符串，行为立刻改变。
4. 编译期毫无提示，运行期也不抛异常，错误会静默传播到很远的地方。

✅ 正确代码

// 正确：对象比内容用 equals()，原始类型比值用 ==
public class NameCheck {
    public static void main(String[] args) {
        String s = "foobar";
        String t = "foobar";
        String u = new String("foobar");

        System.out.println(s.equals(t));       // true —— 内容相同
        System.out.println(s.equals(u));       // true —— 内容相同，与对象身份无关

        int i1 = 5;
        int i2 = 5;
        System.out.println(i1 == i2);          // true —— 原始类型比较值

        char c1 = 'a';
        char c2 = 'a';
        System.out.println(c1 == c2);          // true —— char 是原始类型
    }
}

【为什么这样更好】 equals() 问的是「内容是否相同」，这正是几乎所有业务逻辑真正关心的问题；它给出的答案不依赖对象从哪来、是否被驻留、是否被缓存，因此行为稳定、可预测。而 == 只在原始类型上表达「值相同」，语义清晰无歧义。

【代码对比解说】 这段代码的教学价值在于它把一条规则拆成了两个方向：== 用于原始类型（int、char、double），equals() 用于对象（String、List、数组、自定义对象）。注意两个方向的「可发现性」完全不同：在原始类型上调 .equals() 是静态错误（5.equals(5) 无法编译），错误立刻暴露；而在对象上用 == 完全合法，只是答案错——所以真正需要肌肉记忆的是后者。此外还要注意 s1 == i1（String 与 int）是静态错误，因为二者类型不可比较。

【设计原则透视】 这条规则直接对应「Safe from bugs」：== 在 Java 中是重载的（对原始类型比值、对对象比身份），重载带来的歧义正是 bug 的温床。更深的层面，equals() 的正确语义依赖对象类型对 equals/hashCode 的正确实现——这就是 Reading 15（相等性）的主题，而 Map/Set 的键必须可哈希正是本讲已经埋下的伏笔。在 Reading 11（抽象函数）中我们会看到，equals 的语义本质上由抽象函数决定。

场景 2：在迭代过程中修改集合

❌ 错误代码

import java.util.List;
import java.util.ArrayList;

// 错误：一边 for-each 遍历，一边删除元素
public class WordFilterBuggy {
    public static List<String> removeShortWords(List<String> words) {
        for (String w : words) {
            if (w.length() < 3) {
                words.remove(w);        // 破坏迭代器 → ConcurrentModificationException
            }
        }
        return words;
    }
}

【错误代码的问题】

1. 运行期抛出 ConcurrentModificationException（若恰好删到最后一个元素附近，也可能不抛异常而是静默漏删，更难查）。
2. 编译期无任何错误：语法与类型完全正确。
3. 这个 bug 的行为依赖集合的具体实现与元素分布，因此「本地测不出来、线上偶发」。
4. 同样的错误在 Python 中也存在（for num in numbers: numbers.remove(num)），从 Python 迁过来时极容易原样照搬。

✅ 正确代码

import java.util.List;
import java.util.ArrayList;
import java.util.Iterator;

// 正确一：用集合自己的批量操作，由库保证迭代安全
public class WordFilter {
    public static List<String> removeShortWords(List<String> words) {
        words.removeIf(w -> w.length() < 3);
        return words;
    }

    // 正确二：需要更复杂的条件时，显式使用 Iterator 的 remove()
    public static List<String> removeShortWordsWithIterator(List<String> words) {
        Iterator<String> iter = words.iterator();
        while (iter.hasNext()) {
            String w = iter.next();
            if (w.length() < 3) {
                iter.remove();          // 通过迭代器删除，迭代状态保持一致
            }
        }
        return words;
    }
}

【为什么这样更好】 removeIf 把「遍历 + 条件删除」交给集合自己实现，库内部使用的正是 Iterator.remove()，因此迭代状态始终一致。当条件复杂到 removeIf 表达不了时，显式使用 Iterator 是标准做法：iter.next() 与 iter.remove() 配合，保证「读一个、判一个、删一个」的节奏不会被打乱。若删除逻辑很复杂，还有一种更朴素的策略：先把要删的元素收集到另一个列表，遍历结束后再统一删除。

【代码对比解说】 关键区别在于谁掌握迭代状态。for-each 把迭代状态藏起来了（这正是它简洁的原因），同时也把「不允许中途修改」变成了一条隐性契约；一旦违反，库只能通过 modCount 检查在下次 next() 时抛异常来「报警」。显式 Iterator 把状态交回你手上，于是你有了合法修改的入口。这三段代码在功能上等价，在安全性上差别巨大——这正是「用库提供的正确抽象，而不是自己拼装」这一工程直觉的体现。

【设计原则透视】 这组对比体现了本讲「可变 vs. 不可变」的实用推论：共享可变状态是 bug 之源。迭代器与集合之间共享着一个可变的状态（当前位置），外部修改破坏了迭代器依赖的不变量（类似于 Reading 11 中的表示不变量被外部代码破坏）。最彻底的解法是避免可变性——例如让方法返回一个新 List 而不是原地修改（filter 式的函数式风格），这也预告了 Reading 16（map/filter/reduce）的主题。

场景 3：用字符串常量表示有限取值 vs. 用枚举

❌ 错误代码

// 错误：用字符串常量表示有限的颜色集合
public class PenBuggy {
    public static final String RED = "RED";
    public static final String GREEN = "GREEN";

    private String drawingColor = "REd";      // 拼写错误，编译器不报

    public void setDrawingColor(String color) {
        this.drawingColor = color;            // 可以传入 "purple"、""、null……
    }

    public static void main(String[] args) {
        PenBuggy pen = new PenBuggy();
        pen.setDrawingColor("bleu");          // 静态检查完全帮不上忙
        System.out.println(pen.drawingColor);
    }
}

【错误代码的问题】

1. 拼写错误无法被发现："REd" 与 "RED" 都是合法字符串，错误要等到运行期比较失败时才暴露。
2. 类型太宽：任何字符串都能通过 setDrawingColor，包括拼错、空串甚至 null。
3. 语义不可读：setDrawingColor("3") 这样的调用看不出意图，读者需要去查常量表。
4. 「有限集合」这一重要的设计约束完全没有被代码表达出来，也就无法被编译器守护。

✅ 正确代码

// PenColor.java —— 枚举是一个独立的新类型
public enum PenColor {
    BLACK, GRAY, RED, PINK, ORANGE,
    YELLOW, GREEN, CYAN, BLUE, MAGENTA;
}

// Pen.java
public class Pen {
    private PenColor drawingColor = PenColor.RED;

    public void setDrawingColor(PenColor color) {
        this.drawingColor = color;
    }

    public PenColor getDrawingColor() {
        return drawingColor;
    }

    public static void main(String[] args) {
        Pen pen = new Pen();
        pen.setDrawingColor(PenColor.RED);
        // pen.setDrawingColor("bleu");    // 静态错误：String 不能转换为 PenColor
        // pen.setDrawingColor(PenColor.REd); // 静态错误：找不到符号 REd
    }
}

【为什么这样更好】 枚举把「这个类型只有这十种合法取值」这条设计约束编码进了类型系统，于是拼写错误、类型不匹配、传入域外值全部变成编译错误。这正是 Reading 01 中「把假设交给编译器检查」的最佳实践：能静态检查的假设，绝不留到运行期。

【代码对比解说】 三种表示方式的安全性依次递增：int 常量（int month = TUESDAY; 不报错，且数值含义不可读）→ 字符串常量（能读懂，但拼写不受保护、取值域不受限制）→ 枚举（拼写受保护、取值域受保护、语义可读）。选择哪种取决于约束的强度：如果确实会出现「域外值」，就应当重新审视设计，而不是放宽类型。

【设计原则透视】 枚举是「用类型表达约束」的典范，属于三大目标中的两项之和：Safe from bugs（编译期拦截非法取值）与 Easy to understand（PenColor.RED 比 2 或 "red" 可读得多）。它也为 Reading 12（接口、泛型与枚举）打下基础——在那里我们会看到枚举可以有字段与方法。此外，枚举天然是不可变的有限值集合，因此可以作为 Map 的键与 Set 的元素安全使用。

场景 4：放弃泛型——用裸类型装不同类型

❌ 错误代码

import java.util.List;
import java.util.ArrayList;

// 错误：使用裸类型（raw type），等于主动放弃静态检查
public class RawListBuggy {
    public static void main(String[] args) {
        List numbers = new ArrayList();       // 没有类型参数
        numbers.add(5);
        numbers.add("six");                   // 编译通过 —— 灾难
        int first = (Integer) numbers.get(0); // 需要显式强转
        int second = (Integer) numbers.get(1);// 运行期 ClassCastException
    }
}

【错误代码的问题】

1. 编译器不再检查元素类型，"six" 能混进一个「数字列表」，错误被推迟到运行期。
2. 取出元素必须显式强转 (Integer)，每处强转都是一个潜在崩溃点。
3. 强转错误抛出的 ClassCastException 发生在离错误源头很远的地方（写入点在第 7 行，崩溃点在第 10 行），排查成本高。
4. 代码读起来无法判断这个列表装的是什么，读者必须通读所有 add 调用。

✅ 正确代码

import java.util.List;
import java.util.ArrayList;

// 正确：用泛型把元素类型写进类型，交给编译器检查
public class TypedList {
    public static void main(String[] args) {
        List<Integer> numbers = new ArrayList<>();
        numbers.add(5);                       // 自动装箱：int → Integer
        numbers.add(6);
        // numbers.add("six");                // 静态错误：不兼容的类型

        int second = numbers.get(1);          // 自动拆箱：Integer → int，无需强转
        System.out.println(second);           // 6

        // 不允许 List<int>：泛型参数必须是对象类型
        // List<int> bad = new ArrayList<>();  // 静态错误
    }
}

【为什么这样更好】 泛型把「这个容器里装的是什么」写进类型，于是错误在写入的那一行就被编译器拦下，而不是等到读取时崩溃。取出元素时类型已知，不再需要强转，代码既更安全也更简洁。

【代码对比解说】 注意 Java 的自动装箱/拆箱：numbers.add(5) 会自动把 int 包装成 Integer，int second = numbers.get(1) 会自动拆箱，因此泛型带来的语法负担几乎为零。但要注意拆箱的风险：补充说明，如果 List<Integer> 中某个元素是 null，拆箱会抛 NullPointerException。另外要区分「编译期类型」与「运行期类型」：泛型参数在运行期被擦除（type erasure），所以 List<Integer> 与 List<String> 在运行期是同一个类——这正是为什么不能写 new T[]、也为什么不能重载 f(List<Integer>) 与 f(List<String>)（后者是静态错误）。

【设计原则透视】 泛型是本讲所有内容中最纯粹地体现「静态检查」价值的一处：它把一条本来只能靠文档与约定维持的假设（「这个列表里都是整数」）变成了机器可验证的类型声明。它与 Reading 01 的 Array<number>、List<int> 讨论一脉相承，也直接连接到 Reading 12（泛型）与 Reading 10（抽象数据类型）——在那里我们关心的不再是「容器里装什么」，而是「这个数据类型的抽象行为是什么」。

场景 5：final 引用不等于不可变值——泄漏内部表示

❌ 错误代码

import java.util.List;
import java.util.ArrayList;

// 错误：以为 final 就万事大吉，把内部可变列表直接交出去
public class PlaylistBuggy {
    private final List<String> songs = new ArrayList<>();

    public void add(String song) {
        songs.add(song);
    }

    public List<String> getSongs() {
        return songs;                  // 泄漏内部表示：调用者拿到的是同一个可变对象
    }

    public static void main(String[] args) {
        PlaylistBuggy p = new PlaylistBuggy();
        p.add("Yesterday");
        List<String> leaked = p.getSongs();
        leaked.clear();                // 从外部把「封装」好的状态清空了
        System.out.println(p.getSongs().size());   // 0 —— 内部状态被悄悄破坏
    }
}

【错误代码的问题】

1. final 只保证引用不被重新赋值，songs 指向的列表内容仍可被任何人修改。
2. getSongs() 把内部表示直接暴露出去（表示泄漏，representation exposure），封装形同虚设。
3. 外部代码可以在毫无提示的情况下破坏对象的不变量（例如「歌单里至少有一首歌」），这类 bug 极难定位。
4. 若将来把内部表示从 List 换成别的结构，所有依赖「拿到的是可变列表」的客户代码都会失效——违反 Ready for change。

✅ 正确代码

import java.util.List;
import java.util.ArrayList;
import java.util.Collections;

// 正确：引用不可重新赋值 + 不把可变内部表示交出去
public class Playlist {
    private final List<String> songs = new ArrayList<>();

    public void add(String song) {
        songs.add(song);
    }

    /** @return an unmodifiable view of the songs in this playlist */
    public List<String> getSongs() {
        return Collections.unmodifiableList(songs);   // 补充说明：Java 标准库 API
    }

    /** @return a snapshot copy of the songs in this playlist */
    public List<String> snapshot() {
        return List.copyOf(songs);                    // 补充说明：Java 10+ API
    }

    public static void main(String[] args) {
        Playlist p = new Playlist();
        p.add("Yesterday");
        p.getSongs().clear();          // 运行期抛 UnsupportedOperationException
    }
}

【为什么这样更好】 返回 Collections.unmodifiableList(songs) 让调用者拿到的引用不能修改：任何写操作（add、clear、set）都会抛出 UnsupportedOperationException，从而把「不得从外部修改」这条规则变运行期为显式错误，而不是静默破坏。若调用者需要一份可以自由改动的数据，就给他 List.copyOf(songs)（一份独立的快照），这样他怎么改都不会影响原始对象。

【代码对比解说】 两种保护手段的差别值得记牢：Collections.unmodifiableList 返回的是一个视图（view）——它不复制数据，因此开销小，但它会随原列表的变化而变化（p.add(...) 之后视图里也能看到新元素）；List.copyOf 返回的是一个副本，与原列表彻底解耦。选择哪一个取决于语义：想表达「这是当前状态的只读视图」就用视图，想表达「这是此刻的快照」就用副本。不要为了「不可变」而盲目复制大集合，那是无谓的性能损失。

【设计原则透视】 这组对比精准地示范了本讲的核心区分：final 管的是「箭头不动」，不可变性管的是「气泡不变」，而封装管的是「气泡不许别人碰」。真正的安全来自三者配合：private 限制访问，final 固定引用，不可变返回类型切断外部修改路径。这正是 Reading 08（不可变性）的主题，而「内部表示不得泄漏」在 Reading 11（抽象函数与表示不变量）中会作为 RI 的一部分被正式定义：只要内部表示可能被外部代码随意改动，我们就根本无法为它写出任何有意义的 RI。

与其他设计原则的关联

• 与 Reading 01（静态检查 / Static Checking）：本讲是 Reading 01 的语法落地。final 对应 const，List<Integer> 对应 Array<number>，泛型把 Reading 01 中「静态检查面向类型」的结论变成日常写法；int[100] 的缓冲区溢出教训则直接解释了为什么要用 List。
• 与 Reading 03（测试 / Testing）：本讲场景 1 的 == 陷阱与场景 2 的迭代修改陷阱，都是「单元测试必须覆盖的划分」。互不相等的字符串（字面量 vs. new String）正是「字符串相等性」这一输入子域的边界情形。
• 与 Reading 06（规格说明 / Specifications） 和 Reading 07（设计规格说明 / Designing Specifications）：Collections.unmodifiableList 的注释其实就是一条后置条件；「前置条件该不该检查」「返回类型该不该用接口」都是规格设计问题。
• 与 Reading 08（不可变性 / Immutability）：本讲场景 5 提出的「表示泄漏」在那里得到系统解决；不可变类型如何带来安全性与线程安全性，是 Reading 08 的核心。
• 与 Reading 10（抽象数据类型 / Abstract Data Types）：本讲的 List/Set/Map 就是 Java 库中的 ADT；Reading 10 会解释「为什么用接口声明、用实现类构造」这一习惯背后的抽象思想。
• 与 Reading 11（抽象函数与表示不变量 / Abstraction Functions & Rep Invariants）：本讲的快照图是 RI/AF 的图示语言；private final 字段与「不泄漏表示」是维持 RI 的必要条件。
• 与 Reading 12（接口、泛型与枚举 / Interfaces, Generics, Enums）：本讲只介绍了这三者的基本用法，Reading 12 会把它们整合成完整的抽象与参数化设计工具。
• 与 Reading 15（相等性 / Equality）：本讲 .equals() 的正确语义、Map 键必须可哈希，都在 Reading 15 中展开为 equals/hashCode 契约。
• 与 Reading 21–23（并发 / Concurrency、线程安全 / Thread Safety、锁 / Locks）：本讲「共享可变状态是 bug 之源」的直觉，在并发中成为硬约束——不可变对象天生线程安全，可变对象必须加锁。

关键要点

• 对象比内容用 equals()，原始类型比值用 ==；== 用在对象上不会报错，只会安静地给出错误答案，因此必须靠习惯而不是靠编译器来防。
• 区分四个正交概念：引用是否可重新赋值（final）、值是否可变（String vs StringBuilder）、变量作用域（花括号）、参数传递（按值传递引用）。
• 声明用接口，构造用实现：List<String> x = new ArrayList<>();，让实现可替换。
• 把类型信息完整写出来：用 List<String> 而非裸 List，用 enum 而非字符串常量，让编译器替你守护尽可能多的假设。
• 不要泄漏可变内部表示：返回只读视图或快照副本；final 不解决封装问题。

常见陷阱与注意事项

1. == 与 .equals() 混用：字符串字面量的驻留让你「测出来是对的」。→ 后果：一旦换成从文件、网络或 substring 得到的字符串，逻辑立刻走错分支。
2. 以为 final 就等于不可变：final List<String> l = new ArrayList<>(); l.add("x"); 是合法的。→ 后果：误以为对象受到保护，实际内部状态仍可被任意修改。
3. 在 for-each 中增删元素：ConcurrentModificationException，或者更糟——静默漏删。→ 后果：行为随集合实现与数据分布而变，难以复现。
4. 忘记原始类型集合的限制：写 List<int> 或 Set<int> 会编译失败；用 List<Integer> 时若元素为 null，拆箱抛 NullPointerException。→ 后果：编译期报错（尚可接受）或运行期空指针（危险）。
5. 混淆 TypeScript 的 let 与 Java 的 var：sp22 中的 let 对应 Java 的「声明 + 可重新赋值」，而 Java 10+ 的 var 只是类型推断，是静态类型。→ 后果：把 var 当成动态类型使用，写出难以理解的代码。
6. 把 API 文档当摆设：不查 assertEquals 的参数顺序、不查 Map.put 返回的是旧值还是新值、不查 replace 返回 boolean 还是旧值。→ 后果：写出语义相反的测试或逻辑，且自己看不出来（详见 Reading 03 与 Reading 06）。

思考题（带答案）

问题 1：运行下面的代码，s 最终指向的内容是什么？sb 最终指向的内容是什么？请分别说明是「重新赋值」还是「改变值」。

public class Params {
    static void f(String s, StringBuilder sb) {
        s.concat("b");
        s += "c";
        sb.append("d");
    }

    public static void main(String[] args) {
        String t = "a";
        StringBuilder tb = new StringBuilder("a");
        f(t, tb);
        System.out.println(t + " / " + tb);
    }
}

答案：输出 a / ad。t 仍是 "a"：方法内 s.concat("b") 返回新字符串但返回值被丢弃（String 不可变，没有任何东西被改变）；s += "c" 让局部变量 s 重新指向新对象 "ac"，这属于「重新赋值」，只影响方法内的那个箭头，方法返回后 t 的箭头毫无变化。tb 变成 "ad"：sb.append("d") 是「改变值」——局部变量 sb 与调用者的 tb 指向同一个对象，因此对该对象内部状态的修改对外可见。这组对比说明：Java 的参数传递总是按值传递引用；能影响调用者的只有「对共享对象的修改」，而绝不是「对参数重新赋值」。

问题 2：下面三个声明中，哪些在编译期就会失败？为什么？

List<int> a = new ArrayList<>();
List<Integer> b = new ArrayList<>();
Integer c = 5;

答案：只有第一个失败。List<int> 是静态错误，因为泛型类型参数必须是对象类型（引用类型），不能是原始类型；必须写作 List<Integer>。第二个合法（菱形语法推断出 ArrayList<Integer>）。第三个也合法：Java 会自动装箱，把 int 字面量 5 包装成 Integer 对象。补充说明：Integer c = null; int d = c; 会在运行期抛 NullPointerException——自动拆箱不检查 null，这是包装类型相对于原始类型多出的风险点。

问题 3：一位同学写了 private final List<String> names = new ArrayList<>();，并认为「加了 final，所以 names 是不可变的，外部无法修改」。请指出这句话的两处错误，并给出修正方案。

答案：第一处错误：final 约束的是引用，不是值。names 这个箭头不能再指向别的列表，但 names.add(...)、names.clear() 完全合法，列表内容随时可变。第二处错误：即使字段是 private，只要把内部列表本身作为返回值交出去（return names;），外部代码就能通过这个引用修改它——封装被绕过，表示被泄漏。修正方案分两点：（1）对外返回只读视图 Collections.unmodifiableList(names) 或快照副本 List.copyOf(names)；（2）如果语义上确实要求「集合内容也不可变」，就改用 List.of(...) 构造，或把所有修改方法收拢到类自己的接口内。补充说明：Collections.unmodifiableList 返回的是视图，原列表变化时视图也会变化；List.copyOf 返回的是独立副本。选视图还是副本，取决于你想表达「只读视图」还是「当下快照」。

Reading 3: 测试（Testing）

说明：本讲 sp22 原版使用 TypeScript 与 Mocha，本笔记按用户要求提供 Java 代码示例与 JUnit 写法；方法与 API 与 sp21（6.031 Java 版）原文保持一致。

概述

本讲回答一个问题：怎样选择测试用例，才能用最少的测试抓到最多的 bug？ 答案是系统性测试（systematic testing）：先对规格说明做输入空间划分（partitioning），取每个子域中的边界值（boundary values），再把测试写成自动化（automated） 的单元测试，用代码覆盖率（code coverage） 检查遗漏，用回归测试（regression testing） 锁住已修复的 bug。本讲的全部内容都服务于三大目标：测试直接对应 Safe from bugs；把测试策略写下来对应 Easy to understand；而「测试只依赖规格说明、不依赖实现」正是 Ready for change 的保证——因为实现可以在规格允许的范围内自由变化。

核心概念与设计原则详解

验证（Validation）的三种手段

• 定义与目的：验证是「发现程序中的问题、从而提高对正确性的信心」这一更一般的过程。测试只是其中一种。它服务的质量目标是 Safe from bugs。
• 直观解释（”它是什么？”）：验证就像确认一份文稿没问题：你可以形式化证明它正确（verification，构造正确性的形式化证明）、请别人仔细通读（code review，非形式化推理）、或者实际跑一遍看结果（testing）。
• 关键规则与最佳实践：
  • 形式化验证（verification） 手工做很繁琐，自动化工具支持仍是活跃研究领域；只有少数关键部件会被形式化验证（操作系统的调度器、虚拟机的字节码解释器、操作系统的文件系统）。
  • 代码审查（code review） 让另一个人仔细读代码并做非形式化推理，成本低、收益高（详见 Reading 04）。
  • 测试（testing） 在精心选择的输入上运行程序并检查结果。
  • 即使做了最好的验证，软件仍然很难达到完美质量。典型残余缺陷率（residual defect rate）：工业软件 1–10 缺陷/千行，高质量验证 0.1–1 缺陷/千行（成熟的浏览器 JS 库可达此水平），最顶级的安全关键系统 0.01–0.1 缺陷/千行（NASA 与 Praxis 这类公司可达）。
  • 这个数字对大系统很打击人：100 万行工业代码按 1 缺陷/千行算，等于漏掉了 1000 个 bug。

为什么软件测试很难（Why Software Testing Is Hard）

• 定义与目的：理解三条「行不通的路」，才能理解为什么必须系统化地选测试用例。
• 直观解释（”它是什么？”）：软件不像硬件——硬件可以抽样（测 1% 硬盘推断整批），可以用「加速老化」推断寿命（24 小时开关冰箱 1000 次）；软件的失败点分布不连续、不离散，抽样统计完全失效。
• 关键规则与最佳实践：
  • 穷举测试（exhaustive testing）不可行：测试空间通常太大。穷举测试一个 32 位浮点乘法 a*b 需要 2⁶⁴ 个用例。
  • 随意测试（haphazard testing）（「随便跑一下看看行不行」）找到 bug 的概率低，也不增加我们对正确性的信心——它没有告诉我们任何关于未测部分的信息。
  • 随机/统计测试（random or statistical testing）不适用于软件：物理系统的缺陷在空间上连续或均匀分布，所以抽样有意义；而软件行为在输入空间上是不连续、离散的。「系统在很大范围内的输入上都工作正常，然后在某一个边界点上突然失败」是常态。著名的 Pentium 除法 bug 大约每 90 亿次除法才出现一次；栈溢出、内存耗尽、数值溢出都是突然发生且每次都以同样方式发生，没有概率性变化。
  • 因此：测试用例必须被仔细地、系统地选择——这正是本讲的主线。

测试优先编程（Test-First Programming）

• 定义与目的：先写规格说明与测试，再写实现。它把「发现 bug」提前到「刚引入 bug 的那一刻」，是本讲最重要的工程实践。
• 直观解释（”它是什么？”）：先想清楚「这个函数该做什么、怎么算做对了」，再动手写实现。就像建筑先出图纸再施工。
• 关键规则与最佳实践：
  • 模块（module）：软件中可以独立设计、实现、测试、推理的一部分。本讲聚焦以方法（函数）为单位的模块，后续 Reading 会扩展到类。
  • 规格说明（specification / spec）：描述模块的行为——参数类型与附加约束（例如 sqrt 的参数必须非负）、返回类型以及返回值与输入的关系。在 Java 中，规格说明由方法签名 + 上方注释组成。
  • 实现（implementation） 提供行为，客户（client） 使用模块；规格说明同时约束这两方。
  • 测试用例（test case）：一组具体输入 + 规格说明要求的预期输出行为。测试套件（test suite）：一组测试用例。
  • 开发顺序：Spec（写规格说明）→ Test（写测试）→ Implement（写实现）。实现通过了测试，就完成了。
  • 最大收益是 Safe from bugs：不要把所有测试留到最后，那时你有一大堆未经检验的代码，bug 可能在任何地方。

系统性测试的三个性质：正确、彻底、小（Correct, Thorough, Small）

• 定义与目的：系统性测试意味着「有原则地」选择用例，目标是设计出同时满足三个性质的测试套件。
• 直观解释（”它是什么？”）：像选代表团的成员——每个族群（子域）都要有代表（彻底），但代表总数要少（小），而且不能把不该来的人算进来（正确）。
• 关键规则与最佳实践：
  • 正确（Correct）：测试套件是规格说明的合法客户，接受该规格的所有合法实现而不抱怨。这让你可以自由改动内部实现而无需改测试。
  • 彻底（Thorough）：能找出实现中真实存在的、程序员很可能犯的错误。
  • 小（Small）：用例少 → 写起来快、规格变化时好改、运行快 → 你会跑得更频繁。
  • 对照三性质：穷举测试彻底但大得不可行；随意测试小但不彻底；随机测试要达到彻底必须付出巨大规模的代价。
  • 心态转变：写代码时你的目标是「让它工作」；设计测试套件时你的目标是「让它失败」。好的测试者会故意去戳程序最脆弱的地方。测试优先编程有助于获得这种「残酷的视角」，因为你在还没写出代码、不会把代码当作脆弱蛋壳的时候就已经戴上了测试的帽子。

输入空间划分（Partitioning the Input Space）

• 定义与目的：把输入空间拆成若干子域（subdomain），使每个子域内部的输入行为相似，然后从每个子域取一个代表作为测试用例。这是「用少量用例覆盖大量行为」的核心技术。
• 直观解释（”它是什么？”）：不去检查沙滩上的每一粒沙，而是按「沙粒大小」分成几类，每类抓一把看看。子域的名称来自数学：它是函数定义域（domain）的子集。
• 关键规则与最佳实践：
  • 划分（partition） 必须满足两点：子域两两不相交（disjoint），且完全覆盖（complete） 输入空间——每个输入恰好落在一个子域中。
  • 紧凑写法就是列出一串谓词：// partition: a >= 0; a < 0。
  • 划分必须「正确」：每个子域都要能被合法的测试用例覆盖。例如对规格要求 x 非负的 sqrt，划分成 x < 0; x >= 0 虽不相交且完整，但 x < 0 子域无法用合法输入覆盖，因此不是一个好划分。
  • 划分应当围绕规格说明中行为发生变化的地方：Math.max(a, b) 的规格对不同子域有不同要求，所以取 a < b; a > b; a = b（注意必须有 a = b，否则不完整）。
  • 有时按输出表达划分更方便：// partition on a.multiply(b): 0, positive, negative 是 {(a,b) | a*b = 0}、> 0、< 0 三个子域的简写。
  • 对于多参数函数，把每个参数的关注点写成多个独立划分，让一个测试用例同时覆盖来自不同划分的多个子域，可以避免笛卡尔积爆炸（6×6 = 36 个用例降到 6 个）。但要注意：独立划分会漏掉参数间的交互，所以要额外补一个捕捉交互的划分（如「a 与 b 同号 / 异号 / 有一个为 0」）。

边界值（Boundary Values）

• 定义与目的：bug 常常出现在子域之间的边界上，因此边界值必须被写成单元素子域，从而保证测试套件必然包含它们。
• 直观解释（”它是什么？”）：边界是行为「换挡」的地方，换挡处最容易出错。
• 关键规则与最佳实践：
  • 常见边界：0（正负数之间）、数值类型的最大/最小值（Integer.MAX_VALUE、Integer.MIN_VALUE、Long.MAX_VALUE）、集合类型的空值（空字符串、空列表、空集合）、序列的第一个与最后一个元素。
  • 为什么边界容易出 bug：程序员常犯 off-by-one（写 <= 而不是 <、计数器初值写 0 而不是 1）；某些边界需要被当作特例处理；边界是行为的不连续点。
  • 加入边界后，原来的子域要收缩以排除边界。以 Math.abs 为例，完整划分是：a = Integer.MIN_VALUE；Integer.MIN_VALUE < a < 0；a = 0；0 < a < Integer.MAX_VALUE；a = Integer.MAX_VALUE，五个子域不相交且完整覆盖。
  • Java 的 Math.abs 在 Integer.MIN_VALUE 上有一个反直觉行为：规格说明明确写「若参数等于 Integer.MIN_VALUE，结果是同一个（负）值」。原因是 -2³¹ 的相反数 2³¹ 超出了 int 的范围。这类「规格里写明的怪行为」正是最该测的边界。
  • 对「字符串长度至多 5 且只含 ‘W’/’L’」的 winLossRatio，合适的边界包括 ""（空串）、"WWWWW"（全胜）、"LLLLL"（全负）。

自动化单元测试与 JUnit（Automated Unit Testing）

• 定义与目的：单元测试（unit test） 测试单个模块，尽可能隔离。自动化让测试真正被执行——没人愿意手动跑一百次。
• 直观解释（”它是什么？”）：把测试写成一个可执行的方法，断言（assert）期望结果；运行测试类，得到「全部通过」或「这些用例失败了：……」。
• 关键规则与最佳实践：
  • Java 使用 JUnit：测试方法用 @Test 注解标注，方法体内调用被测量模块，然后用 assertEquals、assertTrue、assertFalse 等断言方法检查结果。
  • 参数顺序至关重要：assertEquals 的第一个参数是期望值（expected），通常是个常量；第二个参数是实际值（actual），即代码真正算出来的东西。所有比较值的 JUnit 断言都遵循「expected 在前，actual 在后」。写反了会导致失败信息令人困惑。
  • TypeScript 对照（sp22 原版写法）：Mocha 的 assert.strictEqual 顺序正好相反——第一个参数是 actual，第二个是 expected。这是从 TypeScript 切到 Java 时最容易搞错的一点。
  • 断言可以带可选的消息字符串作为最后一个参数，让失败信息更有用；一个测试方法里的断言失败后该方法立即返回，但其他 @Test 方法仍会运行。
  • 对返回结构（集合、数组）的比较，需要注意 assertEquals 只对内置类型可靠；补充说明：JUnit 5 的 assertIterableEquals 可以比较可迭代对象的内容，而手写断言应当检查结构的关键性质（如「集合大小为 1 且包含 hello」）而不是逐元素比对。

记录测试策略（Documenting Your Testing Strategy）

• 定义与目的：把用到的划分、子域，以及每个测试用例覆盖了哪些子域写下来。这让测试套件的彻底性对读者可见，直接服务于 Easy to understand。
• 直观解释（”它是什么？”）：测试类顶部的注释就是这份测试套件的「说明书」，读它的人不必逐个反推用例意图。
• 关键规则与最佳实践：
  • 在测试类顶部的注释里写下划分与子域：

public class MaxTest {
    /*
     * Testing strategy
     *
     * partition:
     * a < b
     * a > b
     * a = b
     */
}

• 每个测试方法上方写注释，说明它覆盖哪些子域：// covers a < b。
• 大多数测试套件会有多个划分，大多数测试用例会覆盖多个子域，例如 // covers a = 1, b != 1, a and b have same sign。
• 策略注释写在测试类里，规格说明（@return ...）写在被测类里，两者不要混。

黑盒测试与白盒测试（Black Box and Glass Box Testing）

• 定义与目的：黑盒测试只依据规格说明选择用例，不看实现；白盒测试（glass box testing） 借助对实现的了解来选择用例。前者保证测试正确性（不依赖实现细节），后者提高彻底性（覆盖实现特有的分支）。
• 直观解释（”它是什么？”）：黑盒测试是「只看说明书办事」；白盒测试是「知道内部构造后专门去戳容易坏的地方」。
• 关键规则与最佳实践：
  • 黑盒测试是测试优先编程的默认方式——你还没写实现，自然只能看规格。本讲的 abs、max、BigInteger.multiply 例子全是黑盒测试。
  • 白盒测试的常见触发点：实现会按输入选择不同算法（例如 sort 根据 values.size() 在 radixSort / quickSort / mergeSort 之间切换，于是 0、9、10、1e9 这些阈值附近成为新边界）；实现有内部缓存（于是要测试重复输入）；内部表示有结构（例如 BigInteger 用十进制数字数组表示，则「一位数相乘」与「多位数相乘」是不同子域）。
  • 白盒测试的纪律：绝不能要求规格说明没有承诺的实现行为。若规格说明写「输入格式错误时抛出异常」，测试就不应该具体断言 NullPointerException，因为规格允许任何异常——否则你就限制了实现者的自由，测试也不再「正确」。

代码覆盖率（Coverage）

• 定义与目的：覆盖率用来判断测试套件执行程序的充分程度，是白盒测试的量化工具。它服务于 Safe from bugs（找出没测到的代码）与 Easy to understand（让测试缺口可视化）。
• 直观解释（”它是什么？”）：覆盖率工具把每一行标成绿色（执行过）、红色（没执行过）、黄色（分支只走了一个方向）。
• 关键规则与最佳实践：
  • 语句覆盖（statement coverage）：每个语句都被某个用例执行过吗？
  • 分支覆盖（branch coverage）：每个 if/while 的真假两个方向都被走过吗？
  • 路径覆盖（path coverage）：每条可能的路径（所有分支组合）都被走过吗？
  • 强度关系：分支覆盖强于语句覆盖，路径覆盖强于分支覆盖。工业界常见目标是 100% 语句覆盖，但由于「不该到这里」这类不可达的防御性代码，实际上很少达到；100% 分支覆盖非常可取；安全关键行业有更严苛的标准（如 MC/DC，修正条件/判定覆盖）；100% 路径覆盖不可行，需要指数规模的测试套件。
  • 标准做法是：先写黑盒测试，再测量覆盖率，然后针对红色与黄色的代码补测试用例。Java 生态常用工具是 Eclipse 的 EclEmma（Run → Coverage As），TypeScript 生态是 Istanbul/nyc。
  • 以 Hailstone 为例：初始 n = 3 时序列为 3, 10, 5, 16, 8, 4, 2, 1，n = n / 2 这行会被执行（绿色）；初始 n = 16 时序列是 16, 8, 4, 2, 1，全是偶数，n = 3 * n + 1 这行永远不会执行（红色）；初始 n = 1 时循环体一次都不执行，整个循环体都是红色，而 while (n != 1) 这一行是黄色（条件永远为真、从未取过假方向）。

单元测试与集成测试（Unit and Integration Testing）

• 定义与目的：单元测试隔离地测单个模块；集成测试（integration test） 测多个模块的组合甚至整个程序。二者互补：前者定位快，后者能发现模块之间的连接问题。
• 直观解释（”它是什么？”）：单元测试是「单独尝一尝每道工序的成品」；集成测试是「把整道菜端上桌尝一尝」。做披萨时，单独烤一张饼皮看它够不够脆 —— 单元测试；尝一口用现成香料做的酱 —— 单元测试；把酱和配料铺在饼皮上一起烤，看饼皮在潮湿配料下还能不能烤好 —— 集成测试。
• 关键规则与最佳实践：
  • 隔离测试让调试容易得多：单元测试失败时，你可以更有信心 bug 就在这个模块里。
  • 只有集成测试时，测试一旦失败，bug 可能在任何地方，必须到处排查。
  • 典型错误：测试 extract() 时先用 load() 把文件读进来，再把结果传给 extract()。这不是 extract 的单元测试——失败时你无法判断是 load 还是 extract 有 bug。
  • 正确做法：把文件内容写成字面量字符串直接传给 extract()。使用「贴近真实文件内容」的划分是合理的（因为这才是 extract 的实际用法），但不要真的调用 load。
  • 对 index() 这类高层模块，隔离很难：调用 index 就同时测试了它内部调用的所有函数。这就是为什么必须先有 load 和 extract 的独立单元测试——它们让你能心安理得地把 bug 定位在 index 的连接逻辑里。
  • 真要隔离高层模块，可以为它调用的模块写桩（stub）：例如 load 的桩完全不访问文件系统，无论传入什么 File 都返回固定的模拟内容。类的桩常被称为 mock object。桩是构建大型系统的重要技术，但 6.031 一般不用它。

自动化回归测试（Automated Regression Testing）

• 定义与目的：自动化测试指自动运行测试并检查结果；回归测试指每次改动代码后重跑全部测试。二者结合是现代软件工程的最佳实践。
• 直观解释（”它是什么？”）：自动化测试是「一键跑完所有检查」；回归测试是「每次动完代码就按一下那个按钮」，防止「修好一个 bug、引入两个新 bug」。
• 关键规则与最佳实践：
  • 测试驱动（test driver / test harness / test runner） 不应是交互式程序（不能提示你输入、打印结果让你肉眼判断），而应当在固定的测试用例上调用模块并自动检查结果，输出「all tests OK」或「these tests failed: …」。JUnit 让你构建这样的驱动器。
  • 自动化框架让「运行」变容易，但测试用例仍要你自己想——自动生成测试用例仍是活跃的研究课题。
  • 每当你发现并修复一个 bug，就把引发它的输入加入测试套件，这叫作回归测试用例（regression test）。一个好测试的标准就是「它能引出一个 bug」——而每个回归测试都确实曾在某个版本上引出过 bug。
  • 回归测试还能防止回退（reversion）：这个 bug 既然犯过一次，就很可能再犯。
  • 这引出了测试优先调试（test-first debugging）：bug 一出现，立刻写一个能引出它的测试用例并加入套件；修好之后，所有测试通过，调试结束，同时你永久得到了一个回归测试。
  • 值得重跑全部测试的时机：git add/commit/push 之前、为了提高性能重写函数之后、使用覆盖率工具时、以及你认为自己修好了一个 bug 之后。

迭代式测试优先编程（Iterative Test-First Programming）

• 定义与目的：有效的软件工程不是线性流程。要在每一步都准备好回头修改前面的成果。
• 直观解释（”它是什么？”）：规格说明、测试、实现三者互相校验，像三角架一样彼此支撑；任何一条腿发现问题，都要回去调整另外两条。
• 关键规则与最佳实践：
  • 三步：写规格 → 写测试（发现问题就回头改规格与测试）→ 写实现（发现问题就回头改规格、测试与实现）。
  • 写测试是理解规格的好方法：规格可能不正确、不完整、有歧义、漏掉边界情况；写测试能在你为错误规格浪费时间写实现之前发现这些问题。
  • 反过来，写实现也可能让你发现测试缺失或错误，或促使你回过头修改规格。
  • 因此不要在某一步追求完美再前进：大规格先写其中一部分，测它、实现它，再扩展；复杂测试套件先选几个重要划分做小套件，实现一个简单版本通过它，再逐步增加划分；棘手实现先写一个简单粗暴的版本（如用线性查找代替二分查找）来验证规格与测试，然后再写难的那个。
  • 迭代需要不同于「一次做对」的心态：尽快得到一个粗略可用的解，然后持续精化，以便必要时推翻重做。这在问题困难、解空间未知时最省时间。

代码示例与对比分析

场景 1：交互式手动检查 vs. 自动化 JUnit 测试

❌ 错误代码

import java.util.List;
import java.util.ArrayList;

// 错误：靠打印结果、用肉眼判断的「测试」
public class HailstoneMain {
    public static List<Integer> hailstoneSequence(int n) {
        List<Integer> list = new ArrayList<>();
        while (n != 1) {
            list.add(n);
            if (n % 2 == 0) {
                n = n / 2;
            } else {
                n = 3 * n + 1;
            }
        }
        list.add(n);
        return list;
    }

    public static void main(String[] args) {
        System.out.println(hailstoneSequence(3));    // 人工看一眼：好像是对的
    }
}

【错误代码的问题】

1. 结果需要人眼判断：没有断言，没有「通过/失败」，无法在 CI 中自动运行。
2. 不可重复、不可回归：改代码后必须有人记得再跑一次并再看一眼，而人会忘记。
3. 一旦输出变长（如 n=27 的 112 项），肉眼比对事实上不可行，人会「看上去差不多就放过」。
4. 无法表达「预期输出行为」：规格说明中「以 n 开始、以 1 结束」这类约束完全没有被检查，只检查了这一组输入恰好产生了这一串数字。

✅ 正确代码

import java.util.List;
import java.util.ArrayList;
import java.util.Arrays;
import org.junit.Test;
import static org.junit.Assert.assertEquals;

public class HailstoneTest {
    /*
     * Testing strategy
     *
     * partition on n:
     *   n = 1
     *   n = 2
     *   n is an odd number > 1 (so the 3n+1 rule is used at least once)
     *   n is an even number > 2
     *   n is a power of 2 (the sequence decreases monotonically)
     */

    @Test
    public void testStartsAtOne() {
        // covers n = 1
        assertEquals(Arrays.asList(1), Hailstone.hailstoneSequence(1));
    }

    @Test
    public void testStartsAtTwo() {
        // covers n = 2
        assertEquals(Arrays.asList(2, 1), Hailstone.hailstoneSequence(2));
    }

    @Test
    public void testOddStart() {
        // covers n is an odd number > 1
        assertEquals(Arrays.asList(3, 10, 5, 16, 8, 4, 2, 1),
                     Hailstone.hailstoneSequence(3));
    }

    @Test
    public void testPowerOfTwo() {
        // covers n is a power of 2
        assertEquals(Arrays.asList(16, 8, 4, 2, 1),
                     Hailstone.hailstoneSequence(16));
    }
}

【为什么这样更好】 每个测试方法都把自己的预期写成可执行的断言，运行结果是二值的（通过/失败），可以一键重复执行、可以进入持续集成、可以在每次改动后作为回归测试。测试类顶部的策略注释让读者立刻看到划分与覆盖范围，无需反推每个用例的意图。而且一旦实现被改坏，失败信息会精确告诉你哪一条划分出了问题。

【代码对比解说】 main 加 println 的模式并非毫无价值——它适合探索性的临时试验。但它不是测试：它没有预期值，因此无法自动判断对错。这里的关键跃迁是把「我知道正确答案是什么」这一人类知识，固化成机器可检查的断言。注意 assertEquals(expected, actual) 的参数顺序：Arrays.asList(2, 1) 是期望值，Hailstone.hailstoneSequence(2) 是实际值，写反会让失败消息变成误导人的形式。

【设计原则透视】 测试驱动是自动化的具体形态，对应「Nothing makes tests easier to run, and more likely to be run, than complete automation」。从设计上看，这段测试同时展示了「正确」（只断言规格说明承诺的行为：以 n 开始、以 1 结束、中间项符合递推）与「彻底」（覆盖了偶数、奇数、幂次、n = 1 的边界）。至于 assertEquals 对 List 的比较：补充说明，JUnit 的 assertEquals 对 List 依赖 AbstractList.equals 的逐元素比较，因此上面的写法可用；对数组则必须改用 assertArrayEquals，因为数组的 equals 就是引用相等——这正是 Reading 15（相等性）要讲的内容。

场景 2：assertEquals 参数顺序写反

❌ 错误代码

import org.junit.Test;
import static org.junit.Assert.assertEquals;

// 错误：把实际值写在第一个参数，把期望值写在第二个
public class AbsTestBuggy {

    @Test
    public void testNegative() {
        int result = Math.abs(-3);
        assertEquals(result, 3);          // actual 在前，expected 在后
    }

    @Test
    public void testNegativeIntMin() {
        int result = Math.abs(Integer.MIN_VALUE);
        assertEquals(result, Integer.MIN_VALUE);   // 边界：abs 可以返回负数！
    }
}

【错误代码的问题】

1. JUnit 的失败信息格式是「expected: but was: 」，参数写反后 X 与 Y 互换，**失败信息会误导**你去找相反的方向。
2. 对于「期望值和实际值恰好类型相同但语义相反」的场景（如 assertEquals(result, 3) 中 result 与 3 都是 int），编译器完全无法提醒，错误只能靠纪律避免。
3. 违反「所有比较值的 JUnit 断言都遵循 expected 在前」这一统一约定，让测试代码难以被快速扫读。
4. 第二个用例把 Integer.MIN_VALUE 当成期望值写在后面，掩盖了它其实是边界测试这一重要意图。

✅ 正确代码

import org.junit.Test;
import static org.junit.Assert.assertEquals;

public class AbsTest {

    @Test
    public void testPositive() {
        // covers 0 < a < Integer.MAX_VALUE
        assertEquals(17, Math.abs(17));
    }

    @Test
    public void testNegative() {
        // covers Integer.MIN_VALUE < a < 0
        assertEquals(3, Math.abs(-3));
    }

    @Test
    public void testZero() {
        // covers a = 0
        assertEquals(0, Math.abs(0));
    }

    @Test
    public void testIntMinValue() {
        // covers a = Integer.MIN_VALUE
        // the spec permits a negative result at this boundary
        assertEquals(Integer.MIN_VALUE, Math.abs(Integer.MIN_VALUE));
    }

    @Test
    public void testIntMaxValue() {
        // covers a = Integer.MAX_VALUE
        assertEquals(Integer.MAX_VALUE, Math.abs(Integer.MAX_VALUE));
    }
}

【为什么这样更好】 期望值在前、实际值在后，是 JUnit 所有比较断言的统一约定；失败信息因此永远读作「我期待 X，但实际得到 Y」，方向正确、可读性强。此外，这组测试把 Math.abs 的五子域划分完整地写了出来（Integer.MIN_VALUE、负区间、0、正区间、Integer.MAX_VALUE），每个方法上方注明它覆盖哪个子域，彻底性一目了然。

【代码对比解说】 参数顺序问题看似琐碎，实则是「可诊断性」问题：测试失败时你需要的信息不是「程序算错了」，而是「算成了什么、应该是什么」。当测试套件有几百个用例时，一个方向被反转的失败消息可能让你浪费半小时。另外注意 testIntMinValue 这个用例：Math.abs(Integer.MIN_VALUE) 返回一个负数，这是 Java 规格说明明确写出的行为（两补码表示导致 -2³¹ 的相反数超出 int 范围），一个凭直觉写出的「abs 永远非负」的测试会在这里失败——而这正是边界值测试的价值：它把「直觉」和「规格」的差异逼出来。

【设计原则透视】 这组对比与 Reading 01 的分界线呼应：assertEquals 的参数顺序属于「类型系统无法检查的约定」，只能靠纪律与代码审查（Reading 04）守护。同时，五个子域构成的划分展示了「正确」与「彻底」的平衡——它既没有写成穷举（不可能穷举 2³² 个 int），也不是随意挑几个值，而是围绕规格说明中行为发生变化的地方取样，并显式包含了两个极端边界。

（sp22 原版 TypeScript 写法对照：Mocha 的断言顺序正好相反）

// sp22 原版 TypeScript 写法（Mocha）
import assert from 'assert';

describe("Math.abs", function() {
  /*
   * Testing strategy
   * partition: a < 0; a = 0; a > 0
   */

  it("covers a < 0", function() {
    const result: number = Math.abs(-3);
    assert.strictEqual(result, 3);      // 注意：第一个参数是 actual，第二个才是 expected
  });

  it("covers a = 0", function() {
    assert.strictEqual(Math.abs(0), 0);
  });
});

把这两种框架并排看：JUnit 是 assertEquals(expected, actual)，Mocha 是 assert.strictEqual(actual, expected)——参数顺序完全相反。这是本讲跨语言时最容易出错的一个细节。另外注意 TypeScript 中的 number 无法表示 Integer.MIN_VALUE 那种边界（它是 64 位浮点），所以在 sp22 中 Math.abs 的边界讨论以 Number.MAX_SAFE_INTEGER 等常量呈现，而 Java 中则有 Integer.MIN_VALUE 这个「abs 会返回负数」的著名特例。

场景 3：断言信息不足——随机结果如何正确断言

❌ 错误代码

import java.util.Set;
import org.junit.Test;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

// 错误：对「有多个正确答案」的函数写出过强或过弱的断言
public class PickRandomlyTestBuggy {

    @Test
    public void testDrawFromSet() {
        Set<Integer> set = Set.of(293, 384, 10, 5, -3, 99);
        int result = pickRandomly(set);
        assertEquals(-3, result);        // 断言了一个实现未承诺的具体结果
    }

    @Test
    public void testDrawFromSetNoMessage() {
        Set<Integer> set = Set.of(293, 384, 10, 5, -3, 99);
        int result = pickRandomly(set);
        assertTrue(set.contains(result)); // 正确但失败时毫无线索
    }
}

【错误代码的问题】

1. assertEquals(-3, result) 断言了规格说明没有承诺的行为：pickRandomly 只承诺「返回集合中的某个元素」，任何合法实现都可能在这次调用中返回 293。这让测试不正确——它会拒绝合法实现。
2. 更糟的是，这种测试有时会「碰巧通过」（当实现恰好返回 -3 时），于是它既不可靠又给人虚假的安全感。
3. assertTrue(set.contains(result)) 本身是正确的断言，但失败时只告诉你「断言失败」，不告诉你实际收到了什么值、期望来自哪个集合——调试时毫无线索。
4. 缺少对「返回值来自给定集合」这一关键性质的清晰表达，读者需要自己去推断测试意图。

✅ 正确代码

import java.util.Set;
import org.junit.Test;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

public class PickRandomlyTest {

    /*
     * Testing strategy
     *
     * partition on set:
     *   the set has exactly one element (only one legal answer)
     *   the set has more than one element (multiple legal answers)
     */

    @Test
    public void testSingleElementSet() {
        // covers the set has exactly one element
        Set<Integer> set = Set.of(42);
        assertEquals(42, pickRandomly(set));    // 唯一合法答案，可以精确断言
    }

    @Test
    public void testDrawFromSet() {
        // covers the set has more than one element
        Set<Integer> set = Set.of(293, 384, 10, 5, -3, 99);
        int result = pickRandomly(set);
        assertTrue("expected result to be from " + set + " but actually was " + result,
                   set.contains(result));
    }
}

【为什么这样更好】 对「有唯一合法答案」的子域用精确断言，对「有多个合法答案」的子域用性质断言（assertion on a property），并在消息里同时打印期望的来源集合与实际得到的值。这样测试既正确（不接受任何非法实现，也不拒绝任何合法实现），又在失败时可诊断。

【代码对比解说】 这里体现的是一条重要原则：断言的强度必须恰好等于规格说明的承诺强度。断言过强（assertEquals(-3, result)）会拒绝合法实现，让测试变成规格的额外约束；断言过弱（什么都不查）则抓不到 bug。带消息的 assertTrue 是恰当的中间地带：它只表达规格真正承诺的性质，同时提供足够的调试信息。补充说明：JUnit 5 提供 assertAll 可以把多条性质断言聚合成一次报告，避免「修好第一条才发现第二条也失败」的往返。

【设计原则透视】 这条原则直接对应「正确（Correct）」的定义——测试套件是规格说明的合法客户，它必须接受所有合法实现。这也解释了为什么测试只依赖规格说明是如此重要：一旦测试依赖实现细节，实现就无法自由变化，「Ready for change」随之丧失。这条线索将在 Reading 06（规格说明）中被形式化为「规格说明同时约束客户与实现者」的契约思想。

场景 4：不是真正的单元测试——测试之间发生耦合

❌ 错误代码

import java.io.File;
import java.util.List;
import org.junit.Test;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

// 错误：测试 extract() 时先调用 load()，两个模块被绑在一起
public class ExtractorTestBuggy {

    @Test
    public void testExtractWords() {
        File file = new File("testdata/document.txt");
        String doc = load(file);              // 依赖另一个模块！
        List<String> words = extract(doc);
        assertTrue(words.contains("hello"));
        assertEquals(3, words.size());
    }
}

【错误代码的问题】

1. 失败时无法定位：bug 可能在 load（文件缺失、编码错误、路径拼接错），也可能在 extract。
2. 测试依赖文件系统状态：换一台机器、换个工作目录、文件被改动，测试就失败——脆弱且不可移植。
3. 它不是 extract 的单元测试，而是 load + extract 的集成测试，只是被误当成了单元测试。
4. 覆盖率的意义被削弱：extract 的分支覆盖情况被 load 的行为遮蔽（例如文件读不到时 extract 根本没被调用）。

✅ 正确代码

import java.io.File;
import java.nio.file.Files;
import java.nio.file.Path;
import org.junit.Test;
import static org.junit.Assert.assertEquals;

// load 的测试：单独处理文件输入，不牵涉 extract
public class LoadTest {
    /*
     * Testing strategy
     *
     * partition on file:
     *   the file is empty
     *   the file has exactly one line without a trailing newline
     *   the file has multiple lines, with a trailing newline
     */

    @Test
    public void testEmptyFile() throws Exception {
        // covers the file is empty
        Path p = Files.createTempFile("load-test", ".txt");
        assertEquals("", load(p.toFile()));
    }

    @Test
    public void testOneLine() throws Exception {
        // covers the file has exactly one line without a trailing newline
        Path p = Files.createTempFile("load-test", ".txt");
        Files.writeString(p, "hello");
        assertEquals("hello", load(p.toFile()));
    }
}

import java.util.List;
import java.util.Arrays;
import org.junit.Test;
import static org.junit.Assert.assertEquals;

// extract 的测试：输入是字面量字符串，完全不碰文件系统
public class ExtractTest {
    /*
     * Testing strategy
     *
     * partition on s:
     *   s is empty
     *   s has no words (only whitespace and punctuation)
     *   s has one word
     *   s has several words separated by whitespace and punctuation
     *   s starts or ends with punctuation
     */

    @Test
    public void testEmptyString() {
        // covers s is empty
        assertEquals(List.of(), extract(""));
    }

    @Test
    public void testNoWords() {
        // covers s has no words
        assertEquals(List.of(), extract("  ,;. "));
    }

    @Test
    public void testSeveralWords() {
        // covers s has several words separated by whitespace and punctuation
        assertEquals(List.of("hello", "world", "again"),
                     extract("hello, world!  again"));
    }
}

【为什么这样更好】 extract 的测试把输入写成字面量字符串，与文件系统彻底解耦：测试可移植、运行快、失败时你几乎可以确定 bug 就在 extract 里。load 有它自己的单元测试，专门覆盖空文件、单行、多行等划分。而对 index，我们再写一组（不可隔离的）测试来验证「连接逻辑」——因为前置的两个模块已经被各自验证过了，index 测试失败时我们可以把注意力集中在它调用各模块的方式上。

【代码对比解说】 关键区别在于测试用例的输入从哪里来。使用「贴近真实文件内容」的划分是完全合理的——因为那才是 extract 的真实用法；但不合理的是真的去调用 load。把自己的模块从依赖中解放出来，是单元测试的核心纪律。补充说明：当确实无法避免依赖（如网络、时钟、数据库）时，可以为它们写桩（stub）或 mock object：一个不访问真实外部资源、总是返回固定内容的替身。桩在大型系统中很重要，但 6.031 一般不用它。

【设计原则透视】 这一组对比把「单元测试 vs. 集成测试」的分工讲清楚了：单元测试负责把 bug 局部化到模块内部，集成测试负责发现模块之间连接处的 bug（例如 index 期待 extract 返回 List<String> 却拿到别的东西）。两者缺一不可，但顺序很重要——先有可靠的单元测试，集成测试失败时你才有信心把 bug 定位在连接逻辑上。这正对应 Reading 06/07 的抽象边界思想：模块之间的契约（规格说明）是连接处正确性的依据。

场景 5：遗漏边界值——gcd 的划分不完整

❌ 错误代码

import org.junit.Test;
import static org.junit.Assert.assertEquals;

// 错误：只测「正常」输入，忽略了边界与负值
public class GcdTestBuggy {

    @Test
    public void testBothPositive() {
        assertEquals(6, gcd(54, 24));
    }

    @Test
    public void testAnotherPair() {
        assertEquals(1, gcd(17, 5));
    }
}

【错误代码的问题】

1. 划分不完整：只覆盖了「两个正整数且互质/不互质」这一小块，完全没有覆盖 x = 0、y = 0、负数、x = y、一个数整除另一个数等子域。
2. 规格说明写的是「x 与 y 不同时为 0」，也就是说负数是被允许的，而负数正是实现最容易写错的地方（取模的符号语义）。
3. 这个测试套件小但不彻底——它写起来很快，但几乎抓不到任何真实 bug，给人一种虚假的安全感。
4. 没有测试策略注释，读者无从判断覆盖面，也无从判断该补哪些用例。

✅ 正确代码

import org.junit.Test;
import static org.junit.Assert.assertEquals;

public class GcdTest {
    /*
     * Testing strategy
     *
     * partition on (x, y):
     *   x and y are both positive
     *   x and y are both negative
     *   x and y have opposite signs
     *   x = 0 or y = 0 (but not both)
     *   x is divisible by y
     *   y is divisible by x
     *   x and y are relatively prime
     *   x = y
     * boundary values: x = 0, y = 0, Integer.MIN_VALUE, Integer.MAX_VALUE
     */

    @Test
    public void testBothPositive() {
        // covers both positive, x divisible by y
        assertEquals(6, gcd(54, 24));
    }

    @Test
    public void testRelativelyPrime() {
        // covers relatively prime
        assertEquals(1, gcd(17, 5));
    }

    @Test
    public void testOneIsZero() {
        // covers y = 0 (boundary)
        assertEquals(7, gcd(7, 0));
    }

    @Test
    public void testBothNegative() {
        // covers both negative
        assertEquals(6, gcd(-54, -24));
    }

    @Test
    public void testOppositeSigns() {
        // covers opposite signs
        assertEquals(6, gcd(54, -24));
    }

    @Test
    public void testEqualValues() {
        // covers x = y, and y divisible by x
        assertEquals(9, gcd(9, 9));
    }

    @Test
    public void testBothAtIntMinValue() {
        // covers the boundary Integer.MIN_VALUE
        assertEquals(Integer.MIN_VALUE, gcd(Integer.MIN_VALUE, Integer.MIN_VALUE));
    }
}

【为什么这样更好】 划分被完整地写出来并逐条覆盖，其中显式包含了 0、负号组合、相等、整除关系与 Integer.MIN_VALUE 这些最容易出 bug 的地方。测试策略注释让「彻底性」成为可见的事实：把划分与用例一一对照，就能看出有没有遗漏。注意最后一个用例：gcd(Integer.MIN_VALUE, Integer.MIN_VALUE) 的值是 -2³¹，而它的绝对值超出 int 范围——如果实现内部用了 Math.abs，这个用例会立刻暴露 bug。

【代码对比解说】 从两个用例到七个用例，覆盖的是行为差异而不是「更多数字」。第二组的价值不在于「测得更多」，而在于每一个新用例都对应一个实现可能采取不同代码路径的子域：符号处理、零值处理、整除分支。这正是「划分 + 边界」相对「多写几个用例」的本质优势。注意 gcd(7, 0) = 7 来自规格说明中「x 与 y 不同时为 0」的约定，而 gcd(0, 0) 是非法输入（无法用合法的测试用例覆盖），因此不应写成一个测试用例——那会违反「测试套件必须是规格说明的合法客户」这一正确性要求。

【设计原则透视】 这组对比完整演示了「正确、彻底、小」三性质的权衡：把 gcd(0, 0) 加进来会让套件不正确（它不是合法客户）；只写两个正数用例会让套件不彻底；而七个用例是在彻底与「小」之间取得的平衡。边界值的存在还体现了一条设计直觉：规格说明中特别提到的行为，一定是最值得测试的行为（Math.abs(Integer.MIN_VALUE)、gcd(x, 0) 都是规格说明专门交代过的特例）。

场景 6：白盒测试越界——断言规格没有承诺的实现细节

❌ 错误代码

import org.junit.Test;
import static org.junit.Assert.fail;

// 错误：断言了一个具体的异常类型，而规格说明只承诺「抛出异常」
public class ParserTestBuggy {

    @Test
    public void testBadlyFormattedInput() {
        try {
            parse("(((");
            fail("expected an exception");
        } catch (NullPointerException e) {     // 只接受 NPE
            // ok
        }
    }
}

【错误代码的问题】

1. 规格说明若只写「输入格式错误时抛出异常」，那么任何异常都是合法的；这个测试却只接受 NullPointerException，等于给实现者加了一条规格里没有的约束。
2. 这让测试不正确：一个完全合法的实现（例如抛 IllegalArgumentException）会被判定为失败。
3. 更隐蔽的是：如果实现先把输入解析成内部结构再检查，抛出的异常类型可能随内部重构而变化，测试随之「无故失败」，逼迫开发者去改测试而不是改实现。
4. 它把白盒测试的信息（实现细节）固化进测试，直接损害 Ready for change。

✅ 正确代码

import org.junit.Test;
import static org.junit.Assert.fail;

public class ParserTest {

    /*
     * Testing strategy
     *
     * partition on input text:
     *   text is well-formed
     *   text is empty
     *   text has unbalanced parentheses
     *   text has illegal characters
     */

    @Test
    public void testWellFormed() {
        // covers text is well-formed
        // ... assert the parsed structure
    }

    @Test
    public void testUnbalancedParentheses() {
        // covers text has unbalanced parentheses
        try {
            parse("(((");
            fail("expected an exception for unbalanced parentheses");
        } catch (Exception e) {
            // The spec permits any exception here, so we accept any.
            // (glass box knowledge: the current implementation happens to
            //  throw IllegalArgumentException, but the spec does not promise it.)
        }
    }
}

【为什么这样更好】 测试只断言规格说明承诺的性质（「会抛异常」），因此接受任何合法实现，实现者保有选择异常类型的自由。白盒知识仍然有用，但它被写在注释里作为提示，而不是写成断言——这样当实现重构、异常类型改变时，测试依然正确。

【代码对比解说】 这是本讲第一处提醒：做白盒测试时必须小心，测试用例不能要求规格说明没有明确承诺的实现行为。白盒测试的合法用法是「用实现知识去选择用例」（例如知道 sort 在 size < 10 时用 radixSort，于是专门测试 9、10、0 这些阈值），而不是「用实现知识去写断言」。区分这两件事，是白盒测试不越界的关键。

【设计原则透视】 这组对比把「正确」这一性质的深层含义揭示出来：测试套件是规格说明的合法客户，而不是实现者的助手。这条原则与 Reading 06（规格说明）中的「规格说明同时约束客户与实现者」完全同构，也是「Ready for change」的技术基础——只要测试只依赖规格，实现就可以在规格允许的范围内任意演进。

与其他设计原则的关联

• 与 Reading 01（静态检查 / Static Checking）：Reading 01 反复强调「静态检查抓不到与具体值相关的错误」，本讲正是填补这个空缺的系统方法——输入空间划分与边界值所覆盖的，恰恰是静态类型无法区分的那些具体值（除零、越界、Integer.MIN_VALUE、空集合）。
• 与 Reading 02（基本 Java / Basic Java）：本讲的测试代码大量使用集合与相等性；assertEquals 对 List 依赖 equals，对数组则必须用 assertArrayEquals，Set/Map 作为键的元素必须可哈希——这些都指向 Reading 15（相等性）。
• 与 Reading 04（代码审查 / Code Review）：本讲的「验证」包含代码审查这一手段；审查时检验「测试策略是否完整、断言强度是否恰当」是标准流程之一。
• 与 Reading 05（版本控制 / Version Control）：自动化回归测试是版本控制工作流的一部分——提交前重跑全部测试，是本讲明确列出的最佳实践。
• 与 Reading 06（规格说明 / Specifications） 和 Reading 07（设计规格说明 / Designing Specifications）：本讲的「正确测试套件 = 规格说明的合法客户」「白盒测试不得要求规格未承诺的行为」「前置条件与非法输入如何处理」都在那两讲被形式化。测试优先编程的「先写规格」一步也需要那两讲的写作技巧。
• 与 Reading 08（不可变性 / Immutability）：本讲场景 3 的 Set.of(...) 是不可变集合，能防止测试用例之间通过共享状态互相污染；不可变数据结构也天然让测试更容易推理。
• 与 Reading 09（避免调试 / Avoiding Debugging）：测试优先调试（bug 一出现就写一个引出它的测试）是那一讲的核心建议在本讲中的具体形态。
• 与 Reading 10（抽象数据类型 / Abstract Data Types） 与 Reading 11（抽象函数与表示不变量 / Abstraction Functions & Rep Invariants）：对 ADT 的测试不能只看单个方法，还要检验操作之间的交互与 RI 是否被维持——那是「更大模块」的测试策略。
• 与 Reading 13（调试 / Debugging）：当单元测试失败时，如何系统地缩小范围、形成假设、验证假设，是调试那一讲的主题。
• 与 Reading 29（团队版本控制 / Team Version Control）：持续集成（CI）在每次提交时自动运行回归测试，正是本讲「自动化回归测试」的工程化落地。

关键要点

• 先写规格与测试，再写实现：测试优先让你在还没「爱上」自己的代码时就戴上残酷的测试帽子，也让规格说明中的歧义与遗漏更早暴露。
• 用划分与边界代替穷举与随机：把输入空间切成不相交且完整的子域，从每个子域取一个代表，并把边界值写成单元素子域；多参数时优先用多个独立划分，再补一个捕捉交互的划分。
• 测试套件要满足正确、彻底、小：正确的核心是「只依赖规格说明、接受所有合法实现」；彻底意味着覆盖程序员可能犯的错；小意味着写得快、改得快、跑得快。
• 断言强度必须匹配规格承诺强度：有唯一答案时精确断言，有多个合法答案时断言性质并附上可诊断的消息；assertEquals 在 JUnit 中永远是「expected 在前，actual 在后」。
• 把测试策略写下来，让覆盖率指路，并让测试自动化地反复运行：划分注释让彻底性可见；覆盖率（语句/分支/路径）用来发现漏测，路径覆盖不可行而语句与分支覆盖是实用目标；单元测试隔离地测模块、集成测试测连接，每修好一个 bug 就把引发它的输入加入回归测试。

常见陷阱与注意事项

1. 断言了规格没有承诺的实现行为（如只接受 NullPointerException、断言随机函数返回某个具体值）。→ 后果：测试拒绝合法实现，实现者被迫为了通过测试而写「迎合测试」的代码，Ready for change 彻底丧失。
2. 把集成测试当单元测试用（测试 extract 时先调用 load）。→ 后果：测试失败时无法定位 bug，且测试依赖文件系统等外部状态，脆弱且不可移植。
3. 边界值漏测或划分不完整：只测「正常」输入，漏掉 0、空集合、Integer.MIN_VALUE/MAX_VALUE、字符串首尾元素；或写出 Math.max 只有 a < b; a > b 而丢掉 a = b、以及要求非负参数却划出 x < 0 子域这类不合格划分。→ 后果：off-by-one、符号处理、溢出这些最常见的 bug 全部漏网（Math.abs(Integer.MIN_VALUE) 就是典型），或者写出无法用合法输入覆盖的用例。
4. assertEquals 参数顺序写反。→ 后果：失败信息中的 expected/actual 互换，调试方向被误导，且编译期毫无提示。
5. 在迭代中修改集合来「构造」测试输入，或让多个测试用例共享同一个可变集合。→ 后果：测试之间互相污染，出现「单独跑通过、一起跑失败」的诡异现象（对应 Reading 02 的迭代陷阱，建议使用 Set.of/List.of 等不可变字面量）。
6. 把「100% 语句覆盖率」当成质量保证。→ 后果：覆盖率高但断言贫弱（「执行了但没检查」）的测试套件会给出虚假的安全感；覆盖率是发现遗漏的工具，不是正确性的证明。

思考题（带答案）

问题 1：下面这个函数的规格说明是「返回数组所有元素的布尔与」，实现如下。请指出它的 bug，说明为什么「随意挑选的测试用例」很可能发现不了它，并给出一个能发现它的、基于划分的测试套件。

/**
 * @param bits an array of 32 true/false values
 * @return the Boolean AND of all values in the array
 */
boolean andAll(boolean[] bits) {
    boolean result = bits[0];
    for (int i = 1; i < 31; i++) {
        result = result && bits[i];
    }
    return result;
}

答案：bug 在循环条件 i < 31——它漏掉了下标 31 的元素（off-by-one），正确应为 i < bits.length（或 i < 32）。这个 bug 属于「只在特定输入上出现」的类型：如果数组的第 32 个元素恰好与前面所有元素的与相同（例如全是 true，或最后一个是 true），结果就是正确的；只有在第 32 个元素为 false 而前面全为 true 时才会出错。所以「随意挑几个用例」（如全 true、交替真假）都可能碰巧给出正确结果。穷举测试需要 2³² 个用例，随机测试发现的概率约为 1/2³²（只有「前 31 个全真且第 32 个为假」这一个输入会失败），几乎为零。基于划分的测试套件应包含：bits 全为 true（覆盖「与为真」的子域）、bits 全为 false、前 31 个为 true 而第 32 个为 false（关键边界：决定结果的是最后一个元素）、第 1 个为 false 其余为 true（覆盖 bits[0] 就决定结果的路径）、以及交替真假。其中「最后一个元素为 false、其余全 true」这一条来自 边界值 分析（序列的第一个与最后一个元素是经典边界），也是唯一能揪出该 bug 的用例。这个例子同时说明：测试的价值来自划分与边界，而不来自用例数量。

问题 2：某同学为 sort(List<Integer> values) 写了测试策略注释：「partition on values: 长度为 0、长度为 1、长度小于 10、长度在 10 到 10⁹ 之间、长度大于 10⁹」。请评估这个划分，并说明它属于黑盒测试还是白盒测试。如果他是先写的测试（测试优先编程），这个划分可能吗？

答案：这个划分不相交且完整（任何列表长度恰好落入其中一个子域），但它显然来自白盒测试——因为 10 与 10⁹ 这两个阈值只在实现里才存在：实现根据 values.size() 在 radixSort（< 10）、quickSort（< 10⁹）、mergeSort（否则）之间切换。单纯看规格说明（「把列表按非递减顺序原地排序」），没有任何理由认为 9 和 10、10⁹-1 和 10⁹ 是行为分界点。因此后两个子域在长度 > 10⁹ 时无法用合法测试用例覆盖（现实中造不出这么大的列表），按「划分必须正确」的标准，它们是不合格的子域——至少在实践中不合格。如果是先写测试（测试优先编程），这个划分不可能产生：那时还没有实现，无从知道算法切换点，只能依据规格写出「空列表 / 单元素 / 多个元素 / 已排序 / 逆序 / 含重复元素」这类黑盒子域。这正说明两种测试的恰当分工：测试优先阶段做黑盒测试（只依赖规格、保证正确性），实现完成后再用白盒知识补充用例（借助覆盖率找出实现特有的分支），但补充时必须确保这些用例仍然只用合法输入，且不断言规格未承诺的行为。

问题 3：某项目中所有测试都是集成测试（整个程序端到端跑一遍），而且都通过了。为什么这门课仍然坚持要为每个模块写单元测试？请结合「代码覆盖率」与「回归测试」各给出一条理由。

答案：第一，覆盖率与彻底性：端到端测试往往只走到每段代码的一条主要路径，load 的文件缺失分支、extract 的空字符串分支、index 的空文件集合分支几乎必然处于红色状态；而单元测试可以对每个模块独立地做划分与边界覆盖，把覆盖率补起来——模块内部的 bug 只有在直接以各种输入照射它时才会暴露。第二，定位与回归：集成测试失败时，bug 可能在程序任何地方，排查成本随模块数线性增长；而单元测试失败时你可以确信 bug 在该模块内，定位几乎不需要搜索。这两点叠加起来对「回归测试」尤其重要：本讲要求「每修好一个 bug，就把引发它的输入加入测试套件」，如果只有集成测试，那么这些回归测试运行慢、失败信息模糊，很难在每次提交前跑完，最终就没人跑了——自动化回归测试的前提是测试又小又快，而这正是单元测试的优势。当然，集成测试也不可或缺：模块之间的连接处（如 index 期待 extract 返回的格式与实际不符）只有集成测试能发现。二者互补：单元测试把 bug 局部化，集成测试守住边界。

Reading 4: 代码审查（Code Review）

说明：本讲 sp22 原版使用 TypeScript，本笔记按用户要求提供 Java 代码示例；类型/API 与 sp21（6.031 Java 版）原文保持一致。凡属笔记额外补充的 Java 生态知识，均以「补充说明」标注。

概述

代码审查（code review）是由非作者本人对源代码进行的仔细而系统的研究，它和校对论文是同一种活动：目的不是证明作者愚蠢，而是让缺陷在最早、最便宜的时刻暴露出来。它有两个并列的目的——改进代码（找 bug、预判 bug、检查清晰度、检查是否符合项目风格标准）和改进程序员（彼此学习新的语言特性、设计变更与编码标准）。6.031 把代码审查当作贯穿全学期的工程实践，因为这套方法有扎实的实证支持：研究表明代码审查可以发现 70%–90% 的软件缺陷，Google 的流程甚至规定没有第二位工程师签字就不能把代码推入主仓库。

本讲的重点不是”审查的社交礼仪”，而是一份可操作的好代码清单：不要重复自己（DRY）、在需要的地方写注释、快速失败（fail fast）、避免魔法数字、每个变量只有一个用途、使用好名字、用空白帮助读者、不要用全局变量、函数应当返回结果而不是打印它们、避免特例代码。这十条规则全都直接服务于 6.031 的三大目标：Safe from bugs（免于 bug）——DRY 让一个 bug 只需修一处，快速失败让缺陷靠近源头被发现，避免全局变量让 bug 的影响范围被限制；Easy to understand（易于理解）——注释、命名、避免魔法数字、空白排版让读者不必反向工程作者的意图；Ready for change（为变更而设计）——DRY 与”返回结果而非打印”让代码能被用于作者当初没想到的新场景。一句话总结本讲的立场：代码审查是唯一能发现”晦涩难懂代码”的手段，因为只有另一个人真的去读它、试图理解它，晦涩才会被暴露。

核心概念与设计原则详解

代码审查（Code Review）

• 定义与目的：由代码作者之外的人对源代码做仔细、系统的检查。它同时服务于安全性（发现与预判 bug）、易理解性（发现晦涩代码）与可修改性（由有经验的开发者预判未来变化并建议防护措施）。
• 直观解释（”它是什么？”）：把代码当成一篇要投稿的论文，审查者就是审稿人。审稿人不会替你重写，而是指出”这里读者会误解”、”这个假设没有写下来”、”这两段逻辑重复了，将来改一处忘另一处”。开源项目（Apache、Mozilla）与工业界（Google）都广泛采用它，Google 的规则是：没有另一位工程师在审查中签字，任何代码都不能进入主仓库。
• 关键规则与最佳实践：
  • 不要替作者重排格式：审查是针对语义与可维护性，不是把你的个人风格强加给别人；擅自把每个模块都重新格式化，队友”会恨你，而且恨得有理”。
  • 保持自洽并遵守项目约定——风格是个人选择，但项目一致性是团队义务。
  • 区分”两类问题”：一类是风格（大括号放哪里，属于圣战级的口味问题），一类是能强化三大目标的实质规则（DRY、fail fast、命名等），后者才是本讲的重点。
  • 审查是双通道学习：作者学到新技术，审查者也从别人的代码里学到新写法，因此不要把它当作单向的挑错。
  • 审查清单不是穷尽的；随着课程推进，规格说明、表示不变量、并发与线程安全都会成为新的审查素材。

快速失败（Fail Fast）

• 定义与目的：代码应尽可能早地暴露自己的缺陷。问题被观察到的时间越早、离成因越近，定位和修复就越容易。它主要服务 Safe from bugs。
• 直观解释（”它是什么？”）：静态检查比动态检查失败得更快，动态检查又比”算出一个错误答案并污染后续计算”失败得更快。dayOfYear 就是个反面典型：如果按”月/日/年”以外的顺序传参，它不会报错，只会安静地返回一个错误答案。
• 关键规则与最佳实践：
  • 优先用静态检查（类型、枚举、final）而不是运行时检查；能用类型表达的前置条件就不要留给注释。
  • 不能静态表达时，用动态检查，并且尽早检查——进入业务逻辑之前就检查。
  • 抛异常属于”动态失败”，返回 -1、null 或 false 属于”静默失败”，后者最慢，因为它把错误推迟到很远的地方才爆发。
  • 用更强的类型承载语义：把 int month 换成 enum Month { JANUARY, ..., DECEMBER }，把参数的顺序错误变成静态错误；把 int month 换成 String month 也能让”顺序搞错 + 类型不符”变成静态错误。
  • 在分支结构的 else 兜底处抛异常（而不是漏掉），可以把”漏掉一种情况”变成运行时的即时失败。

防御性编程 vs 快速失败（Defensive Programming vs Fail Fast）

• 定义与目的：防御性编程指代码主动处理”理论上不该发生”的输入或状态，不假设调用者守规矩；快速失败指代码在假设被破坏时立刻、响亮地失败。两者不是对立的口号，而是边界之分。
• 直观解释（”它是什么？”）：对来自程序外部（用户输入、文件、网络、第三方库）的数据，你必须防御，因为那里没有契约可依赖；对程序内部的调用，契约由规格说明（Reading 6）保证，此时”防御”反而有害——它会把你本该知道的 bug 悄悄吞掉，让错误在下游以更难理解的形式出现。
• 关键规则与最佳实践：
  • 内部代码：相信前置条件，违反前置条件时抛异常或断言失败（fail fast）。
  • 外部边界：解析、校验、拒绝非法输入，并把失败转译成上层可以理解的异常（异常转译）。
  • 绝不”静默修正”内部错误：不要 if (month < 1) month = 1; 这类”容错”，那会把 bug 变成错误答案。
  • 断言（assertions）属于”开发期快速失败”：课程在 Reading 9（Avoiding Debugging）与 Reading 11（Abstraction Functions & Rep Invariants）中会把它作为检查前置条件与表示不变量的工具深入展开。
  • 记住判据：这个检查是在保护”我不信任的人”，还是在掩盖”我自己的 bug”？ 前者是防御，后者是自欺。

不要重复自己（Don’t Repeat Yourself, DRY）

• 定义与目的：重复代码是安全风险——如果两份相同或相似的代码里藏着一个 bug，维护者很可能只修了其中一份。它同时服务三大目标。
• 直观解释（”它是什么？”）：把复制粘贴想象成不看来车就横穿马路。复制的代码块越长，风险越高。dayOfYear 里”4 月有多少天”这个问题被写了多次，一旦历法变了，你得改很多处，而且总会漏掉一处。
• 关键规则与最佳实践：
  • 数值重复、逻辑重复、结构重复都算重复；三种都要消除。
  • 消除数值重复的办法是命名常量或数据表（如 monthLength[month]）。
  • 消除逻辑重复的办法是循环或辅助函数（如把 dayOfMonth += ... 收敛为一次累加）。
  • 不要硬编码你手工算出来的数（例如 59、90 这种”几个月天数之和”）；用可见地由其他命名常量计算出来的表达式。
  • 重复出现三次以上的字面量就该被提取，”三振出局”是常见经验法则。

在需要的地方写注释（Comments Where Needed）

• 定义与目的：好注释让代码更易理解、更安全（重要假设被记录下来）、更可修改。注释分两类：规格说明（specification）与出处说明（provenance）。
• 直观解释（”它是什么？”）：注释是对”代码看不出来的信息”的补充。代码本身能表达”做了什么”，注释要表达”为什么这样做、假设了什么、来源是哪里”。把代码逐行翻译成英文的注释毫无价值，因为你应当假设读者至少懂 Java。
• 关键规则与最佳实践：
  • 每个方法/类上方写 Javadoc 规格说明：/** ... @param ... @return ... */，把前置条件写进 @param，后置条件写进 @return（详见 Reading 6）。
  • 抄来或改编的代码必须注明出处（这也是 6.031 协作政策的要求），既避免版权问题，也提醒后来者”这段代码可能过时或有已知缺陷”。
  • 不要写”把代码翻译成英文”的注释：++i; // increment i 是噪声。
  • 晦涩但正确的代码需要注释解释其数学/物理依据，例如 // Gauss's formula for the sum of 1...n。
  • 更好的做法常常是改名字/改结构来消除对注释的需求：const tmp = 86400; // number of seconds in a day 应改成 secondsPerDay。

避免魔法数字（Avoid Magic Numbers）

• 定义与目的：除 0、1（有时 2）之外凭空出现的常量都叫魔法数字，因为它们”像从稀薄空气里冒出来”，没有任何解释。消除它们同时改善可读性与可修改性。
• 直观解释（”它是什么？”）：读到 if (month == 2) 时，你无法确定 2 指一月、二月、三月还是公元 2 年。魔法数字让读者必须去猜，而猜错是 bug 的温床。turtle.rotate(3) 里的 3 到底是 3 度、3 弧度还是 3 整圈？光看调用点无法判断。
• 关键规则与最佳实践：
  • 用命名常量替代字面量：FEBRUARY 显然比 2 可读。
  • 常量之间常有依赖关系：59 与 90 是手算出来的和，应当写成由其他命名常量计算出的表达式。
  • 即使是 π、G 这类”永恒常量”也值得命名：一是避免抄错数字（3.14159265358979323846 与 3.1415926538979323846 谁对？），二是精度、单位这类设计决策未来会变，命名常量更易改。
  • 当魔法数字大量出现时，考虑把它们当成数据而不是常量，放进数组/映射等数据结构，让代码退化成一次查表（monthLength[month]）。
  • 判断”0 是否是魔法数字”的准则：它是否承载了领域含义？for (int i = 0; ...) 与 if (list.size() == 0) 里的 0 是普适常识；if (date.getMonth() == 0) 里的 0 是”一月”，是魔法数字。

每个变量只有一个用途（One Purpose for Each Variable）

• 定义与目的：变量不是稀缺资源——随手引入、起好名字、不再需要就停用。复用参数或变量会让读者困惑，也埋下 bug。
• 直观解释（”它是什么？”）：dayOfYear 把参数 dayOfMonth 复用成了”一年中的第几天”，两个含义完全不同的值共用一个名字。如果几行之后有人还需要”这个月几号”，信息已经丢失了。
• 关键规则与最佳实践：
  • 参数默认不应被修改：未来的改动可能还需要知道传入时的原值。
  • 用 final 修饰参数与尽可能多的局部变量，让编译器做静态检查（Java 支持 final 参数，这是 Java 相对 TypeScript 的一个便利之处）。
  • 需要新含义时引入新变量，而不是覆盖旧变量。
  • 循环变量只在循环内使用，不要借它传递跨循环的信息。
  • 如果一个变量在方法中途”换了身份”，这是明确的重构信号。

使用好名字（Use Good Names）

• 定义与目的：好的方法名与变量名又长又自解释，往往能完全替代注释。它主要服务易理解性，也间接改善安全性与可修改性。
• 直观解释（”它是什么？”）：tmp、temp、data 是糟糕的名字——每个局部变量都是临时的，每个变量都是数据，这类名字因此毫无信息量。名字应让代码”自己会说话”。
• 关键规则与最佳实践：
  • 遵循语言的词法约定：Java 中类名首字母大写，变量名与方法名首字母小写，多词用 camelCase（startsWith、getFirstName），全局常量用 ALL_CAPS_WITH_UNDERSCORES。
  • 方法名通常是动词短语（getDate、isUpperCase），变量名与类名通常是名词短语。
  • 避免缩写：message 比 msg 清楚，word 远胜 wd；很多队友的母语不是英语，缩写对他们更难。
  • 避免单字符变量名，除非是公认惯例：笛卡尔坐标的 x、y，循环里的 i、j。
  • 名字可以暗示类型或单位：widthInPixels、secondsPerDay、bookTitle 让读者不必去查声明。

用空白帮助读者（Use Whitespace to Help the Reader）

• 定义与目的：一致的缩进、行内空格、多行对齐能让代码结构对眼睛”显形”，主要服务易理解性。
• 直观解释（”它是什么？”）：dayOfYear 把相加的数排成整齐的列，读者一眼就能比较相邻两行差在哪；leap 把整行条件挤在一起，读者需要逐字符解析。同一份逻辑，排版决定了它的可读性。
• 关键规则与最佳实践：
  • 缩进保持一致；不要用制表符，只用空格字符（不同工具把 tab 展开成 2/4/8 个空格，git diff 或换编辑器看代码时缩进会全乱）。
  • 二元运算符两侧加空格（===、||），让运算符”跳出来”。
  • 多行条件对齐，使相似与差异一目了然。
  • 用空行分隔逻辑段落，让方法结构（准备—计算—返回）自解释。
  • 编辑器应配置为按 Tab 键时插入空格（新版 6.031 环境已默认如此）。

不要使用全局变量（Don’t Use Global Variables）

• 定义与目的：全局变量既能从程序任何位置读取、也能从任何位置修改，因此 bug 的影响范围无法收敛。它主要损害 Safe from bugs 与 Ready for change。
• 直观解释（”它是什么？”）：Java 中全局变量由 public static 声明：public 让它处处可见，static 让它只有一份实例。任何一段代码都能改它，任何一次调用都可能被上一次调用污染。
• 关键规则与最佳实践：
  • 判据是两条同时成立：它是变量（值可变），且它是全局的（处处可读可写）。
  • 加上 public static final 且类型不可变，它就变成全局常量——处处可读、永不重赋值或变异，风险消失。全局常量常见且有用。
  • 把全局变量改写为参数与返回值，或放进对象里、通过对象的方法访问。
  • 单例式”配置对象”也应尽量以参数形式显式传递，让依赖关系可见。
  • 快照图（snapshot diagram）中要区分局部变量、实例变量、全局变量，因为它们的生命周期完全不同。

函数应当返回结果，而不是打印它们（Functions Should Return Results, Not Print Them）

• 定义与目的：把结果打印到控制台会锁死函数的使用场景——当结果要用于计算而非给人看时，函数必须重写。它主要损害 Ready for change。
• 直观解释（”它是什么？”）：只有程序的最高层才应该与用户/控制台交互；低层组件应把输入作为参数接收、把输出作为返回值交付。调试输出是唯一例外，但它是调试手段而不是设计的一部分。
• 关键规则与最佳实践：
  • 方法签名要能表达全部结果：List<Integer> 不够表达”计数 + 最长单词”两个结果，应返回一个不可变的小对象。
  • 不要让方法既修改全局状态又打印——两个副作用都让测试困难。
  • 单个结果就返回它，不要返回”是否成功”的布尔值而把结果留在输出参数里。
  • 需要多个结果时，返回一个小类（Java 16+ 可用 record，见补充说明）。
  • 打印只发生在程序的边界层（main、命令行前端、UI 层）。

避免特例代码（Avoid Special-Case Code）

• 定义与目的：为”看起来特殊”的输入（0、空数组、空字符串）单独写分支，会让代码更长、更难理解、更容易出现不一致。它损害全部三大目标。
• 直观解释（”它是什么？”）：countLongWords 开头的 if (words.length == 0) 分支是多余的——省略它，空数组会让 for 循环什么都不做，最终照样打印 0。更糟的是：这个特例分支漏掉了通用代码里对 longestWord 的初始化，于是”空数组”与”非空但没有长单词”这两种都应得到相同结果的输入，行为却不一致。
• 关键规则与最佳实践：
  • 写下特例 if 之前先停下来：通用代码是不是本来就能处理它？往往是。
  • 先写通用情形，再考虑特例；不要”先易后难”。
  • 性能理由不成立时不成立：只有在有证据表明特例真的影响性能时才优化，否则只是增加复杂度和 bug 藏身处。
  • 通用代码更短、假设更少、修改点更少，因此同时更安全、更好懂、更好改。
  • 特例分支一旦存在，就必须与通用路径的结果保持一致——这正是 bug 最常出现的地方。

代码示例与对比分析

场景 1：计算一年中的第几天——魔法数字、重复、参数复用三宗罪

❌ 错误代码

// 错误：魔法数字 + 复制粘贴 + 复用参数 dayOfMonth
public static int dayOfYear(int month, int dayOfMonth, int year) {
    if (month == 2) {
        dayOfMonth += 31;
    } else if (month == 3) {
        dayOfMonth += 59;                    // 59 是手工算出来的 31+28
    } else if (month == 4) {
        dayOfMonth += 90;                    // 90 是手工算出来的 31+28+31
    } else if (month == 5) {
        dayOfMonth += 31 + 28 + 31 + 30;
    } else if (month == 6) {
        dayOfMonth += 31 + 28 + 31 + 30 + 31;
    } else if (month == 7) {
        dayOfMonth += 31 + 28 + 31 + 30 + 31 + 30;
    } else if (month == 8) {
        dayOfMonth += 31 + 28 + 31 + 30 + 31 + 30 + 31;
    } else if (month == 9) {
        dayOfMonth += 31 + 28 + 31 + 30 + 31 + 30 + 31 + 31;
    } else if (month == 10) {
        dayOfMonth += 31 + 28 + 31 + 30 + 31 + 30 + 31 + 31 + 30;
    } else if (month == 11) {
        dayOfMonth += 31 + 28 + 31 + 30 + 31 + 30 + 31 + 31 + 30 + 31;
    } else if (month == 12) {
        dayOfMonth += 31 + 28 + 31 + 30 + 31 + 30 + 31 + 31 + 30 + 31 + 31;
    }
    return dayOfMonth;
}

【错误代码的问题】

1. 复用参数：dayOfMonth 先表示”这个月几号”，随后被改写为”一年中第几天”，两个含义不同的值共用一个名字，读者极易误解，任何后续需要原值的改动都做不到。
2. 大量魔法数字与手工求和：59、90 是作者心算的结果，读者无法验证；一旦历法变化（例如二月改成 30 天），需要改动的数字分散在多处，极易漏改。
3. 严重重复：dayOfMonth += ... 出现 11 次，”4 月有多少天”这个知识在多行里重复表达。
4. 不快速失败：参数顺序传错（例如非美式日期习惯的 dayOfYear(9, 2, 2019)）不会报任何错，只是安静地返回错误答案；没有任何注释说明 month 是 1–12 还是 0–11。

✅ 正确代码

// 正确：命名常量 + 数据表 + 单一用途变量 + final 参数 + fail fast + Javadoc
private static final int[] MONTH_LENGTH =
    { 0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };  // 索引 1 = 一月

/**
 * Compute the day of the year.
 * @param month month of the year, where January=1 and December=12
 * @param dayOfMonth day of the month, where 1 <= dayOfMonth <= days in that month
 * @param year the year, in the Gregorian calendar
 * @return the day of the year, counting from 1; for example
 *         dayOfYear(2, 9, 2019) = 40
 * @throws IllegalArgumentException if month or dayOfMonth is out of range
 */
public static int dayOfYear(final int month, final int dayOfMonth, final int year) {
    if (month < 1 || month > 12) {
        throw new IllegalArgumentException("month out of range: " + month);
    }
    if (dayOfMonth < 1 || dayOfMonth > monthLength(month, year)) {
        throw new IllegalArgumentException("day out of range: " + dayOfMonth);
    }
    int dayOfYear = dayOfMonth;                 // 新变量承担新用途，参数不被污染
    for (int m = 1; m < month; ++m) {
        dayOfYear += monthLength(m, year);
    }
    return dayOfYear;
}

/** @return the number of days in month of year, where January=1 */
private static int monthLength(final int month, final int year) {
    if (month == 2 && isLeapYear(year)) {
        return 29;
    }
    return MONTH_LENGTH[month];
}

【为什么这样更好】 参数被声明为 final，编译器会阻止复用；dayOfYear 是一个全新的局部变量，用途单一；月份长度变成一张数据表加一次查表，重复的逻辑被 for 循环收敛为一次累加，重复的数字被 MONTH_LENGTH 收敛为一处定义；越界检查把”参数顺序传错”从”安静的错误答案”变成”立刻抛出的异常”；Javadoc 明确写了月份从 1 开始，消除了读者最大的猜测成本。

【代码对比解说】 两版代码在”正确输入下”的输出完全一致，差别全在可维护性曲线上：错误版本每增加一个特殊规则（闰年、历法改革）都要在多行里同步修改，且修改点之间没有结构约束；正确版本把”每个月几天”这个领域知识集中到一个地方，把”累加”这个算法收敛成一个循环。注意这里同时用到了两条本讲的原则：用数据表消除魔法数字，用循环消除逻辑重复。还要注意 MONTH_LENGTH[0] = 0 这个占位元素——它让 MONTH_LENGTH[month] 直接以 1 为下标，是”用一点空间换掉一次减法”的常见手法，但它本身必须靠注释或命名说清楚，否则下标从 0 还是 1 开始又变成了新的猜测点。

【设计原则透视】 这一组把 DRY、避免魔法数字、每个变量一个用途、快速失败四条规则叠在一起。用规格说明的语言说：错误版本隐式假设了”month 是 1–12”这一前置条件却从未写下，因此客户违反它时实现返回垃圾值；正确版本把该前置条件写进 @param，并在实现中主动检查，把违反前置条件变成显式的动态错误——这正是 Reading 6（Specifications）中”前置条件是客户的责任”的具体落地。

场景 2：闰年判断——把数字当字符串、糟糕命名、隐晦逻辑

❌ 错误代码

// 错误：靠字符串下标取十进制位、名字无意义、隐式魔法数字、逻辑难以核对
public static boolean leap(int y) {
    String tmp = String.valueOf(y);
    if (tmp.charAt(2) == '1' || tmp.charAt(2) == '3' || tmp.charAt(2) == 5
            || tmp.charAt(2) == '7' || tmp.charAt(2) == '9') {
        if (tmp.charAt(3) == '2' || tmp.charAt(3) == '6') return true;   /*R1*/
        else return false;                                              /*R2*/
    } else {
        if (tmp.charAt(2) == '0' && tmp.charAt(3) == '0') return false;  /*R3*/
        if (tmp.charAt(3) == '0' || tmp.charAt(3) == '4' || tmp.charAt(3) == '8') return true; /*R4*/
    }
    return false;                                                       /*R5*/
}

【错误代码的问题】

1. 隐式假设年份恰好是 4 位数字：charAt(2)、charAt(3) 在 leap(916)（3 位）或 leap(10016)（5 位）时会抛 StringIndexOutOfBoundsException，或读到完全错误的位置。
2. tmp.charAt(2) == 5 是真实的静默 bug：charAt 返回 char，与 int 字面量比较是合法的数值比较，'5' 的码点是 53，永远不等于 5。于是”十位是 5”这一支永远不会命中，代码不会报编译错误，只会算错。
3. 名字 leap、tmp 毫无信息量；R1–R5 这样的行号注释只告诉你”这是第几条返回”，不告诉你”为什么”。
4. 只支持公元 4 位数年份、无法表达闰年规则本身，读者必须做心算才能确认它对不对。

✅ 正确代码

// 正确：命名好、规则直接可见、逻辑用算术表达、使用辅助方法消除重复
/**
 * Test whether a year is a leap year in the Gregorian calendar.
 * @param year a year in the Gregorian calendar; requires year >= 1
 * @return true if and only if year is a leap year, i.e. divisible by 4
 *         but not by 100, unless it is also divisible by 400
 */
public static boolean isLeapYear(final int year) {
    return isDivisibleBy(year, 4)
        && (!isDivisibleBy(year, 100) || isDivisibleBy(year, 400));
}

/** @return true if and only if number is divisible by factor */
private static boolean isDivisibleBy(final int number, final int factor) {
    return number % factor == 0;
}

【为什么这样更好】 方法名 isLeapYear 是动词短语且自解释；规则直接写成算术表达式，与公历闰年定义一一对应，读者可以逐字核对；isDivisibleBy 消除了四处重复的取模逻辑；不再依赖字符串下标，因此对任意位数的年份都正确；剩下的数字 4、100、400 是领域定义的一部分——它们就是闰年定义本身，而不是”算出来的中间量”，因此可以接受为具名方法参数中的字面量（若想更进一步，也可声明为 private static final int YEARS_PER_LEAP_CYCLE = 4; 之类的常量）。

【代码对比解说】 错误版本的”聪明之处”（用十进制字符判断整除性）恰恰是它最大的问题：它把程序员的心理过程固化成代码，而把问题定义丢掉了。正确版本反过来——先写下定义，再让代码逐字对应定义。注意 isDivisibleBy 并没有让代码变短很多，但它把”取模等于 0”这一惯用法命名了，使 isLeapYear 的三行读起来像一句英文。这就是”好名字可以替代注释”的典型场景：正确版本几乎不需要行内注释，因为名字已经说明了一切。补充说明：Java 8 的 java.time.Year.isLeap(int) 已经实现了这个规格，实际项目中应优先复用标准库，而不是自己重写——这也是一条 DRY。

【设计原则透视】 这组对比同时体现易理解性（命名与结构）与安全性（消除静态无法发现、运行时静默出错的 char == int 比较）。它也与 Reading 1（Static Checking）呼应：错误版本把类型系统本来可以帮忙的地方（用 int 直接做算术）换成了字符串操作，从而主动放弃了静态检查的保护。此外 isDivisibleBy 是一个纯粹的函数——没有副作用、结果只依赖参数——这种”纯函数”是最容易测试、最容易推理的代码形态，与 Reading 6（Specifications）中”后置条件只谈参数与返回值”的理想规格一致。

场景 3：统计长单词——全局变量、打印结果、特例代码

❌ 错误代码

// 错误：可变全局变量 + 打印结果 + 空列表特例分支（且特例与通用路径不一致）
public static int LONG_WORD_LENGTH = 5;      // 缺少 final：任何人都能改这个"常量"
public static String longestWord;            // 全局可变状态，处处可读写

public static void countLongWords(String text) {
    String[] words = text.split(" ");
    if (words.length == 0) {                 // 特例分支：多余，且漏了 longestWord 的初始化
        System.out.println("0");
        return;
    }
    int n = 0;
    longestWord = "";
    for (String word : words) {
        if (word.length() > LONG_WORD_LENGTH) ++n;
        if (word.length() > longestWord.length()) longestWord = word;
    }
    System.out.println(n);                   // 结果被打印，无法被程序复用
}

【错误代码的问题】

1. 全局可变状态：longestWord 在任何地方都能被读取和修改，调用一次之后结果会残留，两个线程或两次嵌套调用会互相污染，bug 的影响范围无法界定。
2. 结果被打印而不是返回：想把这个计数用于排序、写报告或聚合时就只能重写方法；单元测试也不得不捕获标准输出，测试变得脆弱（与 Reading 3 Testing 直接冲突）。
3. 特例分支与通用分支行为不一致：空数组时 longestWord 不会被重置为 ""，于是”空数组”与”非空但没有长单词”这两种都该得到 0 的输入，留下了 longestWord 的残留值——这正是课程原文指出的隐藏 bug。
4. LONG_WORD_LENGTH 声明为 public static（而非 public static final），它仍然是一个全局变量。

✅ 正确代码

// 正确：全局常量 + 返回结果对象 + 无特例分支 + 参数 final
public static final int LONG_WORD_LENGTH = 5;   // 全局常量：只读，风险消失

/** The two results of countLongWords, bundled into one immutable value. */
public static final class WordStats {
    private final int count;
    private final String longestWord;
    public WordStats(final int count, final String longestWord) {
        this.count = count;
        this.longestWord = longestWord;
    }
    /** @return the number of words longer than LONG_WORD_LENGTH */
    public int count() { return count; }
    /** @return the longest word in the text, or "" if there are no words */
    public String longestWord() { return longestWord; }
    @Override public String toString() {
        return count + " long words, longest = \"" + longestWord + "\"";
    }
}

/**
 * Count the words in text that are longer than LONG_WORD_LENGTH,
 * and find the longest word.
 * @param text words separated by single spaces
 * @return the count and the longest word; for empty text, count is 0 and
 *         the longest word is "" (the general case handles this correctly)
 */
public static WordStats countLongWords(final String text) {
    int count = 0;
    String longest = "";
    for (String word : text.split(" ")) {        // 空数组时循环体不执行，自然得到 (0, "")
        if (word.length() > LONG_WORD_LENGTH) ++count;
        if (word.length() > longest.length()) longest = word;
    }
    return new WordStats(count, longest);
}