开源实习的 4 个重要教训

如果你碰巧有一台时光机，并选择把自己射回一年前，问问我对开源贡献的看法（在所有你可以做的事情中），你可能会猜到我只会耸耸肩，说一些类似这样的话：“我不知道，那不是为那些拥有疯狂 GitHub 统计数据和装饰精美的宏之类的硬核开发者保留的吗？我不知道自己在做什么，谁会在乎一个随机的大学生对他们的代码有什么看法？” 你可能是对的。但这都是在我偶然获得在红帽公司 OpenShift 工程部门实习的绝佳机会之前，那段实习占据了 2020 年的大部分时间。

我像任何一位刚入行的计算机科学专业的学生一样开始实习，马马虎虎地写着未经测试、几乎无法阅读但不知何故仍然可以正常工作的代码，并为此感到自豪。但这次实习带来了让我亲身接触开源文化的机会，并最终了解了所有炒作的意义。

我在 OpenShift-GitOps 团队工作，正好在红帽公司正式将 Argo CD 纳入其生态系统的时候。随后，我和团队的其他成员一起，承担了向上游 Argo CD 贡献代码的任务。我决定把我对这次经历的一些想法写成一篇文章，带你了解一下。

弄清楚事情

正如你可能预料到的那样，刚开始时很困难，而且让人感到迷茫。我认为我们都同意，阅读代码已经够难的了，如果代码是由你团队的同事编写的。要快速了解在一个不同的组织中编写的代码，可能使用了不同的技术、不同的组件和不同的编码实践，很快就会让人感到不知所措。有好几次，我发现自己漫无目的地翻阅文件。

我很快意识到，我的第一步应该是尝试以用户的身份而不是开发者的身份去理解产品。这包括尝试启动并运行软件，并试用它。幸运的是，我有一个完整的团队也在经历同样的事情，所以我们可以互相帮助进行设置并顺利度过难关。

也是在这个时候，我开始体会到优秀的文档的力量，以及它能为开发者的生活带来多大的简化。作为额外的福利，Argo 社区的好心人非常乐于助人，他们每周都会举办一次办公时间，以帮助所有新的贡献者轻松入门。这些会议在加速尴尬的适应阶段和帮助我们的程序员本能更快地发挥作用方面发挥了重要作用。（它们也是一个很好的旁观者场所。）

选择和解决问题

稍微快进一下，我开始浏览未解决问题列表，寻找一些可以深入研究的东西。这可能是一个混乱的过程。开源社区严重依赖其成员参与其中的倾向，这带来了相当多的模糊性和缺乏对高效沟通的义务。这可能会以多种方式表现出来，例如无法在本地重现所描述的问题、理解问题所需的上下文不足，或者与提出问题的人沟通非常缓慢。在你经历开源体验的过程中，你可能会发现这是一个反复出现的主题。然而，这段经历帮助我意识到，选择正确的问题、理解其语义并在本地重现它，就已经成功了一半。

当事情进展顺利，你发现了一个有趣的问题，并且有不错的参与度时，这会非常令人兴奋！评论区中的讨论可以展示人们针对项目中特定问题提出的不同用例和解决方法。这些可能是上下文的绝佳来源，而收集上下文才是关键——至少在你弄清楚到底发生了什么之前是这样。

一旦我深入其中，开始思考解决问题的潜在方案，最让我感到震惊的是，我处理的每个新问题都伴随着巨大的学习曲线。其中一个原因是，我从下一个主要版本里程碑下未被认领的未解决问题中随机挑选。这意味着我处理的问题差异很大。我会在每个问题上都深入不同的兔子洞，在这个过程中学习 10 个新的相关概念（即使并非所有概念最终都进入了最终的拉取请求）。

即使在尝试逐步调试代码以跟踪错误的根源并遇到所有不同的相关组件时，情况也是如此。这个阶段似乎总是包含最多的学习量。当我慢慢地找到解决方案时，我经常需要填补一些知识空白。再一次，我相信我拥有任何人都可以要求的最支持我的同事，因为我总是可以在需要时咨询他们。

提交拉取请求

一旦修复或功能完成并在本地测试完毕，你就可以准备好提出你的拉取请求 (PR) 了！接下来通常会与仓库的维护者进行几轮来回沟通，他们会审查你的 PR 并可能要求进行更改。我总是惊叹于看似最小的贡献可能涉及的时间、精力和深思熟虑的程度。这从外部并不总是显而易见的，你的 PR 最终可能看起来与你最初开始时的样子大相径庭。

