如何找到适合自己的研发模式?

研发效能领域洞察系列

站在蚂蚁金服的视角,自主研发的中间件、数据库、研发平台等金融科技引领着企业数字化的技术趋势。其中,以蚂蚁研发效能为代表,催生了很多赋能行业的方法论和工程实践,特别整合推出 研发效能领域洞察 系列文章。今天的内容将围绕“研发模式”展开探讨,引入了业界很多典型的案例,让我们一起从不同的方向挖掘匹配自身需要的研发模式。

如何找到适合自己的研发模式?

01

What:什么是研发模式?

所谓“模式”,其实就是一套被反复使用、多数人知晓的经验总结 它介于理论和实践之间,由纷繁复杂的实践抽象、提炼而成。

比如组织模式,就是对组织效率的总结。如果你要组织 2 个人,自然会用到“羽毛球双打模式”,不需要明确的分工,用信任就可以粘合;如果你要组织 11 个人,就要参考“足球队模式”,做一些 442、451 的阵型和分工。

再比如软件设计模型,就是对软件系统反复出现的问题的解决方案的总结。如果你希望底层模块不感知上层,而上层模块可以在底层变化时收到通知,自然会用到观察者模式(Observer);如果你的系统希望和其他系统对接,双方又都不希望变更协议,那么自然会用到代理模式(Proxy)。

软件开发领域也一样,针对研发过程中的各类相似问题,总是能提炼出一些共性的解决方案,这就是研发模式。

当然,你可能会想到业内的很多词,比如敏捷、Scrum、SAFe、持续交付、DevOps 等等,它们确实提供了很多理念、方法、实践,但是它们不代表研发模式。根据我们自己的观察,很多大型 IT 公司都有一套 适合自己的研发模式体系 ,它的本质其实就是一组被命名好的解决方案合集,一般都是参考业界一些理念并结合自身实践总结而成, 适合自己的才是最好的。

02

How:怎么找到研发模式?

一般来说,想找到适合你自己的研发模型,需要结合自身的业务特点、软件架构以及组织能力来分析。这个推导过程其实隐含了 3 个基础假设或者说基础前提,结合案例总结如下:

1. 业务特点决定软件架构

这个观点其实不用细讲,因为在软件行业里它已经被普遍认可。业务特点的分析,首先要看业务类型,简单可分为嵌入式、APP客户端、IT产品产品、云服务,然后再看当前业务的发展阶段,比如初创期、上升期、成熟期、转型期。这两个一叠加,通常就变得复杂了,会有很多中间状态,比如老产品迭代升级、新产品构建、嵌入式产品转云化、云产品转云服务等等。只要业务在变,对软件交付形态、响应速度的要求就会变,那架构就必然会跟着变,这里面除了要看清业务诉求以外,更重要的是透过现象看业务本质。

案例  CASE

2015 – 2016 年,软件行业里“云”这个概念开始流行起来,很多产品都说要跟得上趋势,要把自己“云化”。有一家公司的一个网络安全团队,原来做的是嵌入式系统的,系统最终集成在硬件上卖给企业。这个团队的 Leader 有这样的需求:新一代架构准备做成基于微服务的云化软件,需要一套类似 DevOps 的解决方案。在分析过程中发现,他其实做的只是一款具有动态扩容能力的分布式软件,部署在多个服务器上,最后还是连着服务器一起卖给企业,交付周期仍然是半年,也不需要自己的研发团队来运维。归根结底,业务特点没有变化,和原来卖产品没有本质的区别,他真正需要先思考的是业务发展的方向和可能面临的问题,而非架构的演进。

2.软件架构决定研发模式 

我们平常看一个人要从多角度看,比如物理上看身高、长相、体态;功能上看做人、做事;性格上看内向、外向。看一个软件系统也是一样,评估它的优劣也要从多角度看,通常我们喜欢用“架构视图”这个工具。 

