云开发：未来的软件开发方式

我知道这篇文章你可能读不懂，但是它值得你去分享，未来就在那。

如你所见，在过去的几年里，发生了快速的变化（这句话，我已经说烂了）。好比如说：

编程门槛的降低。大量的低编程能力水平可以进入这个行业（如上一篇文章）

基础设施的完善。只需要执行 ，便能完成（尽管四年前我们在项目上实践过）

云主机开发。远程开发机器，代码不在本地机器上。

多人实时开发编辑技术。诸如于 Visual Studio Live Share，可以多人实时协作编程。

5G。更快速的网络连接，更好的通信质量。

……。

在经历了与公司大佬、同事、社区大佬等的一系列的技术讨论之后，以及近年来开始云代码开发，我又有了一些新的顿悟。于是，我就撸了这篇文章。

在你失去继续往下阅读的兴趣之前，让我先说第一个结论：

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

因此云开发是一种解决方案，它解决的问题是：如何以更高效地方式进行软件开发？

作为 v0.1.0 的定义，我对它的定义可能还不是非常准确，但是重点有这么几个：

以共同协作的方式开发软件

软件开发的在线闭环

应用生命周期的代码化和可追溯

你看吧，我们过去解决了一个又一个的线下协作问题，现在构建新的线上协作平台的时机已经逐渐成熟了，是时候开始准备构建你们的云开发平台。

我知道你想说市面上已经有这样的工具，比如 xx 的 xx。但是，一来它朝着一个错误的方向前进，你知道的某公司更懂 2B；二来，它包含了大量的功能，但是却没有闭上环。当然了，我只是从官方的首页看到的功能，一眼得到这个所谓的结论。

PS：只要是它们没办法体现我总结的核心三要素，笑~。套不上我的理论，他们一定是错的，手动滑稽，逃~。

引子 1：核心三要素

这三个要素是软件开发的要素，只有深入要素本身，才能成为真正的云平台。

我不想多说废话了，手疼。

如果基础设施真的已经是基础设施，那么你不应该在云平台强调它们。这就是为什么尽管基础设施很重要，但是却不是核心要素之一。基础设施已经是一个通用域，作为一家时髦的公司，如果你们还没有……。

微架构

微架构，即以模块化的组合方式协同构建大型应用（前端、后端、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 如何设计的文章，我就不展开详细的讨论：

1. 汲取领域名词

2. 模型分析与抽象

3. 模型行为抽象

4. 寻找关键抽象

5. 场景代入

6. 实现 DSL

7. 迭代优化

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

协作设计文化

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

软件开发文化

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

业务（领域）驱动设计

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

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

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

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

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

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

引子 2：编程的本质

好了，我要继续瞎扯了，首先再次回答那个问题，如何以更高效地方式进行软件开发？那么，首先我们需要找到一个解决方案，以应对那个问题：如何解决人类智商不够的问题？

解决复杂问题

于是，首先，让我们引入 Cynefin 框架来解决复杂问题。

PS：复制和粘贴大法好啊，一时爽一直爽

简单（Simple），该域中的因果关系显而易见，方法是感知——分类——响应（Sense – Categorise – Respond），我们能够应用最佳实践。

繁杂（Complicated），该域中的因果关系需要分析，或者需要一些其他形式的调查和 / 或专业知识的应用，方法是感知——分析——响应（Sense – Analyze – Respond ），我们能够应用好的实践。

复杂（Complex），该域中的因果关系仅能够从回想中感应，不能提前，方法是探索——感知——响应（Probe – Sense – Respond ），我们能够感知涌现实践（emergent practice）。

混沌（Chaotic），该域中没有系统级别的因果关系，方法是行动——感知——响应（Act – Sense – Respond ），我们能够发现新颖的实践（novel practice）。

第 5 个域是失序，该域中不清楚存在什么样的因果关系，这种状态下人们将会恢复到自己舒服的域做决定。Cynefin 框架拥有子域，简单和混乱之间的一线之隔是灾难性的：骄傲自满导致失败。

有了这个框架之后，我们便来到了第一个结论。对于编程来说，我们的关键性问题在于：如何将复杂问题繁杂化？。因为简单的问题便简单，繁杂的问题也容易解决。

