面对陌生项目，从头通读所有类往往效率很低。选一条真实请求追踪，容易形成第一张系统地图。
本文使用Java Web 小项目的演示工程与协作场景。初入团队时，重要的不只是写出功能，还包括让别人能够复现、审查和接手。本文使用匿名任务说明工作方法，不指代某家公司的内部流程或真实交付成绩。
1. 从现象推到机制
从 URL（资源地址）找到控制器，再追业务服务、数据库访问和模板。记录输入如何转换、事务在哪里开始、异常在哪里处理。类名相似不代表同一职责，实际调用证据比目录名称更可靠。
图中的四个节点分别表示请求入口、业务服务、数据访问、页面输出。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
以只读查询为入口，先设置一个断点并观察调用栈。遇到框架代理时不要立刻展开全部内部实现，先把业务对象之间的关系画清楚。
1
2
3
4
GET /demo/orders
Controller -> OrderService -> OrderDao
OrderDao -> database
Controller -> model -> template
示例命令需要在独立演示工程中执行，路径和服务均由读者准备。操作前保留当前版本与输入，修改后对照原来的问题验证，而不是只证明新代码能够编译。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 同一服务有多个入口 | 需要检查是否共享相同规则 |
| 数据库结果正确而页面错误 | 继续检查模型与模板转换 |
| 异常在统一处理器被转换 | 客户端提示可能少于内部原因 |
对照 1：同一服务有多个入口
需要检查是否共享相同规则。观察时记录控制器与定时任务的调用路径。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：数据库结果正确而页面错误
继续检查模型与模板转换。观察时记录查询结果与渲染输入。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：异常在统一处理器被转换
客户端提示可能少于内部原因。观察时记录原始异常与最终响应。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
阅读代码不等于授权修改所有模块。先对一条链路建立可复现认识，再提出最小变更，能降低在未知边界上重构的风险。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“异常在统一处理器被转换”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