1995 年,Philippe Kruchten 在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文,引起了业界的极大关注,并最终被 RUP 采纳。 四个主要的视图分别是: 

  • 逻辑视图(LogicalView),描述了系统的功能需求,从为用户提供服务的角度考虑系统功能。 

  • 过程视图(ProcessView) ,又称“进程视图”或“处理视图”,描述系统的运行状态和特点,从运行角度考虑一些非功能性的需求,如性能、可靠性、可用性等等。 

  • 物理视图(PhysicalView) ,描述系统的硬件配置,把软件映射到硬件上,从物理角度解决系统的拓扑结构、系统安装、通信等问题。 

  • 开发视图(DevelopmentView) ,描述了在开发环境中软件的静态组织结构,从软件开发角度,看系统如何被更快构建出来、代码如何组织、开发人员如何开发和分工。 

每个视图设计的完备性会直接影响到对应的软件质量属性,具体对应关系见下图:

如何找到适合自己的研发模式?

根据历史经验,这些视图中最容易被架构师们忽略往往是 “开发视图” ,因为这似乎并不影响系统的功能、性能、运行状态、部署成本。而 开发视图是否被详细设计、有没有良好落地,直接影响着软件研发效率。

案例  CASE

2008 年,一家公司的首席架构师设计了一款某产品的新一代 OS 系统。这个系统是全面组件化的,组件间采用消息通信,具有多进程部署、扩容能力,同时在底层提供了模拟数据库机制,可以对复杂的业务逻辑实现进行建模,并存储在XML中。回头看来,这在当时是一个十分领先的架构设计,里面用的所有的理念全部前沿且正确。但是后来 8 年间,问题逐步浮出水面,虽然这个系统的功能、性能表现良好,可在 16 个版本的演进过程中,像是会吃人一样消耗掉了大量的研发人力,投入和产品不成正比。使用这个系统的产品也频繁反馈,说这个团队虽然有 1000 多人,但是功能上线慢、新需求无法承接、问题定位效率也低。公司组织了专家团队诊断后才发现,几个关键问题恰恰都出在开发视图上,首先,模型缺少可视化的 IDE,积累的几百万行 XML 难以分解和维护,不仅消耗人力,也导致了版本构建时间越来越长;其次,缺少组件间的有效测试工具,开发人员只能用模拟器做黑盒测试;另外还缺少定位问题的链路诊断工具,每次只能手动获取和分析日志;最后还有一点最关键的是学习成本非常高,一个开发想完成一个用户可见的功能,至少需要懂 Liunx 系统、掌握 2 种编程语言,学会 3 种数据建模方式,理解 15 种系统独特机制,普遍的学习周期都在 3-6 个月。针对这些一系列类似问题,公司花费了 2 年多的时间做专项治理。

综上所述,所谓的“研发模式”设计,其实就是开发视图的细化设计,因为常常不被重视,所以总是能找到很多 GAP。

3.研发模式决定研发组织、流程&方法、工程&工具

理解了研发模式,交付各环节的效能目标就很容易明确,那么围绕着目标,再结合现状,就能得出解决方案。我们制定解决方案通常有三个维度:

  • 交付模式: 软件生产过程抽象的看就是需求的流转过程,设计人员把需求从概念翻译成文档,工程师把文档翻译成代码最终生成软件包,运维人员再把软件包部署在环境上变为可运行的进程,运行起来的进程为客户提供功能。交付模式需要设计的是首先是每个环节的输入是什么、输出是什么以及如何有效验证。其次要结合架构看交付的粒度如何拆分,让每个交付件之间松耦合,尽可能做到独立交付。最后,还要结合具体场景来设计,比如新老需求并行开发怎么办,线上多版本维度怎么办等等。

  • 组织模式: 开发团队围绕着交付模式如何分工、协作最有效率。

  • 流程&方法、工程&工具: “君子性非异也,善假于物”,交付模式和组织模式明确之后,就需要看有哪些方法或工具可以支撑这个模式高效运转。结合你的组织和技术能力,通过可以在流程&方法、工程&工具中找到解决方案。

这些维度是有明显排序的。根据经验来看,架构解耦度低,交付模式设计得再好也很难解决问题;交付模式或组织模式设计的有问题,流程&方法、工程&工具对整体效率的影响微乎其微,相对的,管理成本会很高;最后,在理论上,流程&方法的最佳实践是经验和方法流程化、流程工具化,但结合实际来看,从来没有完美的系统,工具的不足要靠流程补,流程的不足要靠人来补。 

03

Why:为什么要先看研发模式