复杂问题的应对之道

什么是复杂问题？

引用公司大佬的三句话：

1. 场景多且复杂

2. 人类的智商不够

3. 语言不统一

这三个问题的答案暂不免费公开，有意者可以咨询我 —— 其实都在本文里。

看完文章后，回过头来回顾一下这个问题。

大型组织的软件开发模式

为了解决上述的问题，对于大型组织来说，采用的第一个模式就是：拆解。

资深开发人员，设计架构

中级开发人员，review 代码

普通开发人员，完成开发

新手开发人员，写写测试

而就当前而言，这几个部分存在一些割裂。代码反应架构，架构实现代码。缺少相应的架构守护、质量门禁等等，并且诸如于 review 的工作是由机器完成的。

云开发

好了，看到这里不容易。因为剩下的内容已经不重要了。

什么是云开发？

再一次地，让我们看一下定义：

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

于是乎，它不同于云主机 / 远程主机开发模式，只需要一个浏览器 / 客户端 / IDE，便可以在线完成：

实例化需求

架构、交互的设计

编码的代码化

自动集成与构建

无环境部署

人工智能运营

举起我的炒板栗：

1. （调试）输入一个 或者便可以在生产环境对应地打出日志。

2. （需求直接上线）改一个 Icon 的需求，在图标上传到 Kanban 的时候。NLP 后，自动提交到代码库，部署到生产环境。

3. （代码创建需求）把默认字体的色彩，由 #000 改成 #384452 的时候，能反触发对应的需求变更——不过就是 commit message，反向地创建需求嘛。

4. （设计同步）模型上添加一个新的字段，对应的完成前端、后端模型的自动化更新。

5. （代码构建同步）新的分支，新的 pipeline，用完即删。

6. ……

它基于这么一些原则：

1. 代码化优于过程化数据。

2. 流程自闭环优于交互。

3. 度量内建优于可视化。

要的就是这么简单，对于开发来说，只是对应于领域建模、详细设计、填空式开发等。

如何构建云开发平台

成熟度模型

就定义来说，我们可以将其划分为五个阶段：

1. 具备基本的远程编程能力及自动化部署。即代码无需在本地

2. 在云端能完成软件开发的完整生命周期。能在云端完成所有的软件开发的工作，并且配套

3. 云开发平台上的云开发平台。（自举）

4. 借助于代码化的方式，将软件开发的每一个步骤都变成代码

5. 实现开发全流程的自动优化。如自动化的蓝绿部署，自动化选择方案，自动化优化。

6. 无人编程。Human Over

第一个阶段。靠人海战术就可以实现了。

第二个阶段。依赖于抽象软件开发模式。

第三个阶段。证明自己，体力劳动。

第四个阶段。进一步抽象软件开发。

第五个阶段。抽象人工部分，智能完成。

所以，嗯，大概要 N 的时间才能完成这个系统的设计。毕竟，云开发是一个复杂问题，我们需要不断拆解系统，结合微架构、代码化、协作设计三个核心要素，以免我们在历史的长河中消失。

云开发平台基石

虽然，我一直在强调实现只是一个细节，但是还是得大致了解一下实现机制。

集成开发环境

编码环境 + 设计环境。

微信小程序、支付宝小程序、在线 Web IDE，VS Code / Monaco Editor 几乎已经当前成为了定制编辑器 / IDE 的最好选择。这样一看，JetBrains 再不努力，可能会失去未来，就像当年的 Delphi 一样，笑~。

这方面的技术在业内已经相当成熟了，不就是加一些插件嘛。

不过呢，它们只是在堆砌一些功能，缺乏闭环上的设计：

1. 需求关联设计，关联代码

2. 代码展示设计，关联需求

3. 构建关联代码，连接部署

如你所知的提交信息规范是一种形式，它可以关联到需求；如你所知的领域建模是一种形式，让代码关联到设计上；

基础设施

尽管，在文章开头的时候，我说了基础设施不重要。但是到真正需要实施的时候，我们不得不强调它的重要性。我们需要的东西有：

微架构支持

部署和构建支持

自动配置化管理

……

而围绕在它背后的是各种模式的提炼。

