接手了一个老项目，没有文档、没有测试、上一个开发已离职。数据库里几百张表，代码里大量存储过程。业务方只说要加一个小功能。第一周应该做什么？

第一周的核心目标：信息采集与风险评估

接手这种“三无”老项目，最忌讳的就是直接扑上去写代码。第一周的核心不是“加功能”，而是“摸清底细”。业务方说“小功能”，但老项目的改动往往牵一发而动全身。你的第一周应该聚焦在三个维度：业务逻辑、数据模型、技术债评估。

第一周行动清单

周一至周二：业务逻辑反推

不要先碰代码。找业务方拿所有相关的历史邮件、需求文档（哪怕只有几行描述）、操作手册。把当前系统的实际业务流程画出来——用纸笔或工具都行，重点是理解“用户到底在做什么”。如果可能，让业务方在你面前操作一次完整流程，录屏。这一步能帮你判断“小功能”是否真的小。

接着，花半天时间快速扫描数据库。不要看所有表，只看跟业务方说的功能最相关的几张表。用SQL查表结构、索引、外键关系。重点关注：哪些表是核心数据表（如订单、用户、产品），哪些是日志/配置表，哪些是无人问津的僵尸表。存储过程先别细看，但要用SHOW PROCEDURE STATUS之类的命令罗列一遍，标记出跟业务功能同名的存储过程。

周三至周四：代码考古与风险点标记

打开代码仓库，先看git log（如果有的话）。关注两点：最近三个月谁在提交、提交信息是否规范。如果没有任何版本控制，那么你面对的是最危险的情况——代码可能已经被多次直接修改。

重点阅读入口文件（如main、index、app等）、路由配置、核心ORM映射。不要逐行读，而是画调用链。比如：用户点击按钮 -> 哪个Controller接收请求 -> 调用哪个Service -> 执行哪个存储过程 -> 更新哪张表。把这条链上的每个节点都标记为“待验证”或“已知风险”。

存储过程尤其危险。找几个跟业务功能强相关的存储过程，用EXPLAIN分析执行计划，看是否有全表扫描、嵌套循环等性能隐患。如果发现存储过程里直接写了业务逻辑（比如计算折扣、状态判断），而代码中没有对应逻辑，这就是技术债炸弹，必须记录在案。

周五：风险评估与汇报

把这一周所有发现整理成一份“风险评估报告”，包含：

- 当前系统的核心业务流程图（你反推的版本）

- 数据库表关系简图（只画跟功能相关的部分）

- 识别出的高优先级风险（如：某存储过程用了游标循环10万行数据、某表没有索引、代码中硬编码了数据库连接密码）

- 对“小功能”的初步实施难度评估（例如：需要改5个存储过程、涉及3张表、业务流程需要改2个状态机）

这份报告不是给你自己看的，而是要跟业务方和你的直接上级对齐。告诉他们：“我完成了第一周调研，目前发现这些风险，建议我们先确认业务逻辑是否准确，再决定改动方案。如果直接改，我预估需要X天，但风险是Y。”

关键提醒

第一周结束时，你应该能回答三个问题：

1. 这个系统最核心的业务规则是什么？（用一段话讲清楚）

2. 要加的功能会触碰哪些“地雷”？（存储过程、无索引表、硬编码逻辑）

3. 如果现在就写代码，最可能出问题的点在哪里？

千万不要在第一周里试图优化整个项目。你的任务是“安全着陆”，不是“重建帝国”。等摸清底细后，再跟业务方协商：是先做技术债清理，还是先加功能。多数情况下，业务方听完你的风险评估后，会愿意给你额外时间做技术准备——前提是你用数据说话，而不是只抱怨“代码太烂”。

先读数据库表结构

再找核心流程代码

先跑通本地环境吧

第一周先不要动代码。花三天时间梳理核心业务流程，找业务方把关键功能走一遍。然后用两天画出现有表关系图，重点关注你要改动的模块涉及的10-20张表。最后两天搭建本地环境，确保能复现线上问题。记住，先观察再动手。

先理清业务流程，别急着改代码。

先跑通本地环境

先搭环境跑起来，别急着改代码。

先跑通业务流，理清核心表关系。