积木式开发体系的原理与应用

“如何快速交付”的问题一直伴随着软件行业的发展。在多年的摸索和实践中，国双不断推进技术架构的演进，引入微服务、组件化、DevOps、灰度发布等手段，建立了由一套工程实施方法论、一个应用架构和一组辅助 工具 集共同构成的 “积木式开发体系”。该体系有效帮助国双在保证质量的前提下快速响应、快速迭代、快速交付，在提高开发效率的同时，可以实现降低开发成本。本文整理自国双技术总监曹荣权在 QCon 全球软件开发大会（北京站）2019 上的演讲，他介绍了积木式开发体系的原理、应用及实施积木式开发体系的要点。

大家好，我是来自国双的曹荣权，从事 To B 软件研发 15 年，转战电信、能源、航空、餐饮等多个战场，熟悉客户关系管理、数字营销、忠诚度管理等多个领域。很荣幸能够参加 QCon 2019 高效开发解决方案专场，并在这里跟大家分享这些年我们在企业数字化建设中的点滴积累，以及一个 IT 老兵对于积木式开发体系的思考。

我的分享主要包含四个方面，首先我会简单介绍积木式开发体系的诞生背景以及我们所面临的问题，然后介绍具体什么是积木式开发体系，积木式开发体系都包括哪些内容，之后我会重点介绍实施积木式开发体系的要点，最后介绍积木式开发体系在国双取得的成绩。

一、积木式开发体系的诞生“积木式开发体系” 的诞生不是偶然。伴随我们的业务发展，工程效率的问题随之出现。当时，我们面临很多项目，其中比较典型有“某热力集团智慧能效系统”和“某石油生产企业可视化监控系统”，接下来简单介绍一下这两个项目。

“某热力集团智慧能效管理系统”要求我们在 2 个月内接入该热力集团旗下的一百多个热力公司、热源和换热站数据，完成数据的监测与跟踪。从能耗、能效、成本、运营质量、服务质量、环境影响等诸多维度进行数据分析，并完成一套能耗预测模型和一套机构评级体系。此外，还包括一套告警管理系统和基于告警信息的工单流转系统。

另一个项目“某石油生产企业可视化监控系统”是油井数字化的典型应用，我们要在 4 个月内接入该组织下的 200 多口油井和抽油机的数据，从“载荷”、“油压”、“套压”、“平衡度”、“产液量” 等维度对数据进行跟踪、分析。从视频、数据两大监控体系入手，通过图像识别技术和大数据技术，结合功图模型分析油井的工作状态。并对设备状态进行评估和预测，以便油企能够提前进行设备的维护、维修和保养以避免由于设备维护不及时带来的停工和损失。

这几个项目都来得比较“急”，要求我们在很短的时间内完成大量的工作。与此同时，我们也和大家一样，面临“业务”、“效率”、“质量” 三个方面的挑战。

在 业务 方面我们要思考如何兼顾 “行业通用化”和 “企业个性化”？如何响应快速变化的客户需求？如何权衡 “个体需求” 和 “整体一致性”的关系？

在 效率 方面我们要思考怎样匹配项目的资源，什么样的人才可以复用，复用率如何提高？怎样保证产品研发和项目交付的独立性？怎样能尽量少做重复性工作，退一步说怎样才能快速做好这些重复性的工作？

在 质量 方面我们在研究怎么规范研发流程，怎么提高产品质量？怎么解决系统复杂上手难的问题，提高客户满意度？

就是在这样的情况下，我们决定在工程效率方面发力研究。“积木式开发体系” 也就由此诞生。

二、积木式开发体系是什么？

积木式开发体系是一个梦想，试想如果开发就像小孩搭积木一样照着图纸或者想象力轻松完成那该多好。别笑，梦想还是要有的，要不然拿什么慰藉我们早起晚归疲惫不堪的身体，又拿什么慰藉我们凌晨 3 点下班走在北京街头抬眼望去只有刚上班的环卫工人相伴时那颗孤独的心。当然我们不能停留在梦想阶段，毕竟 做梦不是我们的专业，实现梦想才是 。我们循着这个梦想摸索和实践，我们得出了一套工程实施方法论、一种应用架构、一组配套工具。积木式开发体系的组成如下图所示。