看到这里你可能会有一些疑惑,为什么不直接发现问题、解决问题,而是要先做这么大量的分析呢?其实这也是有原因的,通常,做效能解决方案的人是某个细分领域的专家,比如架构、设计、编码、测试、项管、团队管理等等,而软件研发过程本身是一项系统工程,它的问题繁琐、复杂,问题的症结常常不在你所熟知的领域中,如果不能站在一定的高度系统思考,就很容易陷入死胡同。下面结合身边的案例看看常见的三个现象:

1.专业偏见,用擅长的领域解决一切

美国作家马克·吐温有句名言:“如果你身上唯一的工具是一把锤子,那么你会把所有的问题都看成钉子”。著名投资家查理·芒格将这种现象称之为“拿锤子的人”。 人们经过年复一年的专业培训,一旦了解并熟悉了某一专业领域的思维模式之后,他们就会到处尝试将所有遇到的问题,都用自己的专业思维模式解决。

案例  CASE

一个 Android 手机操作系统团队,启动了一个开发效率提升的项目,在问卷调查阶段,开发人员普遍反馈了了“构建慢”的问题,这个问题的调研和跟进很自然安排给了一个擅长编译的工程专家。他立刻开始打开编译工程和配置,很快就发现了好几个问题,包括全量构建、多次打包等等,于是他用了 1 个月,把 30 分钟优化到了 15 分钟。奇怪的是功能上线后,开发人员并没有什么感知。后来调研才发现,反馈这个问题的同学基本都是内核态的底层软件开发,他们所谓的“构建”,指的是代码从提交、编译、出包、再传到手机上。这里面的痛点其实是把包传到手机上,由于公司网络安全的原因,要跨越 3 朵云,期间涉及 3 次工具操作,需要他时不时的跟进传输情况,累计要等 45 分钟。编译的 30 分钟,对他来说可以去做编码、做 Review,相比之下这 45 分钟的跟进才是最大的效率损失。

2.过度拟合,深入细节不见大方向

统计学中有一个现象叫“过度拟合”(over-fitting),这个概念也经常在机器学习领域用到,它指的是建立的学习模型在训练样本中表现得过于优越,导致验证数据集以及测试数据集中表现不佳。 简单说,就是死抠细节、追求完美,反而偏离了现实,忽略了更重要的问题。

案例  CASE

一个规模很大的 APP 团队做自动化测试,负责人基于自己在其他产品的成功经验,希望把自动化率提升到 85% 以上。APP 的服务端相对比较容易,需求变化慢、有标准化接口、有明确的质量标准,因此群策群力很快就完成了提升。相对的,APP 的客户端就困难很多,比开关机等各种异常场景、手机屏幕的差异、用户体验没标准,这个负责人用了很多技术手段来提升自动化率,比如引入界面测试工具、购买机械手等等,最后积累了几万个基于用户场景的用例。但是很快发现这些用例的维护成本太高,手机和 Pad 的屏幕尺寸在变、系统风格在变、用户的体验也在变,最终,每日能跑的也只有几百条基础用例。实际上,探索过来发现,其实还有另外一条路,就是只用自动化保证基本的功能和性能,其他的都让用户来测,高手在民间,通过吸引和培养几千甚至几万粉丝,频繁的开展众测来平衡成本和质量。

3.合成谬误,适用个体的不一定适用全体

“合成谬误(fallacy of composition)”是一个经济学概念,由萨缪尔森提出,它指的是对局部说来是对的东西,不能说明它对总体而言也必然是对的。最简单的例子,在一个剧场里面,有人看不清楚舞台上面的表演,站起来他就能够看得清楚。一个人站起来他能够看得更清楚,两个人站起来两个人能够看得更清楚,所有的人都站起来,没有人能够看得更清楚。在系统工程领域这个现象也很常见,有的方案虽然看上去完美、逻辑自洽,可以解决 1、2 个人的问题,但是若想同时解决一百个人的问题,可能就需要完全不同的另一套方案。

案例  CASE

主干模式的发布就是一个典型的例子,每个人都期望小布快跑,少一点防护、早一点合入,万一出了问题再快速回退就行了,这种思想很美好,而且实际上,10-20 个人的团队里可以玩的很高效。但是我原来参与过一个 2000 人一条主干开发的系统,在这个系统里,一次问题的引入,就会有几百人被迫等待,那么这种情况下就应该综合考虑更完备的解决方案,而非单纯的套用所谓的“业内最佳模式”。

