作为一个程序员,怎么读源码或是别人的代码呢?

读源码和读别人的代码，都要带有明确的目的性。

读源码，是为了提升自己的编程水平，你就不会觉得枯燥。

读别人的代码，是为了增加自己对项目的掌控力度，你就不会觉得别人的代码都是垃圾。

所以读代码的前提是目标明确，其次是心态，要有一颗学生的心态，摄取代码中的精华为我所有，最后就是输出，确定性的输出，不要忘记你读代码的目的，为了提高项目的掌控那就输出一份自己理解的代码功能图，目的是下次不再读这份代码，遇到问题能快速定位，目的是提升自己的研发水平，那就自己重写里面的核心代码，并总结提升自己。

那具体该怎么办呢？有个前提，前提是你得有一定的编程基础，不要以上来就读代码，那样只会让你更焦虑。

我编程 20 多年，在我看来读代码就 4 步：先画图再看代码，先跑起来再读逻辑，先走主路径再抠细节，先读懂再重写一遍。少一步都不行，顺序反了更不行。

这看起来简单，但那是我踩了好多坑才总结出来的经验。

接下来，以 LevelDB 为例，说明一下源码该怎么读。

一、先画图，别急着钻代码

读源码之前一定要先找文档、看文档，这步能省掉你 80% 的摸索时间。

看文档的优先级：架构设计文档 > 接口设计文档 > README > Wiki > 代码注释。

有流程图、时序图、模块关系图的文档，价值最高。

拿到源码后，先花半天过一遍文档，然后要画模块关系图、核心业务流程图、关键数据结构图。

有了这个三张图，你就能项目的是骨架，搞清楚骨架，代码逻辑就明白了一大半。

拿 LevelDB 举例，说明这三张图该怎么画。

先看目录结构：

leveldb/├── db/          # 核心数据库逻辑：读写、compaction、版本管理、MemTable├── table/       # SSTable的读写实现├── include/leveldb/  # 公开头文件——这就是最好的文档入口├── util/        # 工具类：编码、哈希、日志，以及env（文件操作、线程）的平台抽象实现├── port/        # 平台相关的原子操作和线程实现├── doc/         # 内部设计文档├── helpers/     # 内存数据库等辅助实现└── benchmarks/  # 性能基准测试

模块关系图就出来了：db/是核心，包含了 MemTable、Version、DBImpl 等关键组件，依赖table/做 SSTable 存取，依赖util/做编码、哈希和平台抽象。include/leveldb/是对外暴露的API。

然后看include/leveldb/db.h，这是 LevelDB 的公开接口：

classDB {public:static Status Open(const Options& options, conststd::string& dbname, DB** dbptr);virtual Status Put(const WriteOptions&, const Slice& key, const Slice& value)= 0;virtual Status Get(const ReadOptions&, const Slice& key, std::string* value)= 0;virtual Status Delete(const WriteOptions&, const Slice& key)= 0;virtual Iterator* NewIterator(const ReadOptions&)= 0;};

关键数据结构图也有了：LevelDB 的核心是DB接口，实现类是DBImpl。DBImpl内部持有MemTable（写缓冲）、Version（当前版本的SSTable集合）、WAL（预写日志）。写请求的路径：Put → Write → WAL → MemTable。读请求的路径：Get → MemTable → Version::Get → 逐层SSTable查找。

核心业务流程图：写操作先写 WAL 保证持久性，再写 MemTable；MemTable 写满后变成 Immutable MemTable，后台线程将其 dump为SSTable；SSTable 层数过多时触发 compaction 合并。这就是 LSM-Tree 的完整流程。

你把这三张图画完，还没看一行.cpp代码，就已经对 LevelDB 的架构心中有数了。

没有文档怎么办的话，那就自己补足，尤其是看公司前辈的源代码，你可以通过注释，接口把核心逻辑梳理出来。你的这个动作本身就是读代码最有价值的一部分。

