伊洪：GitHub 是我的社交方式 ｜ nStar 专访

自 19 年开源到现在，NebulaGraph 社区出现了一群有想法、有实力的用户，将他们的优雅留在 NebulaGraph 的代码中，他们是 nStar，是 Nebula 社区不可或缺的一部分。

—— Nebula 社区

一名在二线城市开启 Work/ Life Balance 模式的程序员，他并非科班出身，从机械工程师到游戏策划，再是数据分析师，最后成为一名程序员，这一路他慢慢走来，在 GitHub 上结交了志同道合的技术朋友，也通过将他的兴趣爱好——跑步数据记录工具开源（目前标星 1.3k），被更多人所知。

GitHub 记录了他的技术成长，也记录着他的生活点滴。我愿意称他为一个“活”在 GitHub 的人，而 GitHub 则是他同他人社交的方式。

他是伊洪。

这是伊洪

图注：正在跳动的心脏是他的一个开源项目

他的非程序员面

清蒸（下简写：Q）：从最开始我认识你，是在 fo 人的点赞信息流。有段时间，信息流频繁出现某个疑似妹纸的跑步记录，随后关注了你。在 GitHub 上，你也为「跑步」这件事单独开了个 repo 记录自己跑步旅程。同时，也提供给其他跑步爱好者来记录他们的旅程。所以，你开启跑步旅程，是有什么故事在里面吗？据我所知我的很多朋友都是出于健身（瘦身）的目的开始跑步，然后爱上跑步这件事。

伊洪（下简写：Y）：其实跑步这件事，我持续好多年了，断断续续地跑了 20 多年。真说有什么故事的话，其实是小时候我比较爱生病，小学二年级有一天，我妈就开始带我早上跑操场，然后初中也跑，高中也跑，学校运动会也各种长跑，然后大学也在操场跑，断断续续地一直跑到现在。最长的单次跑步里程，可能是参加的马拉松了，42 公里。这 20 多年我也参加过几场马拉松，像是大连的、扬州的、北京等等城市的马拉松。

在 2012 年的时候，手机有了 GPS 功能便开始记录自己跑步的曲线里程。你看我跑步数据也能看出来，我跑步经常就是停一段时间，完了再捡起来跑，也不是一直每天都坚持跑。但是基本上每年都会跑，平均一天能跑三公里，整个平均下来。（伊洪开源的供跑步者记录里程的 GitHub repo：https://github.com/yihong0618/running_page）

跑步这件事除了给我带来了“健康”，忍耐力可能是另外一种所谓的价值了。比如说，跑马拉松能花 4 个小时，最大的帮助是什么呢？你无论干什么，大概都能跑能忍耐 2 个小时到 4 个小时无聊的时间，说白了，就比别人能忍受无聊一点。以及就是你说到的“健身”，持续地跑步的好处在于即使有一段时间我不跑了，再捡起来会非常容易，因为你知道怎么循序渐进地训练，如果说有一天我胖了，胖到 180 斤，但是因为我一直在跑步，我知道怎么去循序渐进地一点一点加训练量，通过每周跑一次长期距离，最后让自己再瘦回去。

这里要和刚开始跑步或者跑步没多久的社区小伙伴说下，跑步其实对膝盖（半月板）是有一定程度的损伤的，所以有条件的话，尽量去操场跑可以保护好自己，一双好鞋也是必须的。刚开始跑步的时候，我还会买贵一点，1k 多的跑鞋，太费鞋子了。后来，只要不参加马拉松，不以马拉松为目标，每次跑 3~5 公里或者 5~10 公里的时候，我就买打折后 200 多块钱的跑鞋。

Q：在你的 2020（GitHub：https://github.com/yihong0618/2020）和 2021（GitHub：https://github.com/yihong0618/2021）中，罗列了下厨烹调的各类食物。在我看来程序员是一个和“厨艺”比较难关联上的职业，毕竟“厨艺”需要大把的时间，在这里你有什么快手菜、烹饪小技巧、调料清单可以推荐给其他的 Nebula 社区小伙伴，让他们加上“厨艺”这个 tag 吗？

