协同训练代码_InnerSource：一种更好的代码协同工作方式

协同训练代码

随着冠状病毒COVID-19席卷全球，每个人都沉迷于掩体中，似乎是思考我们如何合作的好时机。 由于该病毒，技术会议已经关闭，甚至办公室常客也越来越多，会议制定者正在学习如何远程工作。 开源软件开发通常是远程完成的，因此也许借用一些开源开发方法，我们都能找到更好的方式进行协作并保持联系吗？

我曾与Danese Cooper谈过“ InnerSource ”或使用开源方法来开发内部或专有软件。 库珀是技术主管，长期开源倡导者，现在是InnerSource Commons Foundation的总裁。

[ 同样在InfoWorld上：如何在敏捷软件开发中脱颖而出 ]

（披露：我曾在Danese Cooper担任开放源代码计划的董事会成员，并且我以其他身份与她合作。她将我们形容为仇恨。）

什么是InnerSource？

InnerSource之所以如此命名，是为了区别于开源。 与开源不同，InnerSource是在公司内部开发的。 Cooper表示，“ InnerSource是在专有公司的防火墙内部使用开放源代码方法，因为这是编写软件的更好方法。” 一些了解如何使用InnerSource进行协作的公司还发现，他们可以在开放源代码中更公开地进行协作。

对许多人来说，开源是一种许可制度，仅此而已。 实际上，许多公司都以这种方式对待它。 对于参与开源项目的我们来说，它更多是一种协作，方法和工具的方式。 许可证使与陌生人的交流成为可能。 开源协作涉及公共存储库，提交者，请求请求，各种标准以及关于如何构建请求请求的规范。 例如，当我开始现在在Apache的POI项目时，我们需要单元测试的内容，注释和文档。 这些“规范”对于现代的拉取要求是必需的。

在许多大型公司中，您不能只是在您附近的区域之外更改代码。 但是，由于上游依赖项没有所需的功能，因此您常常要为无法完成工作负责。 在开放源代码中，您只需修复上游依赖关系，提交拉取请求，然后继续即可。 维护者可以“原样”接受拉取请求。 或者，该代码库的维护者可能会告诉您，因为您使用了全局变量和for循环而不是功能代码，所以无法接受请求请求。 如果被拒绝，则可以对其进行修复，并捕获对话。

本质上，一家实践InnerSource的公司以相同的方式运作，除了存储库位于公司内部。

为什么选择InnerSource？

公司采用InnerSource有几个目标。 一种是与分散的团队更好地远程协作。 如果您想招募最好的Node.js开发人员，那么他们并不全都在硅谷，或者就算在Cooper的爱尔兰也是如此。

有了COVID-19，现在我们都是远程工作者。 根据库珀的说法，“我们对InnerSource持稳定的兴趣。 目前还没有人说他们对冠状病毒感兴趣，但是他们说有兴趣降低设备成本。”

康韦定律是一句古老的格言，“任何设计系统（广义定义）的组织都将产生其结构是该组织通信结构的副本的设计。” 因此，公司内部的控制区往往会使许多人解决相同的问题。 Cooper报告说，InnerSource背后的另一个主要推动力是公司希望促进更多的代码重用，而不是让每个公司孤岛都编写自己的所有版本。

如果有很多人再次写同样的东西会发生什么？ 您遇到了资源问题，无法雇用足够的员工来避免瓶颈。 库珀的前雇主贝宝（PayPal）就是一个例子，该公司尽管有大约8,000名工程师，但仍试图在问题发生之前就进行招聘。

[ 同样在InfoWorld上：11个标志说明您正在编写出色的代码 ]

公司采用InnerSource的另一个原因是通过打破常规来推动创新。 Cooper表示：“ InnerSource已成功用于Bosch和其他一些非常大的公司中，这些公司实际上只是将人们从日常工作方式中脱颖而出，并将他们置于他们所处的不同环境中。自由地互相交流可以为创新创造条件。”

在标准的SDLC（软件开发生命周期）或公司版本的“敏捷”中，所产生的文档的价值通常是可疑的，并且很少阅读。 在开放源代码或InnerSource项目中，文档非常有用-就像开放源代码项目产生的工件比Cooper所说的，“您的团队将在项目结束时编写的废话文档”是更好的可行文档一样， 。”

工程师关于如何使给定的拉取请求可合并的对话包含很多信息，这些信息从未使它成为正式文档。 作为过程的一部分，它是被动发生的，因为您可以捕获人们之间的对话。

