接手别人代码，先看这几个地方
我手上有一个自己立项初期写的项目，隔了两个多月回去改，读第一屏就开始皱眉。明明是自己写的，却像接手了一份别人的遗产，那一刻我才真在想接手别人代码怎么下手。
这跟作者是不是自己没关系，跟有没有留下线索有关系。下面这份清单，我既拿它看别人的代码，也拿它看三个月前的自己。
一、接手别人代码怎么下手：先看入口，别看细节
第一件事是找到程序从哪里开始跑。
不看清入口，你读到任何一段代码都不知道它在什么条件下执行。入口通常在启动文件、主函数或者路由注册处，找到它，整张图的起点就有了。
从入口往下读，比从随便一个文件往上猜，效率差很多倍。
具体动作：画出从入口到第一个业务处理之间的调用链条。
画不出来也没关系，画到哪算哪，剩下的空白正好是你还没理解的部分。
二、再看数据怎么进来、怎么出去
第二件事是找边界。
数据从哪些地方进来（接口、定时任务、消息），又写到哪些地方去（数据库、文件、第三方）。把这几个点标出来，你就知道哪些代码是核心，哪些只是中间过程。
具体动作：列出所有读写数据的位置，标一下哪些是入口、哪些是出口。
标完之后，你对「这个系统在干什么」就有了一个不依赖任何人解释的答案。
三、然后看配置和状态
第三件事是找「会变的东西」。
配置项、开关、环境变量、全局变量，这些是最容易在接手后踩坑的地方。同一个功能在不同配置下行为完全不同，而配置通常不在代码里。
很多「这代码怎么这样写」的困惑，答案在配置里。
具体动作：把配置项列一份，尤其是那些会影响主流程的开关。
列的时候标一下默认值，很多问题的答案就藏在默认值里。
四、接着找「不敢动」的那几处
第四件事比较特别：主动标出你不理解的地方。
接手代码最危险的不是看不懂，是以为自己看懂了然后动手改。我会在阅读时专门记一份「这里我不知道为什么」的清单。
具体动作：读的时候随手记下疑问点，先不解释，攒完再统一处理。
这份清单后来往往就是我的改造顺序——疑问最集中的地方，通常就是最该先动的地方。
五、最后找痕迹：注释、提交记录、待办
第五件事是找前人的线索。
注释里可能有「为什么这么写」，提交记录里可能有「当时是为了修什么」，代码里的待办可能是已知的坑。这些东西是花时间留下的，不用白不用。
但要注意：痕迹可能是过时的。看到一句旧注释，先确认它和现在的代码是否还对得上。
六、看懂了再动手，第一步改什么
我接手代码后的第一个改动，通常不是加功能，而是加一行能验证我理解对不对的东西——一个日志、一个断言、一次手工触发。
这一步的目的不是交付，是确认我脑子里的模型和真实运行的代码一致。
改对了说明你懂了，改错了说明你赚到了，因为这个错误现在暴露，比上线后暴露便宜太多。
优先级：这五步怎么排
如果时间有限，我的顺序是：入口 → 数据边界 → 配置 → 疑问清单 → 痕迹。
前两步做完，你就能回答「这个系统在干什么」；后三步做完，你才敢回答「我改了会怎样」。别跳到第五步，前人有痕迹不代表你理解了系统。接手别人代码怎么下手，说到底就是先建立理解，再动手。
常见问题
Q：接手别人代码怎么下手比较快？
A：从入口开始读，先把调用链和数据边界弄清楚，再看配置和全局状态。不要从一个随机文件开始逐行读，那样很难建立整体印象。
Q：接手代码要不要先写文档？
A：不建议一开始就写。先把理解跑通、改动验证过一轮，再写文档，否则写出来的多半是错的。
Q：看不懂的代码可以直接重写吗？
A：不建议。看不懂说明还有信息没掌握，重写会把这些信息一起丢掉。先记录疑问点，把能验证的小改动做起来。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」