其实作为 C++ 项目来说，头文件就是最好的文档。先通读头文件，比直接看.cpp效率高得多。

具体的做法是，先看公开 API 的声明，搞清楚这个类对外暴露了哪些能力；再看成员变量，理解它的状态模型；最后看私有方法和内部类型，留到后面再读。

二、跑起来，用调试器走一遍

代码跑不起来，你就没法读。

搭环境这步不能省。哪怕花一周把项目跑起来，也比花一周对着代码发呆强。

拿 LevelDB 举例，怎么搭环境、怎么跑。

git clone https://github.com/google/leveldb.gitcd leveldbmkdir build && cd buildcmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ..cmake --build .

注意-DCMAKE_BUILD_TYPE=Debug，必须用Debug模式编译，否则调试器看不到符号。-DCMAKE_EXPORT_COMPILE_COMMANDS=ON给Clangd用。

然后写一个最简单的测试程序：

// test_read.cpp#include"leveldb/db.h"#include<iostream>intmain(){    leveldb::DB* db;    leveldb::Options options;    options.create_if_missing = true;    leveldb::DB::Open(options, "/tmp/testdb", &db);    db->Put(leveldb::WriteOptions(), "hello", "world");std::string value;    db->Get(leveldb::ReadOptions(), "hello", &value);std::cout << value << std::endl;  // 输出 worlddelete db;return0;}

用调试器跟踪 Get 操作的完整链路：

DBImpl::Get  → current_->Get     → mem_->Get    → imm_->Get    → version->Get      → ForEachOverlapping        → TableCache::Get          → Table::InternalGet            → Block::Iter::Seek

这一趟走下来，你比看三天代码深入的多。

你亲眼看到了数据在各个组件之间的流转，哪个先查哪个后查，查找失败怎么跳到下一层，这些细节光看代码很难串起来。

调试器里有两个操作一定要熟练：条件断点和观察点。

条件断点让你在特定条件下才停下来。观察点让你监控某个变量的变化。这两个功能在读大型项目时能帮你过滤掉 99% 的无用中断。

加日志验证理解。

在DBImpl::Get的关键分支加几行日志，看看 Get 操作到底走了 MemTable 还是 SSTable，结果可能和你想的不一样，新建的数据库，数据还在 MemTable 里，根本没落盘到 SSTable。这种认知靠静态分析得不到，必须跑起来看。

三、沿主路径走，别一上来就深入细节

有了文档做地图，有了运行实例做锚点，该深入代码了。

读代码的顺序很关键。

不要上来就从main函数开始一行一行看，那样只会让你越来越晕，要从业务入口函数开始，沿核心调用链往下追，只看主路径，先忽略异常处理和边界条件。

拿 LevelDB 举例，追踪 Write 操作的主路径。

起点是DBImpl::Write，进入实现，以下为简化版，去掉了部分错误处理，保留主路径。

