云研发总览

云研发，是一种生于云上的闭环 + 代码化的软件开发方式。它可以让业务人员、开发人员、运营人员等在同一个云端共同协作、透明化地完成整个软件的生命周期（需求、设计、编码、构建、部署、运营），而非相互隔离，又或者是借助于多个软件才能完成工作。

（调试）输入一个 console.log 或者 fmt.Println 便可以在生产环境对应地打出日志。
（需求直接上线）改一个 Icon 的需求，在图标上传到 Kanban 的时候。NLP 后，自动提交到代码库，部署到生产环境。
（代码创建需求）把默认字体的色彩，由 #000 改成 #384452 的时候，能反触发对应的需求变更——不过就是 commit message，反向地创建需求嘛。
（设计同步）模型上添加一个新的字段，对应的完成前端、后端模型的自动化更新。
（代码构建同步）新的分支，新的 pipeline，用完即删。
……

它基于这么一些原则：

代码化优于过程化数据。
流程自闭环优于交互。
度量内建优于可视化。

对于开发来说，只是对应于领域建模、详细设计、填空式开发等。

云研发路线图

云研发在过程上划分为四部分：

云开发。即软件的开发流程都可以在云端完成，所有相关人员只需要一浏览器就能完成工作。
低代码。需求的变更，可以影响到代码的生成。
万物代码化。由低代码到无代码、云研发的关键技术。
云研发。某个需求的变更，能直接完成部署。如需求对数值的更改，能直接映射到代码的修改，并上线。

如果你还没有放弃此文的话，让我们继续往下走。

实施过程

总体来说，我把实施过程划分为了四步：

构建能力复用平台
精心设计胶水式框架及能力
完成生命周期闭环：定制胶水语言
建立双向反馈，以持续优化：同构

事实上，如果你熟悉 DevOps 的实施流程的话，它与这个实施过程还是相似：

闭环
建立反馈
持续优化

稍有有点不同的是，云研发的建立过程要更为精细化许多。

1. 构建能力复用平台

继续从上图中的左下角的方块讲起。近几年，中台十分火热，不断有新概念，也不被地被置疑。我并非一个中台专家，从个人的角度来看待，中台更像是一个垃圾回收站。而受部门墙的影响，大型组织下的部门的核心业务，到底不会交由中台来管理？便是另外一个问题。

但是不论中台的结果怎样，它做了一件有了不起的事情，引发了管理者对于服务复用的思考。提升复用率，意味着提升组织的整体效能，减少了一定的内部浪费。

同样的，这种复用的机制，也出现在组织内的前端基础建设、APP 基础设施建设等等。它们出现的本质就是为了提升组织级的开发效率，减少创造重复的轮子。

所以，落地组织级别的云研发有一个很大的前提是，能实现组织内的技术能力复用。这里的组织是相对的，因为大公司的某一部部门本身类似于中型公司的开发能，以此类推。所以，在公司这一级别上，他们可能会有各种重复的轮子，其主要受限于各自的场景及未来的假设之间的差异。

2. 精心设计胶水式框架及能力

技术能力复用，意味着：我们可以把上述的每个技术能力视为一个个的乐高。在构建应用的时候，我们只需要学会如何去组装它们即可。而为了组装它们，我们需要：

编制它们之间的粘合规则。
设计粘合适配层，用于防腐和适配未来的新架构。
制造各种粘合剂，以便于连接系统的各个部分。

因此，我们还需要一些支持快速粘合的技术作为支撑：

后端接口快速适配。从过程中有，微服务 -> BFF -> Serverless -> Serverless Components，直到把基础设施弱化
前端组件快速复用。这一点上便有：组件 -> 微前端架构 -> Web Components
APP 快速接入。从技术上来说有：小程序、APP 插件化、H5 等

一旦完成了这些技术能力，就可以关注于如何完善胶水层。

3. 完成生命周期闭环：定制胶水语言

只凭上述的两步，我们大可以完成一个简易的云研发系统。但是而为了系统的未来演进，还需要一些更先进的能力，以便于我们解耦各个开发过程。这样一来，我们可以轻松更换其中的组件，而不至于因为组件的替换，引起系统架构的巨大变化。

