维护热门开源项目的 6 个经验教训

2016年至2018年间，我维护了一个每月下载量超过80万次的开源项目。从中我学到了六个宝贵的经验，现在我想与大家分享。

一切是如何开始的🛫

我于 2016 年加入 Spotify，当时我的团队需要一个 React 日期选择器组件。我在 GitHub 上搜索了很多，最终选定了一个。我把它集成到我们的网站中，并阅读了代码和文档。很快我就意识到这个项目还有改进的空间。于是，我提交了几个 PR，添加了代码检查器、一些重构，并改进了文档。

项目负责人负责审核和批准我的拉取请求 (PR)。就在这时，我看到了机会！我给他发了一封邮件，问他是否需要维护项目的帮助，他欣然欢迎我加入团队！哇！感觉就像加入了一个秘密俱乐部！我一直想维护一个受欢迎的开源项目，这真是太令人兴奋了。

我以前从未维护过开源项目，所以完全不知道会发生什么！这个项目很受欢迎，但有很多未解决的问题和未合并的 PR。我先从解决这些问题开始，然后着手提升代码质量。

一旦我了解了代码库，我就会做出更重大的改进，例如对 API 的更改。

两年过去了，154 次提交，我学到了很多！以下是我最宝贵的六条经验。

我花了很多时间编写文档，改进了组件的入门体验。尽管如此，我还是有一些问题在文档中得到了解答。这种情况一直在发生，我尝试让文档更直观，但并没有什么帮助。

“我没办法马上搞定，所以我得问问！ ”这种习惯很糟糕。作为一名软件工程师，你需要阅读文档来学习和进步。你的问题不一定有人能解答，到时候你该怎么办呢？

我开始维护这个项目的时候还是个初级工程师。我以为自己已经把所有事情都搞清楚了，但天哪，我错了。我有幸与经验丰富的工程师一起在这个项目上共事，学到了很多东西。我当时很自信，心想“这才是写好代码的方法”。可后来有人发了一个 PR，完全违背了我的信念，我不得不重新审视什么是好的代码。

现在，作为一名高级工程师，我发现好的代码并不总是客观的。当然，我们认同一些好的做法。但总会有人不同意你的观点，而且理由充分！

维护开源项目最让我惊讶的一点就是这一点。在 GitHub 上使用 Git 的开源世界里，我们与未来的自己沟通的空间非常有限。我们应该明智地利用这个空间，并尽力在编写提交信息时做到尽可能清晰。

反正我就是这么想的，但大多数人似乎并不认同。我经常看到一些 PR 没有任何描述，只有一条提交信息说“修复渲染错误”。这不仅是一个糟糕的做法，还会减慢 PR 合并的速度。

如果你曾经为开源项目贡献过，你一定体会过你的 PR 被合并的滋味。那种感觉太棒了！我成为了更伟大事业的一部分！现在我可以告诉你，成为按下“合并”按钮的人，感觉也很棒。这是一个三赢的局面。PR 的作者、维护者和项目使用者都获益匪浅。

人们会抽出时间去为陌生人使用的组件做贡献。在我看来，这就是开源的意义所在。人们为了更大的利益走到一起。如果你现在还没有为某个开源项目做贡献，不妨试试。如果你已经参与了，那就继续做下去，你太棒了⭐️。

维护这个项目让我很开心，但无论我花多少时间修复错误，总会有新的问题出现。这个组件比我最初想象的要复杂得多。有时，似乎有源源不断的新问题不断出现。

当时基本上只有我一个人在维护它，另外还有几个人帮忙。我感到自己肩负重任，因为真的有人遇到了真正的问题。我可以通过修复错误来提供帮助。所以我确实修复了很多。但我从未停止，直到那时我才感到筋疲力尽。

在这个项目上工作了两年之后，有一天我突然意识到我已经一个月没碰它了。于是，我决定停下来。我给老板发了封邮件，解释了一下。他说这很酷，并感谢我的帮助。他甚至还从他的公司寄给我一些“我们都能得到的东西”（SWAG）！一件T恤和一些贴纸。谢谢你，哈维尔！

维护一个开源项目很有趣。项目里的人都很棒！但也可能很累。

以下是我所学到的经验教训的总结：

如果你有机会尝试，我推荐你尝试一下。现在有数百万个项目正在寻求帮助，勇敢地开始贡献吧！你不会有任何损失。

最初发表于prplcode.dev