我还了解到，五行代码更改伴随 150 行代码的测试对于这些更改来说并不罕见。换句话说，为你的 PR 编写单元测试有时可能与修复/功能本身一样复杂，甚至更复杂。在一切都说完做完之后，你的 PR 终于被合并了。你可以跳一段快速的庆祝舞，但随后就要继续下一个了！

学习重要教训

在实习期间，我学到了很多东西，这些东西将在专业和个人方面对我有所帮助。

专业教训

• 在开始实习之前，我的大部分编码经验都集中在个人项目或学校作业，或为我的组织分配的任务。这些任务往往非常针对其目标受众，并且通常对更广泛的社区没有太大的影响。相比之下，开源项目往往具有更广泛的影响范围，因此思考我的贡献可能产生的潜在规模很有趣。这让我觉得我的工作是有意义的，这让它感觉值得。
• 如果你像我一样，那么随机发现问题并修复它们可能过一段时间就不那么令人兴奋了。你可能会问，“这一切实际上会带来什么？” 这就是为什么我认为重要的是要有一个更大的格局和一个明确的方向。它有助于驱动你的决策，并提醒你你正在努力实现什么。红帽公司采用 Argo CD 的更大目标和长期愿景为我提供了这种方向感，并帮助我保持动力。但这可能可以通过多种方式实现。更有策略地挑选和处理问题，这样它们就可以让你学习你感兴趣的编程方面，从而让你变得更好，这可能是其中一种方式。

个人教训

• 闯入一个新领域可能会让人望而生畏，这已不是什么秘密。我可能和软件行业的一半人一样，对冒名顶替综合症并不陌生。有时我感觉自己的进步不够快，或者没有达到自己期望的进度。这令人沮丧，但我最终明白了对自己有耐心是多么重要。特别是如果你是一个刚入门的人，可能需要一段时间才能开始取得良好的进展，但值得记住的是，这一切都是学习过程的一部分。
• 早期，我倾向于将自己与更有经验的同事进行比较，他们处理问题的速度更快，合并 PR 的速度比你说完“Argo CD”还要快。这并没有对我的信心有太大帮助，但我意识到，将自己（一名兼职实习生）与行业资深人士进行比较对任何人来说都不是一个公平的比较。提升自己的最佳方式是将自己与过去的自己进行比较，而不是与周围的人进行比较。

我学到的其他有用的技巧

• 不要犹豫在社区论坛上提问。此外，尝试找出项目是否有你可以加入的 Slack、Discord 或 Gitter。
• 查看其他 PR 和讨论，以了解项目中正在发生的事情，并更好地理解代码库。
• 尝试识别与你感兴趣的工作流程相关的唯一日志和错误消息。直接针对代码库搜索这些消息可能是一种快速定位你想要关注区域的方法，而逆向工程到达该点的函数调用序列可能有助于你了解沿途发生的一切。（我发现这特别有帮助。）
• 查看单元测试可能是了解函数应该做什么以及它如何与其他函数交互（输入/输出格式等）的好方法。
• 寻找标记为“good first issue”的问题可能是一个好的开始。但是，可能有很多好的问题没有被标记为这样，因此可能值得在过滤器之外浏览问题板。
• 如果你正在进行功能编辑，请务必更新文档！

结束语

开源贡献体验不是一个完美的过程。与任何其他事物一样，它也有其缺点。其开放式性质带来的模糊感以及偶尔缺乏反馈或沟通可能难以解决。另一方面，我很高兴看到在这段时间里我能够成长和获得多少经验。我发现成为开发团队的一员既具有挑战性又令人欣慰，我因此变得更好了。

在一个不同的范式中工作，成为更广泛的开发者社区的一员，以及建立新的联系都是很大的优势。合并你的 PR 也是一种很好的感觉！我还受益于发现 PlayerUnknown's Battlegrounds 是一位 Argo CD 用户，我通过告诉我的朋友们这件事，帮助改善了他们玩 PUBG 的游戏体验。

如果你一直读到最后，感谢你的阅读！我希望这对你开始自己的开源世界之旅有所帮助。祝你好运！