编码器 协议不公开_公开编码的3种后果

编码器 协议不公开

我不知道你上周干了什么。 我找不到我想要的。

但是，如果您对此感到好奇，那么您可以准确地找到我周一至周五的工作。

例如，在2016年8月31日，我对Response Commerce的主要代码repsository的各个分支进行了3次提交。 他们中的两个通过了测试。 一个失败了，我不得不返回并修复错误。 几个月前，我整天都在为即将发布的版本修复棉绒问题 ，今天，我修复了一些与平台有关的i18n翻译问题 。

不过，您不需要我告诉您。 这是因为我每天所做的每一件事都可以在GitHub上看到。

我们确实有一些私人分支机构，我偶尔会工作，但除此之外，我的大部分工作（以及Response上所有其他开发人员的工作）都在那里供您查看。

令人生畏。 真是可喜。 好有趣。 太恐怖了

这是我第一次为开放式组织工作。 在Response Commerce之前，我曾在两家封闭源代码软件公司Media Temple和TTPM任职。 这是一个挑战，但是由于开源的透明，连接和协作的性质，我已经成为一个更好的开发人员和交流者—我每天都在学习很多东西。

这是我从全职从事开源工作中学到的一些独特的经验教训。

绝对透明是绝对的

您可以从我的GitHub活动中了解很多有关我的信息。

例如，鉴于我提交代码的时间，您可能会注意到我是夜猫子。 您可能还会注意到，在两个星期内，由于我正在休假，所以我没有为该项目做任何贡献。 您可以看到我为自己感到骄傲的最大编码天，您可能会想：“没什么！ 我的生计是您的判断，所有这些都没有我的投入。

这是一个可怕的想法。 同样令人恐惧的是，任何准雇主都对我所做的一切每天都有详尽记录。

在封闭的环境中，发生的大部分事情都在雷达之下。 它是在小型团队中讨论的，或者根本没有讨论过，只要它有效，就永远不会受到质疑。

但是在开放的环境中，我无法修复代码。 如果需要更改一行代码，我有责任通知社区并告诉他们我在做什么。 我提出了一个问题，创建了一个分支，提出了拉取请求，然后联系团队成员进行合并。 我们所做的每一件事每天都会影响成千上万的人。 每个更改的变量都可能破坏存储。

绝对的透明性使我成为一个更好的计划者和开发者。

学会完全透明是一个挑战，但是我相信这使我成为了更好的开发人员，可以记录我们的想法并强迫自己了解自己在做什么。 几个月前，我偶然从错误的分支分支中发出了分支请求 。 这是每个开发人员都会犯的一个简单错误，但是我的错误将继续存在于Response代码库中，以供所有人查看。 我不得不公开地解释为什么我要杀死一个分支以对另一个分支进行相同的更改。 OY合租！

还有我的工作习惯和奉献不受约束（有时不受约束）的问题。 在封闭的环境中，我的直接经理通常将是唯一掌握我的日常活动的人。 如果其他人需要知道，我有机会解释自己在做什么。 但是在开放的环境中，一切都应有尽有。

24/7的可用性令人感到沮丧

在封闭的环境中，您几乎不需要帮助任何人使用您软件的代码库，因为他们根本无法访问它。 问题在营业时间内在内部得到解决。

但是在Response上，我们的代码库可被任何地方的所有人访问，我们的公共聊天室也是如此。 因为我们是24/7全天候开放的，所以世界可以随时问我们一个问题，我们需要回答。 有时候，发生问题时，我们会帮助商店重新上线。 几天前，我们花了几个小时来帮助某人首次安装Response。

因为我们是24/7全天候开放的，所以世界可以随时问我们一个问题，我们需要回答。

周围有人认识的人会做出React真是太好了。 但是，当您期望快速回答​​查询时，尤其是当您遇到麻烦时，全天候24/7连接可能会中断。 尽管如此，您全心全意地尝试构建的产品最终还是针对您正在帮助的同一个人，因此您必须打断自己。 另外，我想说我们的社区已经足够了解我们的习惯，以至于他们知道我们的可用性，因此他们相应地降低了期望。

很高兴看到人们说“谢谢”的次数。 在我们的聊天室中。 我去过另一端，那里的人并不总是在那里，所以我真的可以与我们的贡献者的感受联系起来。

协作带来发现

在封闭的环境中，您有一个与之合作的团队，而该团队很少变动。 决策，失败和胜利都是在这支团队之间共享的，通常情况就是这样了。 我经常想到我们自己的Sara Hicks所说的出色话 ：“开源开发可能只是最佳的协作体验。”

我们在React有一支很棒的核心团队。 但是实际上，我的同事实际上是为Response 做出过贡献的每个开发人员。 不管您是打错打字（顺便说一句，这是我受聘前很久以来我的第一次贡献 ）还是贡献了整个仪表板功能 ，每一个贡献都使Response变成了今天。

生活在您的舒适区之外，并不断收到来自数百个国家和背景的用户的反馈，真是令人惊讶。 您将学习与通常的工作方式完全不同的方法，但仍能获得相同的结果。 同时，当我们想对产品进行更改时，厨房里有这么多厨师会引起沉思。 西部似乎很荒凉，但我们花了很多时间来讨论如何做得最好。 协作使您思考未来的远景，这对于像JavaScript这样不断变化的事物而言非常重要。

生活在您的舒适区之外，并不断收到来自数百个国家和背景的用户的反馈，真是令人惊讶。

一年来，我们已经多次更改了编程语言和环境。 现在，我们将UI代码库从Blaze模板转换为React。 我敢肯定，对于成千上万的开发人员来说都是如此，但是当时，我还不知道React。 我一直在学习，首先对同事Mike Murray的现有组件进行了一些更新，然后在每个新版本中都做了一些自己的修改。 现在我已经有几个月的经验了，我很乐于帮助我们代码库之外的其他人。

这些都是巨大的变化。 它们是在开放源代码平台上工作的，可以在一组开发人员之间轻松做出选择。 但是在一个开放的组织中，这些重大决策将影响成千上万的人。 这使大胆的决定暂停了。 切换到React意味着我们必须相信我们的社区会知道并希望与React合作。 我们必须解释为什么我们选择React而不是Angular，选择LESS而不是SASS，选择Mocha而不是Jasmine，以及选择两个空格而不是四个空格。 这可能对生产力构成挑战，特别是在我们按时完成任务的时候，但是一旦我们达成协议，我们就可以确信我们拥有整个社区的支持。

结论

我永远不会排除回到任何封闭的来源（不是我打算离开Reaction！），但是在开放源代码下全职工作使我看到了我真正喜欢的事物的崭新面。 绝对的透明性使我成为一个更好的计划者和开发者。 在实施之前，之中和之后必须向世界表达我的想法，这改变了我做事的方式。 24/7的可用性既令人着迷又令人难以置信。 最后，不仅与核心团队合作，还与我们的GitHub社区合作，促使我共同制定决策并成长为一名开发人员。

我期待着面向开源社区的许多新面Kong和贡献者，以及更多的挑战。

翻译自: https://opensource.com/open-organization/17/8/transparency-at-reaction

编码器 协议不公开