工程取舍与学习自检：遇到新项目先问什么
学完一轮教程，最容易出现的新问题是：认识了很多方法，遇到项目却不知道该选哪个。软件工程不是把所有流程和工具都装上，而是根据目标与风险做有依据的选择。本章用几组情境检查你是否能把知识带到新的任务里。
1. 先看软件要活多久、影响谁
一个自己周末使用的小脚本，可以用简单输入和人工检查；一个长期保存用户数据的服务，需要权限、备份和运行观察。区别不只是用户数量，更包括错误后果、数据价值和后续变更频率。
第一次讨论项目时，可以问：谁会用？最重要的任务是什么？失败会造成什么后果？数据是否能重建？预计谁来维护？这些回答会影响验证投入和设计复杂度。
2. 不确定需求时先验证最贵的猜测
假设你不知道读者究竟需要收藏还是浏览历史。先做低成本原型，让他完成找回文章的任务。此时直接实现分布式收藏服务不能减少产品不确定性，只会让改变方向更贵。
反过来，如果需求清楚，但第三方服务能否支持关键操作不确定，就先做技术实验。两种探索回答不同问题：产品原型验证是否有用，技术实验验证是否做得到。实验代码是否适合上线，需要另行检查。
3. 用证据决定是否增加复杂度
当性能变慢时，先测量耗时在哪一段：网络、查询、计算还是渲染。慢在缺少索引的查询，增加更多应用实例未必有效。性能数字要附带测试数据量、环境和负载，不能只比较一次本机运行。
当多人协作困难时，先看模块职责和接口是否清晰。把模块拆成网络服务，并不会自动让职责变清楚，还会增加部署和调用失败的处理成本。复杂方案可以有价值，但需要针对真实瓶颈。
4. 做三轮自检
第一轮，用自己的话解释五个区别：需求与实现、认证与授权、提交与推送、部署与发布、重构与行为变更。每个区别都举收藏功能的例子，避免只复述定义。
第二轮，面对失败场景给出下一步：保存请求超时、旧客户端不能读新字段、重复请求产生两条记录、CI 偶尔失败、上线后数据丢失。先说明要收集的证据，再谈修复，不要对所有问题都回答“重试一下”。
第三轮，把一个陌生小功能按需求、设计、实现、验证、发布和维护走一遍。例如“给文章增加阅读进度”。先写刷新和跨设备行为，再考虑数据模型。能迁移方法，才说明学习不只停在收藏这个例子里。
5. 一个参考推理过程
遇到“收藏请求超时”，先区分客户端没拿到结果与服务端没有执行；读取当前状态并关联请求日志；确认重复请求是否安全；再安排重试或提示。这里不能直接断定保存失败，更不能无条件重复一个切换操作。
遇到“新字段上线后旧程序报错”，先看旧程序是否仍能读取当前结构，再决定回滚还是前向修复。恢复方案必须针对数据兼容性，而不是默认旧版本一定安全。
6. 接下来怎样学得更深
如果你想提高实现能力，继续学习一门语言与数据库，完成小型完整应用；如果经常改坏功能，深入测试设计与调试；如果上线问题多，学习发布工程、可观测性和故障恢复。按实际遇到的问题选择下一阶段，比同时打开十门课更容易形成闭环。
前端、后端和 Java 分区提供具体技术实践；Agent 开发分区还涉及模型不确定性、工具权限和评测。软件工程方法可以复用，但不同系统需要不同风险模型，不能把一个普通函数测试直接当成模型系统的全部评估。
练习与参考答案
给“阅读进度”列三个先问的问题。参考答案：按章节还是百分比记录？换设备时哪个进度为准？文章被修改后旧进度怎样解释？这些问题会改变数据与交互设计，因此应该先于选择缓存库或消息队列。