写在前面：
项目是 : greptimedb
它是一个时序数据库，官方介绍是：
化繁为一的可观测数据库，OpenTelemetry 原生、云原生的可观测数据库，实时处理指标、日志和链路追踪数据 — 在任何规模下提供亚秒级洞察。
我一共给 greptime 提了 51 个 Pull Request 被 merge 了 44 个，在所有贡献者里目前排第 20.
不过最后一个契机是某一天有人在 LinkedIn 上关注我，我点开一看是 Greptime 的 CEO 正好我想学一学 Rust 便又点开了这个项目。
第一个 PR 是没有成功合并的，我特别喜欢从 bug 入手一个项目，在 bug 中管中窥豹来了解一个项目的全貌，
那时候正好有这么一个 issue, 我去尝试解决了下，发现不太难，但是由于设计的问题最后没有合并，但尝试修第一个 bug 的过程中
我学到了：
make help 应该怎么写怎么用，给我后面打 TiDB 提的一个 patch 打了基础想给开源项目贡献并不难，只要项目成功跑起来，就知道如何贡献了。
嗯上面是我说的，于是就有了
在尝试做第一个修复的过程中发现了 make fmt 异常的慢，我不太理解，仔细研究了一下代码。嗯，是 python 我比较熟。
从 40s 提高到了 4s 这个贡献并不难，我们都可以做，甚至在今天，AI agent 直接做的比我还好，我们在 LLM 时代更
需要一个发现问题的眼睛了～
从这 patch 中我学到了一些 rust cargo 生态的一些 check
因为懂一点点 pg 我又去尝试修复 bug 了但是这个是一个需要巨大工作量的修复（后来我才知道）
这个 patch 也是我给 greptime 贡献的第一行 rust 代码，从这个 PR 里我学会了如何给 greptime 加测试
在我尝试修复另一个很久以前的 bug 的时候发现的 bug, 还挺有趣的顺便尝试修复了，从中我学到了怎么处理 Rust
panic 的一些技巧
因为 @Xuanwo 的 OpenDAL 发现 greptime 用的也是 opendal 就去学习里面的代码了，发现有个 useless import 给删除了
其中的一条评论很有趣
LGTM. Why does cargo check or clippy is not reporting this?
通过这条评论我又学习了 cargo check 是无法准确的报告一些 useless code 的，那么有没有可以的呢，学到了新的一个 static check
于是有了下面一个 patch
再之后我想了，既然 rust 的机制已经保证了很多的安全性，那么能不能更安全呢？于是去查到了 rapx 这个项目，这应该是我见到的最牛的几个 static check 项目之一（后面因为 check greptime 我还有机会给这个项目提了个 patch）
因为 rapx 我贡献的几个 patch:
之后是一些常规的修复也水了一些 patch
三个我比较自豪的 patch
我从中学到了很多 perf 技巧，尤其是之前在 gp 的时候只听同事讲过优化器 fast path 我通过其中的一个 patch
才真正的明白了一点点数据库的优化。
还有一个是算法的重要性，我只是优化了几行代码就能提高 10 倍的性能理解了 O(n) O(...) 不是只有 LeetCode
后面因为学会了一点点 Rust 又去给 OpenDAL 贡献了不少代码，理解了 OpenDAL 后又返回来给 GreptimeDB 贡献了个小的 feat
再后面就是遇到啥好玩的，发现 greptime 可能有用就顺手贡献一个。
学到了新的东西，认识了新的朋友，就更有趣了。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。