社区 | 如何优雅降落到 TiDB 星球？

提到「开源项目 TiDB」人们老是习惯性反应：它在 GitHub 上 Star 数已经超过 17000，并拥有 260+ 位全球各地的 Contributors 。但数据总归是冷冰冰的，不能生动的展示 TiDB 社区的魅力。因此今天推送一篇 TiDB contributor 杜川同窗加入 TiDB 社区先后的「心路历程」，他从亲历者的角度告诉你——

• PingCAPer 够 nice 么？
• 积极参与 TiDB 社区对本身的能力提高有何帮助？
• 如何在 TiDB 星球上找到最适合本身的落点？（ 或者在大树上找到本身最擅长的“小树杈”hhhhhh）
• 以及…利用好碎片时间，你也能够一年给 TiDB 提 70 个 PR！

** 做者：杜川，TiDB contributor**

最近这一年多断断续续一直在往 TiDB 中提交一些修改，前两天看了一些 GitHub 提交记录，发现居然已经累计了 70 来个 PR 了。考虑到最近这一年基本处于疯狂加班的节奏，另外忙里偷闲还基本上刷完了以前列的十几本书的读书清单，我以为这也算一个不大不小的成就吧，值得 mark 一下。

话说回来，虽然我 17 年年中才开始给 TiDB 提交 PR，其实在以前一年多之前，大概在 2016 年 4 月份左右, 就据说过 TiDB 这个项目了。当时个人主要工做也是车一个 SQL 执行引擎，因此对分布式数据库业界的相关新闻仍是比较关注的。

虽然数据库是一个轮子高发领域，各类轮子五花八门，可是在国内，数据库，特别是分布式数据库这块的轮子，基本仍是几个大厂在车，要么不开源，要么开源了社区也不甚活跃。像 TiDB 这样要从头车一个分布式数据库，而且仍是彻底开源的方式来搞，确实让我印象深入。后来组里一个小哥离职投奔 PingCAP，我借着面基的名义陆陆续续参加了 TiDB 几回线下 Meetup，也由此认识了不少 TiDB 社区的小伙伴。

16 年末从北京回到成都之后，工做重心发生了一些变化，从以前的纯作 infra，转变为更多地要面对业务层面的需求。不过作了几年 infra，本身自己对数据库内核仍是很感兴趣的，因此工做之余，开始研究 TiDB 的实现，而且搭了一套 TiDB，在开发环境里代替 MySQL。咱们都知道，MySQL 通过多年的发展，其 SQL 语法是比较复杂的。TiDB 虽然全面兼容 MySQL 的语法和协议，可是由于没有复用 MySQL 代码，确定不可能作到 100% 兼容，落实到一些具体的语句上，确定会和 MySQL 有一些区别。由于以前我也一直在作 OLAP 系统的 SQL 引擎的开发工做，对这一块比较熟悉，在遇到这方面问题后，感受解决起来也并不很麻烦，所以慢慢开始在这个方面给 TiDB 提一些 PR。到后面熟悉了之后，有时间的话也会到 TiDB 的 issue list 上捞相关的 issue 解决，主要集中于 SQL Parser, 表达式计算和 MySQL 兼容性等方面。最近抽空在作的是和聚合函数相关的一些 Feature。

由于平时工做仍是比较忙，加班也是屡见不鲜，所以给 TiDB 提交 PR，回复 Review 意见的时间段基本都集中在周末，晚上老婆睡觉之后，或者午休间隙。这样有一个问题是时间段比较离散，很难有长时间的连贯思考的时间。所以现阶段一方面我在提 PR 的时候会选择一些相对较小，独立一些的 Feature。另外一方面，我尽可能把开发放在时间相对充裕的周末，把晚上和其余零碎时间用来查看和回复 Review 意见，Update 代码和跑回归测试。这样算下来，平均提交一个 PR，算上开发，测试，和社区小伙伴沟通，大概要消耗 3 到 5 个工时。

不过这个时间投入我以为却是很是划算，一是由于我自己对数据库就很是感兴趣，把参与 TiDB 社区开发当成了一种兴趣，能够看作是工做之余的一种放松，二是我一直在从事数据库相关的工做，包括以前 OLAP SQL 引擎的运行时优化相关工做，和如今云数据库相关的工做，其实和在社区所作的事情都是密切相关的。好比一个 MySQL Builtin 函数, 在各类极端输入下的表现是怎样的，或是 SQL_MODE 的各类组合对这个 Builtin 函数的行为有什么样的影响，这些问题在平时工做中，我可能很难考虑得很是周全；可是要在社区中提一个 PR 实现这个 Builtin 函数，我就非得把这些问题考虑清楚，并经受社区小伙伴各类 Case 的轰炸考验。等这个 PR 顺利被 Commit，这些细节我也烂熟于心了。

说到社区，我以为 TiDB 作得至关不错。一方面 PingCAPers 都很活跃，在 GitHub 上提的 Issue 通常很快就能获得回复, 有什么疑问经过 GitHub, 微信群甚至知乎提问等很快都能获得反馈；另外一方面更重要的是在 Review PR 的时候社区小伙伴能保持比较严谨的态度。

就个人经历而言，我在开发过程当中没有注意到的一些 Corner Case 和细节错误，基本都能在 Review PR 过程被翻出来，这不只须要 Reviewer 理清楚 PR 对应 Feature 的相关细节，构造出可能有问题的场景，还须要 Reviewer 理解 PR 做者的开发思路。其中须要花费的精力，经常不低于开发这个 Feature 自己。此外，还有一个我以为很赞的方面是 TiDB 花了不少心思来构建从 UT，FT 到集成测试的一系列测试框架，让我在参与开发工程中比较容易对本身开发的 Feature 进行各个方位的测试，节省了不少来回捣腾的麻烦。

总的来讲，参与 TiDB 社区是一件很是有意思的事情，给我带来不少收获，我也会继续关注 TiDB 项目的进展。短期来看，个人计划主要仍是抽空完成手头聚合函数相关的一些 Feature，包括对 MySQL 聚合函数 STDDEV，VARIANCE 等的支持，以及在 TiKV Coprocessor 侧的对应改动。以后，我打算看看能不可以结合我以前在 OLAP SQL 引擎的运行时优化方面的经验，提高 TiDB 在 OLAP 领域的能力。不过这个是一个比较大的目标了，到时候还要和社区的小伙伴多多讨论。

TiDB 社区大事件

TiDB TechDay2018 即将于 7 月 28 日在深圳举办，目前报名已满，咱们周六见哦！点击【这里】查看活动详情。P.S 欢迎踊跃勾搭 TiDB Robot （微信号：tidbai）加入 TiDB 星球～