譬如，我们已经有了 Web 部分的快速开发，现在要支撑起 APP 的快速开发。我们不需要一起改动上下游的代码，只需根据定义好我们的接口，各自的改动都是独立的不受影响的。哪怕我们是通过采购的供应商，也可以轻松地替换供应商，避免供应商锁定。这样的接口包含了结构和数据，所以我倾向于 DSL（领域特定语言）来完成。

通过在线 IDE 隐藏胶水细节。
创建 DSL（领域特定语言）连接生命周期的两两节点。（PS：节点间的 DSL 是不同的）
建立起系统的闭环。如通过运营数据节点里，可以直接创建用户故事，来优化系统

尽管这些胶水语言会在前期增加系统的复杂度，但是它无往而不利。

4. 建立反向反馈，以持续优化：同构

在抽象代数中，同构指的是一个保持结构的双射。在更一般的范畴论语言中，同构指的是一个态射，且存在另一个态射，使得两者的复合是一个恒等态射。

有过使用 DreamWeaver、WinForm 等拖拽式开发经验的开发人员，都对这种形式的低代码开发有点反感。其中的主要因由有，当我修改完代码之后，无法反馈到设计上。也因此造成了一个问题，拖拽只适用于设计阶段。当后期代码发生变更时，便无法进行演进。

解决这个问题的办法，除了更新代码生成机制，还有一种方式是通过 DSL （领域特定语言）来建立反向反馈。如设计专用的工具，来将代码的修改同步设计上，同时改变架构设计的 DSL 代码。换句话来说，通过 DSL 来建立起步骤之间的桥梁。

架构同构。即已完成的代码进行解析，其生成的架构设计与模型设计是一致的。
设计同构。对已设计的前端组件进行解析，其与 UI 设计图生成的模型是一致的。
需求同构。对已编写的测试用例筛选解析，其与原始的需求是一致的。
……

简单地来说，我们要保证系统的各个节点的一致性。最终所呈现的结果是：如果节点间不一致的话，那么只能是原始需求有问题。为此，开发人员进行的代码修改，应当是通过 DSL 的形式一步步回溯，直至自动修改了需求，或者映射到需求的问题上。

所以，需要把生命周期的每一个过程都代码化。

云研发要素

微架构

微架构，即以模块化的组合方式协同构建大型应用（前端、后端、APP等）的架构方式。每个微应用都可以独立开发、独立部署、独立运行，对应的替换的方式有模块化、子模块的方式，微服务、APP 插件化（独立构建、独立运行）、微前端等。

微架构是一个模式，它不是银弹，它以技术的方式拆解了复杂软件架构，适合于复杂场景下的问题，还有人类脑容易不够大的问题。

后端：服务导向架构

五年前，Martin Fowler 和 James Lewis 一起写下了那篇《微服务架构》，微服务成为了今天新项目的主流架构之一。最近几年来，它结合着《领域驱动设计》这把锤子，已经成为了一个利器。

作为服务导向架构的一种实现方式，掌握它背后的设计与实现模式，是云研发中不可或缺的重要一环。

后端：函数即服务

两年多以前，我在 GitHub 写下了我的第 N 本电子书《Serverless 架构应用开发指南》，而在最近 Serverless 终于在国内慢慢有一点的热度。两年前，我陆续收到阿里云、腾讯云的 Serverless 尝鲜体验（作为一个 MVP 还是没白混），但是它们并不成熟，甚至于无法调用自己的云服务。而今天，越来越多的云厂商的 Serverless 终于可以跑起来了，

同理于服务导向架构 BAAS （Backend as a service）又或者是 Serverless，也是如此，它们进一步拆解了复杂问题到人能 handle 的范围。

APP：应用即『插件』

最近几年，对于 APP 来说，开发者也探索出了大量的微架构方案。我习惯地称它们为应用即『插件』，因为 APP 作为一个基座，提供了各式各样的能力。就目前来说有三种展现方式：

APP 内 Web 应用。
APP 插件化。市面上已经有大量这一类的方案，诸如于 RePlugin、Atlas、VirtualAPK、DynamicAPK。
APP 小程序。即功能以小程序的运行在容器化，即可以像 Web 容器一样实现远程更新，还能有效地控制开发商的权限，培养自己的生态。