积木式开发体系主要由一套工程实施方法论、一种应用架构、一组配套工具构成。

• 工程实施方法 ：和大家的非常相似，整个过程也由 分析 >> 设计 >> 开发 >> 测试、交付这四个阶段构成，积木式开发体系在分析和开发两个阶段做了少量的调整，在分析阶段更注重差异分析，在开发阶段将常规的开发变成了配置开发，将约定、声明、配置提到了特殊的高度。
• 应用架构 ：是积木式开发体系的基础，这套应用架构允许我们通过简单的声明 / 配置的方式实现，并跟其他方式开发的软件呈现出一样的外观和用户体验。这种应用架构主要包括“界面堆叠体系”和“逻辑堆叠体系”两个部分。
• 配套工具 ：这是积木式开发体系在快速交付的重要手段，开发工具的支持是积木式开发体系落地的重要一环，是从 coding 到 configuration 的重要手段。

应用架构是积木式开发体系的重要基础，主要由 “界面堆叠体系” 和 “逻辑堆叠体系” 构成。

界面堆叠体系：软件界面是工程实施过程中的主要组成一部分，积木式开发体系将界面分为最终交付的 “成品”、组件化的 “零件” 及管理组件布局的 “界面装配车间” 三个部分。

逻辑堆叠体系：逻辑是工程实施过程中另外一个重头戏，积木式开发体系在逻辑组织方式上引入事件系统形成 “逻辑流水线”，和数据访问控制、安全、缓存、消息队列及 Workflow 构成的 “基础控制模块” 共同形成逻辑堆叠体系。

三、积木式开发体系的要点在打造积木式开发体系的过程中，有如下几个要点需要注意：

1. 固化渐进式“四问”思维

俗话说 “人的问题是根本性问题”，积木式开发体系中最核心的也是“人”。积木式开发体系设计要求每个参与其中的人都有渐进式的 “四问” 思维模式。这种 “四问” 思维并不是积木式开发体系所特有的。在我们日常工作中其实都在应用。当我们遇到问题时，我们总是会发出一连串的问句——类似事情是不是发生过？如果我们自己没有发生过，那么周围的朋友是否发生过？我当时是怎么应对的？我这次是不是也可以用类似的方式应对？一个典型的例子，当我们站在马路边打不到车时，我们会想有没有在相同的位置打到过车，如果在这里没有打到，我是不是换了另外的位置打到了。遇到技术问题的时候，我们也是一样的，如果我们自己身上没有发生就会问周围的同事，再不行就上网搜索，到 Stack Overflow 这类的社区里面去寻找答案。

在积木式开发体系中，我们将这种思维模式固化下来。“标准解决方案” 就是行业方案，“推荐解决方案” 是我们在个别客户实施的成功经验和典型案例。当我们在行业方案和典型案例中都找不到，我们优先采用简单的 “声明 / 配置” 方式来解决。如果以上办法都行不通，我们要考虑编写代码实现或者寻找第三方的帮助。解决问题的过程通常会反哺我们的经验集。在积木式开发体系中，我们会以系统的方式沉淀这种成功经验。一步一步形成我们自己的 “标准解决方案”。

2. 建立“七层组件” 界面结构

界面是功能的具体体现，自然也是积木式开发体系中实现配置化的重头戏。纵观我们身边的各种企业数字化系统，虽然形式多种多样，但整体上都可以用分层的方式来分析其界面构成。业界有很多不同的方式来组织前端的 “组件化”，积木式开发体系将这种封装（分层）的方式固化下来，形成 “七层组件” 的界面结构。从大到小分别是：