Y：快手菜的话，我这边大概会推荐油焖大虾。一，虾相对容易熟。二，油焖大虾你可以先把所有的调料放在一个碗拌匀了然后加点淀粉，一起倒进去，快速地炒下然后锅盖闷一下就行。然后烹饪技巧的话，最近研究出来一个做青菜的时候，蚝油是个好东西。蚝油的使用方法你可以先把油热了之后再倒蚝油，再下青菜，蚝油味道激发出来之后就会很鲜，最后再放蒜蓉。

Q：你的业务生活如此多彩，是如何做到工作和生活的平衡的，感觉你的 24 小时和我们的 24 小时不是一个计时方式。

Y：其实，在于一点吧，其实我不是一个特别 social 的人。你看其他的程序员会混迹各种社群，然后线上和线下 social，其实我基本上除了必要的公司团建，team building 之外很少会出去 social，整个来说工作之余的所有时间都是自己的个人时间。而我的 social 方式也就是给 GitHub 项目提一个 pr，或者 comment 之类的，以大家熟悉的代码形式来交流。

他的程序员面

Q：在你的年度计划和回顾中，其实你是阅读过大量的前端、后端的知识，这块是出于自己自身的某个业务需求还是纯粹好奇想了解下某块内容呢？你是如何系统化地学习、掌握某块技术的呢？技术如果不应用在特定的场景，感觉学习完容易被遗忘。

Y：其实我非科班计算机生，最开始我是一名机械工程师，然后做过一段时间的游戏策划，然后是数据分析师，最后是程序员。做数据分析师的时候，会写一些 Python 脚本，一些 SQL，发现：诶，我好像可以干程序员，就慢慢地转到程序岗位上了。

说回学习路径话题，我最开始是看书，后来的话主要是在项目中学习技术。比方说，我会突然有个灵感，这个项目缺什么知识，我就会主动去学习，这个过程中你可能需要补一些底层的知识，前面我也说了我是慢慢地转到程序员这边的。毕竟非科班，好多底层的知识要不懂的话，会对你的代码速度或者查询速度、项目结构，会带来一些问题。就在一个个项目从零到有的开发过程中，知道大概程序是怎么回事，真正地从中成长起来。

Q：像你在《力扣的程序是如何运行的》（GitHub issue：https://github.com/yihong0618/gitblog/issues/205）中，通过一个群友他有个地方 typo 把小写的 l 写成大写的 L，LeetCode 竟然能编译通过这件事，抽丝剥茧发现当中它的运行机制，和我司的研发同学之前写的《记一起由 Clang 编译器优化触发的 Crash》有异曲同工之效，都能从小细节看到程序的有趣之处。你有什么有趣的代码片段或者调试经历可以分享下吗？

Y：我前一阵子因为写跑步程序（GitHub：https://github.com/yihong0618/running_page），做了好多相关逆向工作，这个过程中感觉各个公司对程序处理的逻辑还挺有意思的。拿某款运动类 App 为例，App A 和 App B 当中的逻辑非常相似，深入去了解它们为何如此相似，你就会发现原来 A 的架构师原来是从 B 过去的，程序员的自身痕迹就以代码留在产品，让其他用户感知到了。

生活在 GitHub

Q：用生活在 GitHub 来形容伊洪，我觉得是非常恰当不过的，日常的碎碎念，偶尔闪现的代码灵感，都在 GitHub 上记录着。在你看来，如果你根据自己的使用习惯，来给 GitHub 下个定义是什么？

Y：它是一个对我来说是社交软件的存在，因为能遇到很多有意思的人，它已经不光是一个代码平台了，上面有意思、感兴趣的项目让我可以参与进去。

