微信号:infoqchina

介绍:有内容的技术社区媒体

InnerSource:来自PayPal内部的开源实践

2015-11-06 08:14 适兕 译

InnerSource仅仅是一个名称,它是一种在企业内部应用开源软件实践的软件开发方法。来自PayPal的技术带头人Cedric Williams,在开源大会OSCON上解释了在PayPal如何使用InnerSource来打破孤岛、加强合作、增加生产力。

实践开始于18个月以前,清算平台的团队当时大概需要花2/3的时间来重写由区域团队所提交的代码。而区域团队,有一个很重要的职责,那就是确保PayPal能够在不同国家符合当地的一些规定。这种情况对于谁都没有益处。清算团队没法做好自己的本职工作,而区域团队所话费时间写的大量代码而别人又用不上。


InnerSource的灵感来源与实践


PayPal从开放源代码软件中汲取了灵感,尤其是来自Apache软件基金会的实践。他们发现了开源软件的组织原则,即每个项目都有各个金字塔的层:用户,在最底层;贡献者;可信任的提交者;最上层是架构师/开发者的领导者。PayPal评估了这些个情况后,作出最大的变化是引入“可信任的提交者”角色。


找到合适的可信任的提交者可不是一个简单的决定:清算团队中只有10%的人是这样的角色。Williams在此回答了人们一个问题,成为可信任的提交者需要哪些技术技能?首先必须有深厚的技术功底,然后对于代码库的核心了如指掌,即使有了这两样也不能成为最出色的。可信任的提交者还必需拥有良好的人际交往能力,他们要成为教练员。他们需要以积极、清晰的方式来沟通。举例来说,不要说“这些代码无法接受”,而是需要这么去说“这是我需要你去做的方可接受你的代码,这里有几点原因[...]”。


不出所料,引入可信任提交者角色带来了政治上的扯皮风险,所以不得不小心的去处理,无论是清算团队内部还是外部。为了使全局能够接受变化,可信任提交者不仅仅要审核来自区域团队所提交的代码,还要审核来自清算团队其他成员所提交的代码。


实施6个月之后效果出来了,清算团队再也没有花时间去重写别人的代码了,而仅仅花了10%的时间去做审核代码的工作,该团队进行了一次大规模的重构,且在没有做任何计划的情况下提升了4倍的性能。团队成员的心态也从排斥转变为积极的接受。一个最大的副产品是所有相关的沟通都通过写作来完成,多数是在Github上:PayPal使用Github来托管他们的开源软件,使用企业版Github来托管他们的闭源项目。这使得能够在所有的团队之间进行知识共享和传播。


PayPal以前的方法


在InnerSource之前,PayPal尝过不同的方法,它们是:自顶向下的强制和驻场。


第一种方法,即自顶向下,是比较传统和古老的了。定义严格的规则和利益相关者,自顶向下,让人们承担责任。这无法解决问题,但是可以产生很多的会议。


驻场的情况会好一点。来自各个区域团队的高级工程师们都被租借到圣荷西,和开发团队的成员们在一起工作。驻场能够达到知识的共享,且能够对彼此团队的行为有所了解。非常遗憾的是 ,一旦这些工程师们回到了各自的区域团队之后,他们就会成为瓶颈。他们发现找不到时间或者是没有所需要的技能将他们所学到的传授给他人。


入门建议


Williams为InnerSource的入门者提供了一些建议。在第一步,在你的工程师团队中将可信任提交者限制在10%,要求所有的代码都须公开审核,且要确保代码的审核要聚焦于完成什么从而使代码更加的良好;第二,要求所有的对话都是成熟的、得到尊重的;第三,分享你的经验。


  • 本文为InfoQ英文站原文译文,点击阅读原文可获取英文原文链接


今日文章推荐


1.技术债务管理,是什么&怎么做!

  • 点击文章标题直接获取内容👆


技术债务是由Ward Cunningham在1992年的报告创造的一个比喻,被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。


为什么软件从业者意识到技术债务很重要?为什么一定要避免引入它?


因为巨大的技术债务影响了软件开发团队的生产效率,并降低他们的士气和积极性。技术债务不断累积导致了恶性循环:巨大的技术债务降低了生产效率和团队的士气;同时低生产效率使得管理者推出更多的功能并导致技术债务问题的延期,而这又进一步增加了技术债务。


2.中国技术力量:携程的技术演进之路

  • 点击文章标题直接获取内容👆


携程今年动作不断,继5月份收购艺龙后,前不久又宣布了与去哪儿合并,成为国内在线旅游领域当之无愧的霸主。那么一路走来,技术是如何支撑携程成长到今天的地位,我们基于过去三年携程在QCon会议中分享的十几篇技术主题内容,从一个独特视角来下分析下携程技术的演进之路。


在今年11月17日QCon旧金山的中国技术开放日专场上,携程旅行网CTO叶亚明(Eric Ye)先生也将上台与大家分享携程的技术演化进程。


3.OPPO的服务化架构系统监控难题解决方案

  • 点击文章标题直接获取内容👆


众所周知,系统监控一直是拥有复杂IT架构的企业所面临的一个重要问题,而这也并不是每家企业都能够轻松解决的技术挑战。OPPO作为一家国际智能终端设备及移动互联网服务供应商,推出过多款外观精细、功能可靠的智能手机产品,其品牌知名度也一直名列前茅。但实际上OPPO公司与其他快速发展的现代企业一样面临着自己的IT挑战,而更加鲜为人知的,则是其品牌背后同样出色的IT团队与信息化支持能力。


OPPO后端系统规模近几年快速发展,系统重构以后采用了服务化的架构,各系统之间耦合降低,开发效率得到了很大的提升。然而在服务化带来了好处的同时,难于监控的问题也一并出现。由于服务之间调用关系错综复杂,接口出现问题,多个系统报错,因此很难定位真正的故障源头。整个请求调用链就像一个黑盒子,无法跟踪请求的整个调用路径,发现性能瓶颈点。


为了解决这些问题,OPPO公司自行开发了一套监控系统,并结合第三方监控系统,形成了从App请求开始到后端处理过程的完整监控体系。OPPO监控系统的简称为OMP(OPPO Monitor Platform),历时半年开发,分为两期上线,现在已全面接入OPPO线上项目。


版权归属InfoQ,禁止私自抄袭转载。

回复关键词React | 架构师 | 运维 | 云 | 开源 | 物联网 | Kubernetes | 架构 | 人工智能 | Kafka | Docker | Netty | CoreOS | QCon | Github | Swift | 敏捷 | 语言 | 程序员


投稿:editors@cn.infoq.com

合作QQ:1073600161



 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 iso文件用什么打开 iso文件怎么打开 用户体验设计和精益设计的平衡之道 安卓App热补丁动态修复技术介绍 mnv*框架时代 服务的扩展性