Status DBImpl::Write(const WriteOptions& options, WriteBatch* updates){Writer w(&mutex_);    w.batch = updates;    w.sync = options.sync;    w.done = false;MutexLock l(&mutex_);    writers_.push_back(&w);       // ① 写请求入队while (!w.done && &w != writers_.front()) {        w.cv.Wait();              // ② 等待成为队首    }if (w.done) { return w.status; }    Status status = MakeRoomForWrite(updates == nullptr);  // ③ 确保有空间uint64_t last_sequence = versions_->LastSequence();    Writer* last_writer = &w;if (status.ok() && updates != nullptr) {// nullptr batch是后台compaction用的，不走正常写路径        WriteBatch* write_batch = BuildBatchGroup(&last_writer);  // ④ 合并写请求        WriteBatchInternal::SetSequence(write_batch, last_sequence + 1);        last_sequence += WriteBatchInternal::Count(write_batch);        {  // ⑤⑥ 写WAL和MemTable，期间释放锁允许并发读            mutex_.Unlock();            status = log_->AddRecord(WriteBatchInternal::Contents(write_batch));if (status.ok() && options.sync) {                status = logfile_->Sync();  // 注意：是logfile_不是log_            }if (status.ok()) {                status = WriteBatchInternal::InsertInto(write_batch, mem_);            }            mutex_.Lock();        }if (write_batch == tmp_batch_) tmp_batch_->Clear();        versions_->SetLastSequence(last_sequence);    }// ... 唤醒其他等待的Writerreturn status;}

一个 Write 操作「入队→等待→腾空间→合并→写WAL→写MemTable」有 6 步。

⑤⑥两步：写 WAL 和写 MemTable 时，锁被主动释放了。

这个细节，你光看代码时很容易被漏掉的，但在调试器里，你单步执行时，一览无余。

每一步你都可以继续深挖，比如第③步MakeRoomForWrite，跳进去看会发现它判断 MemTable 是否写满，写满了就触发 compaction。但先别深挖，把主路径走完再说。

用 git blame 追踪代码演变。

git blame -L 300,320 db/db_impl.cc

你能看到提交时间和作者。通过 git log 追踪提交历史，能发现某些关键优化是在什么场景下引入的。理解了演进历史，你就不会觉得代码复杂，而是明白每个设计都有其背景。

读模板代码的方法。

C++ 项目里模板代码是最难读的部分。我的做法：先找到模板的一个具体实例化，把模板参数替换成具体类型，当普通类来读。

理解了一个实例化，再回头把参数抽象回来。C++20 的 Concepts 也让模板的约束更清晰，先读requires子句，再读实现，约束会告诉你这个模板期望什么、不期望什么。

我研究一行代码，最多 10 分钟，超过 10 分钟搞不明白就标记下来继续走。等主路径走完了回头再看，大部分标记点在理解全局之后一看就懂。

四、重写一遍，才知道自己懂没懂

读懂不等于学会。

无数程序员都有一个错觉，那就是看了别人的代码，就觉得自己也行，等真动手要写的时候啥也不是。

拿 LevelDB 举例，怎么重写验证。

读完 LevelDB 的BlockBuilder，你可以试试自己也写一个：

classMyBlockBuilder {std::vector<std::string> keys_;std::vector<std::string> values_;public:voidAdd(std::string_view key, std::string_view value){        keys_.emplace_back(key);        values_.emplace_back(value);    }std::stringFinish(){std::string result;for (size_t i = 0; i < keys_.size(); ++i) {// 你的朴素实现：每个key完整写入            result.append(keys_[i]);            result.append(values_[i]);        }return result;    }};

写完和 LevelDB 对比一下，你会很有收获。

然后你用 LevelDB 自带的测试验证：BlockBuilder 的测试在table/table_test.cc里，把你的MyBlockBuilder替换进去，跑测试看哪些用例过不了。过不了的地方，就是你理解不到位的地方。

重写不是目的，理解设计取舍才是。

C++ 项目里性能差距往往来自三个地方：内存布局、分支预测、编译器优化。

对照这三个方向分析，你的收获比盲目优化大得多。

把学到的设计迁移到自己的项目里。

这才是读源码的终极目的。在 LevelDB 学到了前缀压缩，能不能用在你的网络协议序列化里？学到了 WAL 先写日志再写数据的模式，能不能用在你的订单系统里？

读源码不输出，等于没读。

目的不同，输出的形式不同：为了掌控项目，输出功能图和架构文档，下次遇到问题快速定位；为了提升水平，重写核心代码，写博客写笔记，把理解变成可复用的能力。

你不要担心出错，怕就输了。你得有方法，有目标，有输出。

先画地图，再跑起来，沿主路径走，最后重写验证。四步走完，读源码这件事，你就不再怕了。

如果你觉得这篇有用，那就给个点赞收藏吧！！！