对于大部分项目来说，如果想做一点贡献的话，只要跑起来其实已经能找到能贡献的地方了。

引子

前阵子机缘巧合下接触到了 risingwave 在这之前我可以说是仅仅从几个在这工作的几个厉害的推友那里得知有这么一个用 Rust 写的流数据库，而流数据库是什么，到底什么原理，也仅仅是有所想象。既然是机缘巧合下了解到的，就试试去看看他的代码，去了解下它到底是怎么回事儿，顺便学点什么。

这里特别感谢下叉鸽。

正文

那么如何快速去切入一个项目呢？Cursor, copilot, marscode? No, 目前这种补全工具在做一个几千个人做过的 demo 里，是无敌的，但对了解一个大项目，甚至能给这个大项目提交一点代码修改一些 bug 的能力近乎于 0. （突然想到好久没有当时特别火的那个解决程序员问题的创业公司的信息了，留下了个 demo, 半年过去了）

既然这些不行，什么可以呢？根据我自己的经验步骤如下。

  1. GitHub Actions workflow 比文档要好用，对于一个 CI/CD 写的好的项目，我一般会直接点开 .github 下面的 workflow 如果这个项目很成熟，里面大概率会包括，如何编译，编译需要的依赖是什么？如何测试，需要的版本，不同环境需要安装的不同的包，都会在这个 workflow 里。看里面的 workflow, 然后根据步骤，编译，跑一些简单的命令，项目就跑起来了。
  2. 去扫一眼 good first issue, 点开 issues -> tag 筛选 -> good first issue, 去找一个一般 type 为 bug 的，然后结合第一步跑起来的，去把这个 bug 复现，OK 如果能复现已经实现了 1/3 了。
  3. 去 PR 里看看，一般一个正在发展的项目会有很多活跃开发者提的 PR, 而提 PR 一般需要做一些本地测试或者写好 pr messaage, 在里面会有一些开发者习惯的命令，比如 ./risedev c 可以在本地试一下。
  4. OK 有了这个 ./risedev 跑一下，就大概知道了开发者们常用的命令，本地都实验一下，大致就知道开发流程了
  5. 语言是 Rust 我也不会啊？没啥问题啊，既然能跑起来试试呗，去网页搜索 debug rust OK 学习到了和 C 语言一样可以用 gdb 而且有 rust-binding 可以用 rust-gdb, 去项目目录看到，有一个 .vscode 文件夹里面有如何用 VSCode debug 他们用的是 lldb, 我习惯命令行，再搜索下 lldb 也有 binding -> rust-lldb
  6. 能 debug 其实又完成 1/3 了，接上面的能复现的 issue -> 跑起来 -> 复现 -> ps aux| grep risingwave 去找到进程号，卧槽！这里好多进程号，两个方案，去按照文档 + issue 搜索去研究下大概应该哪个进程 or 一个一个实验。我都做了。明白了这个 bug 是在 front 进程 -> rust-lldb -p ${pid} 这个时候去研究下需要 break 的点，怎么研究呢？当然是看 log 啊！找到了 log(发现其中有个可以改进一点点的点）正好可以帮提个 PR, 找到 log 后大概率能拿到 backtrace 当然也可在 lldb 中用 bt 拿到 backtrack 之后就可以去 break 你想 break 的点了（这里因为 Rust 我不太熟悉，项目也太大，lldb 略卡，我选择直接 break 行号 b xxxxxxx.rs:41 另一个 terminal 跑 sql 再去 lldb 里一步一步调试就好了。
  7. 调试的过程中一点一点学习相关的知识，这个时候无论是 google ChatGPT 还是其它的都会派上用场了，哪里不会问哪里。
  8. 最有效的可能是 issues 和 PR, 有时候有问题不解对于一个成熟的开源项目来说可以直接去 issues 里搜索相关的关键字，然后大概率有 PR 的双向链接，点进 PR 看代码更改的 diff 学习下前面的大哥是怎么做的，能帮忙更好的定位问题。
  9. 尝试解决问题。
  10. 解决不了其实无所谓，因为经过了以上的步骤其实对项目已经有一点点了解了，这就够了，能学到一些东西就更开心了。

尾巴

  • 我的 PR
  • 为了解决 issue 一边学习 Rust 一边理解代码的流程提的 PR