01《代码阅读》

核心痛点
拿到一个陌生开源项目或接手遗留系统，打开文件夹看到成百上千个源文件，第一反应是“从哪个文件开始看？”多数人的本能是找main()函数然后逐行往下读，结果陷入无穷无尽的函数调用迷宫，三天后彻底放弃。
底层逻辑：阅读不是“看”，是“建模型”
Spinellis的核心观点振聋发聩：代码不是小说，阅读代码是一种主动的“假设-验证”游戏。你的大脑不是用来存储代码行的，而是用来构建心理执行模型的。每读到一段逻辑，你都要在脑中问：“如果我是CPU，执行到这里，内存状态变成什么样了？”读代码的真正产出，不是记住了多少行，而是你脑中那张运行时数据流图是否清晰。
五大实操战术（按优先级排序）
战术一：自顶向下画“地形图”
打开项目，第一件事绝不是看.c或.java，而是：
读README、INSTALL、CHANGELOG —— 了解项目定位和版本演进。
看顶层目录结构（src/、include/、test/、doc/），用tree -L 2输出目录树，用笔圈出核心模块（通常命名最抽象、最贴近业务的名词）。
读Makefile或CMakeLists.txt或pom.xml —— 这些构建脚本暴露了编译顺序和库依赖，依赖链就是阅读的“高速公路”。
战术二：自底向上抓“数据核心”
找到核心模块后，不要看函数，先找数据结构（C的struct、Java的class成员变量、Go的type struct）。数据结构是系统的“骨架”，函数只是操作骨架的“肌肉”。把核心结构体的字段一个个查清楚（尤其是指针/引用字段，它们揭示了对象间的关联），这一步做好，你已经读懂了系统一半的设计意图。
战术三：追踪“一次完整请求”的调用链
选一个最典型的业务场景（比如HTTP服务器的“处理GET /”），用grep -rn "GET"找到入口函数，然后用IDE的“查找调用者”和“跳转到定义”功能，手工在纸上画出调用栈（深度控制在3-4层）。千万不要一次性追到底——先画主干，再把叶子节点记下来留待以后填充。
战术四：重点狙击“异常处理”和“日志”
正常路径的逻辑往往被过度设计模式包装得晦涩难懂，但异常处理分支if (ret < 0) 和 catch 块里，往往藏着最直白的、最接近业务约束的判断条件（如“磁盘满”、“权限不足”、“超时”）。同时，搜索printf、LOG_INFO、console.log，日志字符串是人类语言，能秒懂该模块在业务链路中的“前后邻居”。
战术五：利用“注释考古”降低认知负荷
先忽略描述“做什么”的注释（代码本身已经说了），只高亮标记“为什么（Why）”和“边界条件（Edge case）”的注释。例如注释写着// 此处不能使用快速排序，因为输入可能包含大量重复元素，这就是作者给你的“作弊纸条”。
经典案例实操
假设要读Redis源码。第一步：看src/下的文件命名，server.h、db.c、networking.c —— 立刻锁定server.h（核心数据结构全局大本营）。第二步：打开server.h，找到struct redisServer，里面几百个字段看似吓人，但注释把port、dbnum、clients等核心字段解释得清清楚楚。第三步：用git log --oneline src/server.c看提交热度，发现processCommand函数被改了几十次，这就是核心入口。第四步：追踪processCommand如何调用lookupKey读数据、如何调用call执行具体命令。三小时内，Redis的主流程已在脑中跑通。
金句摘录
“读代码时，如果你无法在5分钟内说出‘这段程序读取什么输入，产生什么输出’，说明你还没找到正确的入口。”