• Application : 是指整个系统。
• Screen : 是指系统中的导航以及整个内容区域。
• View : 是指进入某一个导航之后的整个内容区域所呈现的内容。
• View-Layout : 我们知道一个视图在不同的设备上展示的会有所变化，在不同的模式（阅读、编辑）下也需要有不同的展现形式。为了增加 View 的复用性，我们专门在视图之下增加了一个 Layout 组件，用于控制整个视图的布局控制。
• Applet : 子视图，对应的是业务层面的信息归类，通常与一个业务实体紧密相关。比如客户、订单、物流信息等实体。
• Applet-Layout : 子视图布局，和 View-Layout 一样，Applet 也面临多种形式（阅读列表、编辑列表、单个编辑、单个详情），是为提高 Applet 复用而增加的一层组件。
• Control : 控件，是子视图的主要组成部分，如：显示 / 编辑业务实体的属性的控件，或者按钮、菜单等。

这种七层组件的界面结构井然有序，即能够有足够的规律性支持我们的“配置化”，又能兼顾多终端、企业个性化带来的变化。

3. 理清界面 “拼装” 流程

在 “七层组件” 的界面结构基础上，界面 “拼装” 的流程主要涉及 Client-Side 、 UI Provider 和 Data Provider 三个部分。一个页面要呈现时 Client-Side 首先会向 UI Provider 请求布局数据，在取得布局数据之后 Client-Side 生成界面结构，同时向 Data Provider 请求需要绑定到界面中的业务数据，在布局和数据绑定都完成之后，完成整个界面的渲染工作。是的，过程就这么简单，一个系统的界面就完整地呈现在用户面前。

• Client-Side : 是客户端程序，包括 Client-Side Engine 、 Widget Library 、 Cache Manager 和 Client-Side UI 四个组成部分。
  • Client-Side Engine 引擎，是最主要的控制器，管理客户端界面的组织和渲染过程。
  • Widget Library 组件库，由 三层组件堆叠 而成，分别是内置的 Built-in Widgets、第三方贡献的插件 Add-on Widgets 以及项目实施过程中定制的 Custom Widgets。三种组件优先级不同，从高到低分别是 Custom Widgets -> Add-on Widgets -> Built-in Widgets。
  • Cache Manager 缓存控制器，为了尽量减少动态布局带来的性能损耗，布局数据启用预加载技术，建立内置布局数据、客户端布局缓存、服务端布局缓存的 布局缓存管理 机制。
  • Client-Side UI ，最终渲染的客户端界面。
• UI Provider : 布局提供者，是 Server-Side 的一部分。内部由 Custom Layer、Device Layer、Basic Layer 组成的 三级布局控制 ，以应对设备差异和客户个性化定制带来的变化 (这种变化不仅仅是控件位置的不同，也包括控件类型的差异)。同时，布局提供者还要与 Client-Side 之间建立 布局变化通知 机制，在布局配置数据发生变化时，布局提供者将主动通知客户端，以便客户端尽快刷新缓存呈现最新的界面。
• Data Provider : 业务数据提供者，按照需求执行正确的业务逻辑，提供正确的数据，是衔接积木式架构前端与后端的重要桥梁。Data Provider 提供统一的语言体系将前端和后端串接在一起，形成完整的前后端响应逻辑。

接下来让我们揭开 Data Provider 的面纱，一起探究背后的秘密——积木式开发体系的逻辑堆叠体系。

4. 建立可定制、可扩展的逻辑处理系统

逻辑和界面的关系，本身也分为几层，第一层就是基本的数据展现，我们的软件首先要做到的是在正确的位置展现正确的数据。如何能够做到整个基本的要求呢？在积木式开发体系中，我们针对 “七层组件” 结构中与业务相关的部分抽取出来，并形成与之对应的 三层逻辑结构 。这三层结构由如下内容构成：

• Business Object : 业务对象，用于组织维护各个业务实体之间的关系，比如客户与其名下订单的关系，订单与订单行项目的关系。同时也是运行时上下文的组织方式，会决定业务实体在新增记录时的一些字段的缺省值。
• Business Component : 业务实体，概念上与普通开发体系中的业务实体没有区别，通常与数据底层的“表”存在一定的映射关系。
• Field : 业务字段，指业务实体中的各种属性，大致分为两类，一类与界面显示密切相关，一类是内在逻辑所需的字段。

这 三层逻辑结构 ，一方面与界面 七层组件 对应，一方面规范所有业务逻辑的堆叠方式。通过这种机制，形成统一的语言描述业务实体之间的关系，也就形成了统一的上下文描述体系。

