拆分为两套代码所存在的问题:
使用不同分支后,大型修改的合并将变得极为困难,不论是从上游合并到下游,还是下游合并到上游,都将成为一个耗时巨大的工程,以轻共享代码合并上游为例,历时3个多月,经历过大量测试,仍然出现风险不可控。如果只是禁绝了从下游合并到上游的可能,下游的客户也一样需要承担上游合并到下游所带来的功能异常风险,及下游代码丢失的风险,该风险从宏观和微观层面,都与下游合并至上游一致。
分析目前工作特性
需求差异
在没有强一致性的标准下,toB产品必然存在由于管理制度不同而导致的需求差异情况,那么针对某个企业的特异需求,如何考虑,转换成一个可以通用的配置性需求,是对大客户产品设计的一个必定要求。如果转换成了通用性的配置性需求,那么就可以认为是一个标准化的产品需求,那需要解决的问题就是由于交付压力而导致的交付时间问题,而交付压力在研发过程中就转换成为了团队资源差异,最终转变为代码差异。
三种服务扩展方式
对于一个已有服务的扩展应该分为三种类型:
- openapi式扩展
- 服务覆盖式扩展
- 代码式扩展
在目前的实践阶段,由于微服务化程度不够,主要的扩展方式为1、3两种,其中openapi式扩展由二开团队负责,代码式扩展由大客团队负责。
在深度微服务化后,可以增加一种服务覆盖式的扩展手段,以保证上游代码不变的情况下,下游代码实现新的接口,以新的逻辑提供服务,并不需要阻止有共性的服务,而可以由服务调用方进行逐渐的优选,详见亚马逊AwayTeams模式。
由于交付时间压力的存在,所以代码式扩展不可能被完全禁绝,所以代码质量管理成为目前最大的管理症结,例如之前提出的,责任田内代码被其他团队修改,导致最终的bug权责不清问题。
参考管理实践
对于大型团队的代码管理,参照了大型公司谷歌、亚马逊、脸书以及大型开源项目如Linux基金会的管理方案。
Amazon Away Teams架构剖析/解密:AWS的工程师如何开发和维护他们的内部技术
[转]facebook是如何管理代码的_trace的技术备忘专栏-CSDN博客
Participating in Open Source Communities - Linux Foundation
提取的共性:
Code Owner
Code Review
二开现状更类似于开源软件项目的上下游概念:
主产品作为上游。
二开部署代码作为下游,如果每个客户都存在只属于该客户的代码增量,需要投入大量的资源来保证下游代码稳定,如果所有大客户使用同一套代码作为下游,则与上游并没有根本区别。
优化方案
优化代码管理思想:
来自于其他团队的代码贡献不可避免,只需通过code review的方式避免低质量代码合并,下游贡献的高质量代码是对责任田能力的优质补充。
如果沿用现有组织机构,提升上下游意识,保证“上游优先”可以解决代码差异问题,通过CodeReview来提高其他团队修改代码导致的质量问题。