此外，我也用它来记录我日常的生活和技术思考。因为在我刚开始记录生活和工作的时候，也没思考过平台问题。直到有一天我看到过一个程序员 like9m 的一篇博文：People Die, but Long Live GitHub（链接：https://laike9m.com/blog/people-die-but-long-live-github,122/），这篇文章对我的感触很深——无论你之前是发过微博，还是说假如你使用过校内网，在上面写过一些日志，这些东西都会不见。一个网站挂了，或者背后的公司没了，你写的东西也没了。这篇文章主要就是谈什么东西能存在 100 年以上呢？当中举例了很多东西，在我们认知内能存在上百年的。刚好那时候 GitHub 也出了一个冰山计划（冰山计划科普传送门：https://archiveprogram.github.com/）也算是个契机吧，我把所有的东西都搬到了 GitHub，日常的碎碎念和零碎的技术思考都放到了 GitHub 上。

刚开始的时候是一个私有仓，后来觉得开源出来（public）也没有什么，大家还可以基于我的使用方式来生成自己的一个目录，还挺有意思的。然后一直持续到现在，我的日常输出和记录都在上面，然后再通过 issue 来和其他人互相交流。

Q：你的 GitHub 贡献墙让人惊艳，你是如何看待开源，和其他开源社区用户交流这件事呢？什么你觉得可以分享的贡献 pr 的小 Tips 吗？

Y：其实刚开始在 GitHub 做贡献的时候，我也不大懂玩法，第一个大 pr 就是哐哐哐地写了一堆东西然后就往某个项目里提 pr。但项目维护者是一个德国人，人非常好，虽然一开始没接受这个 pr 但鼓励我继续做下去，最后这个 pr 被 merge 了。

随着贡献的积累，我慢慢知道了，有些 feature 是作者（维护者）不想要的，因为每一个项目 roadmap 里都有作者的规划，或者说作者想怎么做这个东西。所以说，涉及到大的 feature，你最好先提一个 issue，你想贡献一个 feature，可以先开一个 issue 和作者讨论下，看他是否需要这个功能，这样也可以避免了你做了贡献却被对方“伤害”了感情。如果作者不想要这个 feature 的话，你可以做一些别的贡献，自己 fork 下来，用自己的方式实现也是可以的。

懂了玩法之后，我提 pr 之前会看下有没有对应的 issue，如果没有的话我会提一个，然后看看作者怎么回，如果作者觉得这个有用就继续。就像我给 Nebula 提 pr 一样，我会先提一个 issue 看你们需不需要，可以不可以加个 add requirements.txt（issue 传送：https://github.com/vesoft-inc/nebula-python/issues/105）。然后 Nebula 的研发同学就说可以，那我就加上，直接提了个 pr。

当然一些小的 typo 之类的，就不需要提 issue 了，直接提个 pr，如果 typo 影响面比较广的话，作者也会立马 merge。

说个题外话，其实日常 issue 中也会遇到一些其他社区用户参与讨论，但是其实整个项目规划还是由作者来主导的，所以其他人的思路和你是否一致这时候就显得并不是很重要，但是有讨论总是好的，我也遇到过一个情况，大家讨论完了之后发现，诶，还是你这个方案比较好，最后采用了我的方法。所以整个来说，GitHub 上交流的话，更多的是和项目作者或者说是背后团队在交流他们的规划。

对话 Nebula

Q：最后，当然是和 Nebula 说些啥，你有什么提 pr 体验、社区体验优化的地方愿意说下的吗？

Y：这块的话要说下 PingCAP 了，Nebula 现在的社区是人对接，TiDB 已经实现了全部的机器人对接，比如你提一个 pr，立马会有个机器人说你该做什么怎么做，如果你代码有问题的话它也能立马给你检查出来，包括 pr 合并也是自动化实现的。

再比如说，你需要一个对比或者测试，你直接在 pr 的 issue 里 at 机器人，它就会自动帮你把这块东西给做了，非常的自动化。机器人跑完之后，那边会有一些人和你对接，人 + 机器的结合就能带来非常好的 pr 体验，这块的话，不光是国内，国外而言也算是做得非常好了。

以上为第 96 位 contributor 伊洪的专访，更多 Contributor 及社区活动见 Nebula Community 仓