Cooper通过她的工作发现，InnerSource会给您带来质量上的自动提升，部分原因是代码审查在过程中是被动进行的。 在传统的或公司的敏捷过程中，通常人们会“橡皮戳”他们应该审查的代码。 尤其是当此人年长时，会发生这种情况。 从那里到将问题引入代码库仅一步之遥，因为除了原始开发人员以外，其他任何人都没有审查过该代码。

根据库珀的说法，“另一个原因是无形的，但这是真实的原因-员工的幸福。 人们对功能请求文化的围坐和等待感到非常沮丧。 它会产生大量的停止能量，而如果这阻碍了其他所有事情，那么敏捷就不会让您摆脱困境。 能够为持续不断的进步做些实际的事情对人们来说是令人惊奇的好处。”

根据个人经验，这就是我参与开源的原因 。 我无法忍受坐下来等待沉默的厂商解决问题。

InnerSource与敏捷开发有何关系？

库珀说，敏捷开发方法和InnerSource实际上“非常和谐”，只是scrum提出了一条建议，即托管是可取的。” 并置在InnerSource中是不可取的，因为它可以促进较少的书面知识交换和更多的口头知识交换。 这意味着这两个人分享了一些无法给予第三者的东西。 除非我们开始以某种有意义的方式记录人们的谈话并使它们可搜索，否则在此过程中，托管始终将是大量文档收集的敌人。

库珀觉得托管服务既昂贵又愚蠢。 “的确，一个小团队围坐在桌子旁可以做很多事情。 这实际上不是大公司的组织方式，如果尝试这样做，往往会非常昂贵且不必要。”

[ 也在InfoWorld上：Devops最佳实践：应该采用的5种方法 ]

敏捷中的所有其他功能都可以在InnerSource上正常工作。 实际上，敏捷的组织部分-即工作两个星期，进行演示等-所有这些都可能非常有帮助，特别是对于协作者而言。

InnerSource如何与产品和计划经理一起工作？

InnerSource的挑战之一是公司和产品经理习惯于自上而下的计划和“执行上报”。 在贝宝（PayPal），尽管取得了初步成功，但由于传统角色的中断和对行政升级的普遍沉迷，仍然存在很多阻力。

在“ InnerSource入门”中， Andy Oram指出，通过采用InnerSource，PayPal的质量提高了25％。 开发人员将其时间的65％用于一个团队的“执行升级”，因为这是组织的常规瓶颈。 但是，产品管理在下一个发行周期中取消了对InnerSource的更改，从而产生了负面影响。 结果，那些不想回到过去的工程师。

PayPal引入了外部帮助来制定需要进行的组织更改。 解决了功能优先级的啄食顺序系统。 产品经理转向编写高级故事。 拥有一个产品经理可以查看他们的故事如何被转换为工程故事的系统，可以使他们对结果具有更强的主人翁感。

库珀建议公司在这一变化方面走得更远：

我希望看到产品所有者在开放源代码方面越来越接近社区经理。 如果客户是他们的社区，那么请收集他们的反馈，以便工程师不必处理客户反馈的繁琐工作。 但是我不想看到他们沉迷于撰写故事。

您在哪里可以了解有关InnerSource的更多信息？

希望了解InnerSource的组织可以使用许多资源，其中包括两本相对简短的书：

• “ InnerSource入门”
• 采用InnerSource

PayPal还在InnerSource上制作了一系列视频 ，您可以在O'Reilly的收费墙后面找到这些视频，并进行免费试用。 还有一个InnerSource Commons ，它托管一个活跃的社区，其中包括博客，Wiki和git存储库。

最后，如果您有太多问题，可以聘请顾问，例如Cooper的NearForm或其他。

[ 通过InfoWorld Daily新闻通讯了解软件开发，云计算，数据分析和机器学习方面的最新发展 ]

但是您真的应该这样做吗？

如果更低的设施成本，更高的质量，更好的技术文档，更少的瓶颈，全球招聘和更大的开发人员满意度不足以克服组织上的障碍，请考虑Danese Cooper的最后想法：

新员工，尤其是刚从学校毕业的新员工，期望更高的透明度，而且他们不明白您为什么不那样做。 加入一家传统公司并被带给他们工作的方式，并发现他们作为个人所拥有的代理很少，这常常让人感到非常难过。 他们很难适应。随着劳动力的年轻化，以这种方式工作将变得越来越必要。

翻译自: https://www.infoworld.com/article/3534022/innersource-a-better-way-to-work-together-on-code.html

协同训练代码