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

研发效能领域洞察系列

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

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.研发模式决定研发组织、流程&方法、工程&工具

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

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

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

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

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

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

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

案例  CASE

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

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

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

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

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

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

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

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

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

• 松： 和其他业务松耦合

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

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

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

长按识别二维码关注我们

P.S.

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

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

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