5. 建立事件代理体系

业务逻辑的堆叠体系除了业务实体间关系，还有逻辑的处理过程。在积木式开发体系中，逻辑的处理过程我们引入 事件 、 代理 、 声明 三种概念。

• 事件 ：我们将所有的业务逻辑处理都封装在一个个“事件”中。应用 AOP 的思想将所有逻辑过程都分为 “事前”、“事中”、“事后” 三个阶段，贯穿前后端。同时将逻辑分为 界面相关 和 界面无关 两层。由此形成从界面 Applet 中的点击开始到后端 Business Component 执行逻辑再到最后界面 Applet 响应的事件闭环。
• 代理 ：我们将事件的 “事前”、“事中”、“事后”三个阶段又分为 11 个小的步骤，一些以硬编码的形式书写业务代码；另外一部分我们实现事件逻辑的代理，以便我们能够进行二次开发和随时应变。这 11 个点为我们的逻辑验证测试提供了统一的检查点，友好地支持更细粒度的自动化测试。
• 声明 ：我们以最方便的声明方式配置这些代理，便于分离产品固有逻辑和企业个性化逻辑，取得行业通用化和企业个性化之间的平衡。

我们通过这事件体系形成了统一的逻辑描述体系，深度整合了 AOP 的思想，统一了代码风格，无形中提高了代码质量。同时也在框架级别统一埋点方式为自动化测试提供支持。

6. 快速配置开发工具

有了方法论和 “四问” 思维的指导，也有了从界面到逻辑的堆叠体系，我们的积木式开发体系大体上可以完成。但这些还不够，因为我们还不够快。我们还需要一些配套工具。

• 在线工具 ：支持我们随时都能方便直观地完成配置和修改。
• 离线工具 ：支持更多模式匹配、批量复制、批量更改等批量操作。
• DevOps ：整合 DevOps ，使配置信息 (Configuration) 能够以恰当的方式和代码 (Code) 进行织入，编译出和普通开发模式一样的代码。

有了这些工具的支持，我们才能方便、快捷地完成基于配置的开发工作，积木式开发体系的效率才能最大程度地发挥出来。

四、积木式开发体系的成绩

在国双，我们通过实践 “积木式开发体系” 取得了不小的成绩。在开头提到的 “某热力集团智慧能效系统” 和 “某石油生产企业可视化监控系统” 两个项目中，我们的工作量分别是 1 人月和 3 人月，最终我们顺利完成了项目的交付工作。

通过积木式开发体系的实践，我们在 “业务”、“效率”、“质量” 三个方面都得到了提升：

• 在 “业务” 方面，我们统一了工程实施范式，规范了团队思维模式，建立了从行业通用模式到企业个性化的渐进式逻辑体系
• 在 “效率” 方面，我们统一了组件化粒度，建立了标准组件库，提高了复用性
• 在 “质量” 方面，我们统一了逻辑堆叠体系，编程思维和代码书写方式，提高代码质量的同时统一了用户体验，降低跨模块使用门槛，降低用户学习难度

积木式开发体系适合的场景如下图所示。

积木式开发体系也不是银弹，不能适合所有的软件开发。积木式开发适合于 重复性工作多 、 规律性强 、 界面一致性高 、 逻辑课堆叠 的场景。具体表现在界面、实体等复用多的地方。企业应用为了提高工作效率，通常会以各种维度将信息整合在一起，比如顾客、订单、商品、价格、合同、收款等多种实体会相互串联，形成一个无处不通的网状结构。而对于类似 Word、Excel 或者 Photoshop 这种 界面超级复杂 的，或者 纯数据科学、算法 则不太适合。

关于更多的积木式开发体系内容，请关注我接下来的系列文章。

作者介绍：曹荣权，国双技术总监，先后供职于猫扑社区、亚信科技移动事业部。5 年创业经历，2016 年加入国双科技。熟悉客户关系管理、数字营销、忠诚度管理等多个领域，经历涵盖电信、能源、航空、餐饮等行业，是国双积木式研发体系的布道者。