您想成为开源开发者吗？

作者：Cory LaNou / 用例
2015年11月11日

自从加入InfluxDB核心工程团队11个月以来，我多次被问及作为开源开发者是什么感觉，以及他们（提问的人）是否会喜欢这种工作。我唯一找到的合适回答方式就是分享我的经历，让他们自己得出结论。

这个人是谁？

通常我不会在一篇文章的开头谈论自己。我不觉得自己有多么出众或重要，但针对这个话题，设定背景是相关的。

我成年后的大部分时间都在从事软件开发工作。虽然我在最初起步时并不总是拥有正式的“开发者”头衔，但当我回顾我的日常工作时，很明显，我确实是一名开发者。我在1994年为一家制造电阻焊接机的小公司开始了我的职业生涯，作为一名质量保证技术员。在纸上跟踪缺陷和异常是困难的。我的经理已经在使用一款名为Paradox的软件来跟踪缺陷。不久之后，我开始修改输入界面和报告，以提高该软件的实用性。从那时起，我跌跌撞撞地进入了一个又一个软件机会（如果你真的想了解详情，请查看我的领英资料）。总结我的职业生涯，我在各种封闭源代码平台上写了大约十五年的软件。从Borland Delphi到Microsoft .Net。

行动起来！

2012年3月，Go发布了第一个官方的1.0版本。这恰好与我们对当前平台的彻底重写相吻合，看起来像是一个很好的技术匹配。对我来说，这独特的之处在于当时还没有形成一个真正的社区。当然，Go的核心团队在回答邮件列表，偶尔做一些演讲，但如果你在Google上搜索Golang或Twitter标签#golang，你会发现搜索结果相当空。当我继续在Go中开发并有问题时，我开始通过Twitter与他们的社区互动。我对Go如此着迷，以至于我成为世界上第一个Go聚会的组织者之一（仅比GoSF聚会晚3个月）。几年后，我在我居住的丹佛举办了GopherCon。参加GopherCon永远加深了我想要成为社区一员的渴望。这也是我遇到Paul Dix，InfluxDB的CEO的地方。

进入开源世界

我在2014年12月29日加入了InfluxDB团队。我完全不了解他们的代码库，但由于它是用Go编写的，我能够立即开始工作并开始贡献。

这是我向项目提交的第一个提交。不久之后，我有了我的第一个Pull Request。由于评论，有80条评论和许多额外的提交。这立即为我设定了一些期望。

所学到的教训

首先，代码质量非常重要。这并不是说你要写优雅、美丽的代码。我几乎所有的时候都写得很糟糕（我并不总是像我知道的那样重构）。这里的代码质量意味着像以下这些事情：

• 变量名 - 它们是否有清晰的上下文。
• 注释 - 它们是有用的还是令人困惑的？
• 代码组织 - 是否有人能跟随我刚刚写的代码的流程。

很明显，我长期以来一直单独编写代码，没有人告诉我我有多草率。

有人能看看这个吗？

这还是我第一次经历真正的代码审查。当然，以前有人看过我的代码，但从未逐行审查。你的代码上的评论往往非常“实事求是”，很容易被视为侮辱或针对你。请放心，它们不是。我总是把所有的反馈都当作是计算机分析了我的代码并做出回应。

我认为反馈就像拼写检查器。当问题出现时，通常是因为它错了，或者电脑没有理解它。有时候你的单词拼写正确，你可以忽略。然而，我的经验是，如果有两个或更多开发者对代码的同一区域进行评论，以下两种情况之一是真实的。最好的情况是还有一些改进的空间。最坏的情况是你完全做错了。这些既不是好也不是坏，它们只是存在。作为开发者，你需要修复它们，使它们变得更好，并不断成长。最重要的是，我非常感激我的团队成员或社区中有人足够关心，帮助我成为一名更好的开发者。

总之，对我来说，代码审查是必须的。这对你们团队的每个人都更好。我可能永远不会在任何不做代码审查或不懂其重要性的地方工作。

你们都知道这一点，对吧？

在我的第二个拉取请求中，我对另一件事有了非常明显的认识。每个人都可以看到我的代码。我一开始就理解了这一点，但我没有准备好感到不舒服。如果每个人都认为我的代码很糟糕怎么办？

为了增加这种恐惧，在处理这个特定的PR时，我发现Go语言中有一个意外的行为。当我查找Go问题上的问题时，我看到Dave Cheney对这个问题进行了评论，并最终关闭了它。我通过社区认识Dave，所以我向他提出了这个问题。Dave要求我提供一些背景信息，所以我自然地把PR链接给他，毕竟它是公开的。

接下来，让我惊讶的是，他开始审查这个PR！这就像有一个摇滚巨星要求你在他们面前唱他们的歌。为了增加更多的压力，我的团队成员开始在Slack上问为什么Dave要审查我们的代码。我的代码有问题吗？是的。Dave评论了吗？当然。以下是他的一些评论

• "我认为这个应该放在函数的顶部。为什么做了这么多工作，却发现地址不正确？"
• "ResolveUDPAddr在这里会返回一个更好的错误。一个你可以检查看是否是临时的错误。"

最终，这是一次很好的经历，我担心是没有必要的。由于额外的关注，我在这个特定话题上学到了很多东西。

你必须是一位专家才能全职从事开源项目的工作。

完全错误！当人们问我关于全职做开源时，我遇到的第一大担忧是，他们是否足够聪明，或者是否有足够的经验。

关于为什么你不需要成为专家，我有几点体会。首先，没有人对软件开发的所有东西都知道。我开始时真的对Time包了解不多。除了time.Now()，没有太多需要它的地方。在InfluxDB核心团队开发8个月后，我现在可以熟睡时输入time.RFC3339Nano！其次，你不知道（或做错了）的东西，社区会让你去学习。有时他们的反馈非常建设性和有帮助。有时，它可能显得简短或粗鲁（尽管我发现很多情况下这是由于他们的英语不是母语）。始终要记住的是，你是否从他们的反馈中学到了东西（无论好坏）？如果是，那么它就是一个积极的经历。到目前为止，我没有遇到过一次我认为是消极的互动。总的来说，他们一直很支持和有教育意义。

要无所畏惧！

希望我已经为我的开源开发者经历提供了一些背景信息。我鼓励每个人至少找到自己热爱的事情并贡献。即使是微小的贡献也非常受欢迎。说真的，即使只是修复文档中的一处单词错误，他们也会感激的！如果你没有时间进行修复，但发现了一个缺失的功能、发现了一个可以改进的区域，或者“惊讶”你发现了错误？只需提交一个问题。不要假设他们已经想到了或者发现了。无论贡献的是代码还是问题，都能让每个开源项目变得更好。

接下来是什么？

如果您这篇文章激励您参与开源项目，那就不要再寻找了！InfluxDB刚刚对几个需要社区帮助的开放问题进行了分类。查看博客文章或直接访问问题！