转载

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

研发效能领域洞察系列

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

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

What：什么是研发模式？

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

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

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

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

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

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

正文到此结束