模式提炼

无论是在哪个行业，值钱的东西在于原则与模式。原则与模式是用来快速提升能力的方式，换句话来说，就是让新手能像以大牛一样的方式工作——尽管会烂用模式。所以：

代码的模式类库

开发流程模式

用户体验设计模式

……

这些是核心所在，抽象、提取、模式化。

全流程闭环

如你所猜想的一样，构建这样一个平台的难点，不在于实现功能，而在于设计。只需要保证在当前阶段的信息，能够传递到下一阶段即可，而不在于你使用什么工具。

你可以使用 Jira、Trello、Mingle 或者基于 Git + DSL 的方式，只需要保证它们能关联到下一阶段，即可。一步步往下，将信息关联到设计、代码、构建、部署、运营，运营再反应到需求上，就能完成上的设计。

So？

原型设计与关键因子

作为模式的拆解，我做了一个简单的分级，以便于一步步实现整个系统：

需求

事实上，采用诸如 Cucumber 一样的 Given-When-Then 三段式设计就够了。所以在我的 story 工具里，利用了注释作为额外的信息扩充。Cucumber 使用的 DSL 已经有丰富的

有了这个设计，我们可以将这个设计结合到我们的下一步设计中。

设计

其实 UML 本身也是一个不错的原型，只需要创建一个 DSL 将其中的一部分转成 UML，再结合一下 UI 上的 DSL 便能实现流程上的设计：

最近，我们在做一个对应的架构设计平台：

结合我的 https://github.com/phodal/design 用于代码生成设计，设计转为代码。

代码

代码生成并不是一件新鲜的事物，有大量的人在做大量的事件。编写一个 DSL，用这个 DSL 结合编程语言描述 DSL 来生成不同的编程语言，这便是我最近在做的事情之一。它并不复杂，只是繁琐。

嗯，我花了很多时间在设计这个步骤的两个 DSL，其中一个是生成语言的 DSL，一个则是独立的编程 DSL。

与此同时，对于代码来说，我们关注于：验收标准和适应度函数。

验收标准：

设计生成代码，代码反应设计

DSL 生成代码

适应度函数

软件质量门槛

自动化架构守护

自动化测试生成（回录）

系统演进设计

借助于此，我们才能承上启下。

构建

对于持续集成来说，需要手动去配置是一个糟糕的事情。所以，我们 Jenkins 使用了 Pipeline as Code 来抽象流水线的构建。但是，它没有真正解决问题，因为现实的软件开发是非常复杂的。对于一个项目来说，它存在过多的分支，不同的构建。所以，真正意义上的持续构建，应该采用诸如于 Pipeline as Pipeline 这样的方式。

部署

事实上，DevOps 技术已经足够的成熟，我们已经能实施相关的步骤：

1. 部署自动化

2. 部署代码化

3. 提交即上线

4. 部署自治

代码质量的控制，自动化测试，决定了部署成熟度。

运营

这一步，我还不是非常擅长，以我有限的经验来看，现有的工具就够了。唯一要做的事情是，收集数据，抽象模式，构建 DSL，串联起来。

1. 运营可视化

2. 运营中心化

3. 代码化运营

4. 运营需求化

需求 -> 代码 -> 运营，运营反馈需求。

云开发平台成熟度模型

嗯，看标题就够了。

Level 1：可追述、电子化

Level 2：全流程闭环

Level 3：云平台上的云平台

Level 4：代码化云平台

Level 5：自动化优化流程

level 6：human over

结论

最后，再让我们回到这张图上：

这就是核心所在。

哦，对了，做平台是一件苦逼的事情。

哦，不对~，这才是我的：growth-ren

引用：

Cynefin 框架部分：https://www
.infoq.cn/article/2013/10/cynefin-framework-playing-lego

GitHub 上的类型流：https://github.com/notyy/TypeFlow

无代码编程：https://www.phodal.com
/blog/low-code-programming/

微前端如何落地：https://www
.infoq.cn/article/xm_AaiOTXmLpPgWvX9y9

需求 DSL：https://github.com/phodal/story

设计 DSL：https://github.com/phodal/design

编码 DSL：https://github.com/phodal/code

来源：Phodal