收藏功能从需求到交付：把前面的小步骤连起来
现在你已经分别见过需求、设计、提交、测试与发布。真正做项目时，它们不会各自待在课本章节里。本章把同一个收藏功能串起来，得到一份能展示、能检查、也能说明限制的小作业。
1. 先拿到一张有边界的需求卡
目标是让读者找回稍后阅读的文章。完整产品要求登录、跨设备保存、私人列表和取消；第一轮代码练习只实现本地收藏状态规则。两者必须区分，不能用本地数组的成功演示代替完整网站验收。
把完整产品的验收条件写成 FAV-01 到 FAV-05：成功保存并刷新可见；重复保存不增加记录；取消后不再出现；账号之间隔离；失败时不误报成功。然后标注每条由哪一层验证。
2. 运行不需要搭服务器的第一版
仓库中的 examples/software-engineering 包含三个小文件：favorites.mjs 是规则，favorites.test.mjs 是检查，demo.mjs 是演示。安装 Node.js 24 后，在项目根目录运行：
node examples/software-engineering/demo.mjs
node --test examples/software-engineering/favorites.test.mjs
演示会依次打印保存后的一条记录、重复保存后仍是一条、取消后为空。这里的 article-1 是模拟 ID，不会向本网站发送请求，也不会修改真实收藏。
测试通过后，试着把第二次操作改成保存 article-2，应该出现两条。再把 saved 改成 false，观察它只移除对应 ID。每次只改一个条件，用输出确认你理解的是行为而不是代码外形。
3. 用一个小改动走完协作过程
假设新需求是“取消不存在的收藏也视为成功”。先看当前实现是否已经满足，再添加对应测试。不是每个新验收条件都需要改产品代码，有时只是把已有行为说清楚并固定下来。
给改动写一个明确提交，说明新增检查的理由。评审时让同伴只看需求卡与测试，先预测预期，再看实现。如果他理解成“取消不存在项必须报错”，说明双方契约还没有对齐，应先讨论，而不是继续写更多代码。
4. 走向真实网站时补上哪些东西
接入服务端后，需要把数组换成按用户持久化的记录。服务端验证身份、检查文章可访问性，数据库使用唯一约束防止并发重复，读取时按用户隔离。再把结果返回页面，处理保存中、成功和失败状态。
| 承诺 | 本地规则测试 | 真实接入后需要的证据 |
|---|---|---|
| 重复保存不重复 | 可以检查数组结果 | 并发请求与数据库约束 |
| 刷新后保留 | 不能证明 | 重新加载并读取存储 |
| 用户互相隔离 | 只能检查独立输入 | 两个真实身份的访问测试 |
| 网络失败正确提示 | 没有网络边界 | 受控失败下的界面验证 |
这张表的意义是防止过度解读测试结果。一个小示例可以教会规则与方法，但不应该声称自己已经提供生产认证和可靠性。
5. 准备一份可验收的交付包
至少包含需求卡、设计决定、代码、运行命令、测试结果和已知限制。对真实网站还要补目标环境、发布版本、数据变更和恢复方案。交给另一位读者，他应能知道从哪里开始、怎样判断结果。
若只是学习作业，不需要真的租服务器。可以用本地示例验证规则，再用纸面发布演练解释数据库迁移与回滚。明确哪些执行过、哪些只是方案，是工程表达的一部分。
6. 用反馈安排下一轮
试用者可能说“收藏太多，找不到”。先观察他如何查找，再决定加排序、筛选还是分组。不要因为教程里出现过某个架构名词，就把下一步定为拆微服务。新一轮仍然从用户问题开始。
练习与参考答案
提交一份不超过一页的交付说明，至少回答“做了什么、怎样运行、怎样验证、还不能做什么”。参考边界是：本地状态规则已验证；跨设备、真实权限、持久化和浏览器交互尚需在完整系统中实现和验证。这样的说明比笼统写“收藏系统完成”更可信。