04

蚂蚁金服的研发模式

讲到这里,你可能会很好奇,蚂蚁的研发模式是什么样的呢?它是怎么被系统设计出来的呢?由于篇幅有限,下面做一个极简的介绍。

1.业务特点:“快”和“稳”的平衡

蚂蚁的业务兼备金融行业和互联网行业属性。金融的核心诉求是“稳”,因为一旦出现资金问题就会失去用户信任,所以每次的发布必须是高质量。而互联网的核心诉求又是“快”,1个新特性可能需要1周甚至更早要上线,1个严重问题甚至要在几小时内完成修改、发布。按照常识来判断,我们知道,“快”和“稳”这两个指标的同时达到最大化几乎是不可能的,就像开车一样,你想快,猛踩油门,风险就会提升。因此,要解决这个问题就需要系统性的设计,尤其是在软件架构和研发模式上。

2.软件架构:“小、独、轻、松”

平衡 “快”和“稳”的关键首先是软件架构,想象一下,一辆装了60个人的公交车想加速,只能猛踩油门,车上的人都要承担更大的风险,而如果是60辆小汽车,那么状况则完全不同。蚂蚁的架构体系就是这样一套 分布式架构解决方案,包含了 微服务、限流/熔断、分布式链路追踪、分布式高可用消息队列、分布式数据库等诸多技术。从开发视图的角度看,它的每一次交付都具有 “小、独、轻、松” 的特点,即:

  • 小: 每次发布的交付件足够小

  • 独: 可独立开发、测试、发布

  • 轻: 能轻量级部署、升级

  • 松: 和其他业务松耦合

有了这样的架构保障,蚂蚁的业务在风险最低的前提下,就有了独立开发、快速上线的基础。

3.研发模式:Cloud Native下的研发模式

蚂蚁金服的研发模式如果套用一个业界比较火的概念,可以说,我们是“Cloud Native”下的研发模式。“Cloud Native”,是 Matt Stine 提出的一个概念,它其实是一个思想的集合,包括 DevOps、持续交付、微服务、敏捷基础设施、康威定律等等。有趣的是,蚂蚁并不是看到了这个概念才去实践的,而是在上述的业务特点和诉求下,运用了相应的技术,匹配了适合的研发模式,自然而然演进而成,这可能也正是“Native”这个词的精妙之处,具有“原生”、“天生”这样的含义。

05

结语

“研发模式”作为软件开发中的重要一环,随着技术和实践的丰富也日渐趋同,但匹配自身场景、找到适合自己的研发模式才能实现真正的落地。蚂蚁金服在日趋成熟的研发模式之上,也探索了很多优秀实践,比如单元化部署、AntWorkFlow、研发容器、 智能 IDE、 DevMind 等等,后续有机会再和大家一一交流、分享。

如果还想要了解更多,这里有更多研发效能内容推荐:

从代码层面开始,对 Code Review 这个基础而重要的环节进行剖析:

点击查看原文: 研发效能领域洞察 | 敏捷开发实战(一):Code Review 纵览

如何找到适合自己的研发模式?

长按识别二维码关注我们

P.S.

蚂蚁金服研发效能团队招募进行中, 解决方案架构师、技术运营、数据研发专家、技术专家、技术支持专家、 产品专家、测试平台高级开发工程师、代码分析技术专家 等众多岗位持续开放,让我们共同开赴DevMind/ DevOps /DevServices三大战场,助力内部及外部伙伴研发效能的持续提升:rocket::rocket::rocket:

如果你对任何岗位感兴趣,请留下联系方式,或者发简历到: AntLinkE@antfin.com

▼  点击“阅读原文”获取更多职位详情

原文 

https://mp.weixin.qq.com/s?__biz=MzU3NzczMDI4Ng==&mid=2247483786&idx=1&sn=372cf2cded3c1dbe6d530e37cada1b93&chksm=fd01620bca76eb1d1a58ca530301670c8bd9a234a69144f180c563be6de745fd8ff17fa13e3d&token=1872121949&lang=zh_CN

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 如何找到适合自己的研发模式?

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址