尽管让人们下载 APP 的成本越来越高，APP 平台化成为了一种趋势。

哪怕 APP 的原生仍占很重要的一部分，但是 App 平台的方案 + 应用插件化模式的生态构建，也是云研发要考虑的重要因素。

前端：微前端与应用组件化

今年是微前端开始火爆的一年，微前端框架层出不穷：SingleSPA、Mooa、qiankun、ngx-planet，还有诸如于《前端架构：从入门到微前端》这样的书籍。它让越来越多的企业开始思考前端架构的未来，也完善丰富的微前端相关的基础设施。从某种意义上来说，这是组件化的一种方式，只是原先的组件只是简单的 UI 组件，而现在的组件是一个完整功能的应用。只需要设计好对应的 pipe，就能完成一个应用的开发。

而随着 5G 的到来，微 “服务化” 前端应用、Web Component 的体积已经变得让人可以接受。进行功能编排，将成为云研发的一个重要组成——毕竟，插件市场地不断火爆，可以看出一些端倪。

代码化

对于这部分的一句话总结是：

Given Future[Dev]
When Everything as Code，
Then you can Guard
Then you can Refactoring or Rewrite it.

然后，以下大概就是三种完全不同的模式。

设计到代码：填空式开发

起先我只有两种模式，直到月初在公司内部听到了相关的分享，Get 了第三种模式：面向于大型组织的类型流 (https://github.com/notyy/TypeFlow) 开发。

这种方式颇为适合大型组织的软件开发模式，由高级工程师设计出基本的模型与软件架构，生成对应的方法名称，以及其所需要的返回结果。这种模式事实上在过去已经有了，剩下的就是普通的开发人员去填充对应的代码。再结合 Serverless 等基础设施，便可以直接集成上线。

它表面上看它是设计生成的代码，实则设计即代码。

需求到上线：无代码编程

年初，我写下了那篇《无代码编程》，通过这篇文章，我结交了更多无代码/低代码已经有大量的案例表明，这是一种可行的开发模式。

无代码编程的本质是业务模式 + 编程模式的抽象化，以领域特定的场景解决领域特定的问题。所以，低代码编程 / 无代码编程它只能解决领域特定、简单场景的需求，无法解决大部分的问题。

无代码编程做了一件了解不起的事情是，直接对于业务和设计即需求的抽象，实现了直接由需求到代码的直达。

代码化：DSL as DSL

DSL 即 DSL，即把每件事物都变成 DSL。考虑到我正在编写一篇关于 DSL 如何设计的文章，我就不展开详细的讨论：

汲取领域名词
模型分析与抽象
模型行为抽象
寻找关键抽象
场景代入
实现 DSL
迭代优化

而代码本身也应该是一种 DSL，才能进一步完成云平台的建议。需求、设计、代码、构建、部署、运营都应该抽象成 DSL，才能完成真正意义上的云平台。

协作设计文化

软件开发是一个集体行为，软件设计也是一个集体行为。所以，一个好的云研发平台应该要融入共同协作的基因。

软件开发文化

采用了敏捷，却始终敏捷不起来，有一部分的原因在于：部门墙。对于非互联网公司来说（对于大部分互联网公司也是如此），开发一个软件往往需要在多个部门甩锅：业务部门、技术部门、测试部门、市场部门……。

业务（领域）驱动设计

以我多年的读书经验来看，人们采用开发出失败软件的原因，无非就是两点：『缺少协作设计』和『知识传递』。对了，还有技术水平不行，这个反而不是那么重要。

而 DDD （领域驱动设计）和事件风暴，正是软件开发文化的一种实践，通过协作设计的方式，传递知识，以妥协出符合大家需要的应用。

服务端服务中台与客户端组件中台

可能是我对于中台的误解，我习惯性称中台为『不可清空的垃圾回收站』。但是，它做了一件不可思议的事件，将 “基础设施服务” 化，成为了一个 common 的 common 的 common。好了，调侃到此结束。

随着中台建设的进一步完善，大量的基础设施，将从原先的各个业务部分，统一到了这个 ~~垃圾回收站~~ 大平台。

有了这个基础部分，我们才能迈向下一步。