头图 | 作者绘制并授权CSDN使用
我知道你可能看不懂这篇文章，但值得分享，未来就在那里。
正如你所看到的，在过去的几年里，变化很快（我已经说得很糟糕了）。 例如：
经过近几年与公司领导、同事、社区负责人等的一系列技术探讨，开始云代码开发后，我有了一些新的顿悟。 所以，我读了这篇文章。
在您对继续阅读失去兴趣之前，让我陈述第一个结论：
云开发是一种诞生于云端的闭环+编码的软件开发方式。 它允许业务人员、开发人员、运维人员等在同一个云上进行协作，透明地完成整个软件生命周期（需求、设计、编码、构建、部署、运维），而不是彼此孤立，或者需要不止一个软件来完成工作。
所以云开发解决的问题是：如何以更高效的方式开发软件？
作为v0.1.0的定义，我对它的定义可能不是很准确，但有几个关键点：
你看，我们过去解决了一个又一个的线下协作问题，现在搭建一个新的线上协作平台的时机已经逐渐成熟，是时候开始准备搭建你的云开发平台了。
我知道你想说市面上已经有这样的工具了，比如xx的xx。 但是，第一，方向错了，你认识的某家公司更懂2B； 其次，它包含了大量的功能，但没有关闭循环。 当然，这个所谓的结论，我只是从我在官方主页上看到的功能，一眼就得出了。
PS：只要不能体现我总结的核心三要素，笑~。 不符合我的理论，他们肯定是错的，说明书搞笑，逃避~。
引言一：三大核心要素
这三个要素是软件开发的要素，只有深入到要素本身，才能成为真正的云平台。
废话不想多说了，手疼。
如果基础设施真的已经是基础设施，那么你不应该在云中强调它们。 这就是为什么虽然基础设施很重要，但它不是核心要素之一。 基础设施已经是一个共同领域，作为一家时髦的公司，如果你们还没有……
微架构
微架构，即以模块化组合方式构建大型应用（前端、后端、App等）的架构方式。 每个微应用都可以独立开发、独立部署、独立运行。 相应的替换方式包括模块化、分模块、微服务、App插件化（独立构建、独立运行）、微前端等。
微架构是一种模式，它不是灵丹妙药，它以技术的方式将复杂的软件架构进行拆解，适用于复杂场景下的问题，以及人脑不够大的问题。
五年前，我和 James Lewis 写了《微服务架构》，微服务已经成为当今新项目的主流架构之一。 结合领域驱动设计的锤子，成为这几年的利器。
作为面向服务架构的一种实现方式，掌握其背后的设计和实现模型是云开发不可或缺的一环。
两年多前，我写了自己的第N本电子书《架构应用开发指南》，最近终于在国内有了一点人气。 两年前，我先后接到了阿里云和腾讯云的尝鲜（作为MVP，也没有白来），但都不够成熟，无法调用自己的云服务。 今天，越来越多的云厂商终于可以跑起来了。
面向服务的架构BAAS（as a）也是如此，或者，同理，他们将复杂的问题进一步拆解到人的能力范围内。
近年来，对于APP，开发者也探索了大量的微架构方案。 我习惯性地称它们为应用程序或“插件”，因为App作为基础，提供各种能力。 目前有以下三种呈现方式：
尽管让人们下载应用程序的成本越来越高，但应用程序平台化已成为一种趋势。
尽管App的原创性仍然占很重要的一环，但App平台的解决方案+应用插件模式的生态建设也是云开发需要考虑的重要因素。
今年是微前端大行其道的一年，微前端框架层出不穷：、Mooa、ngx-，还有《前端架构：从入门到微前端》等书籍。 让越来越多的企业开始思考前端架构的未来，也完善了丰富的微前端相关基础设施。 从某种意义上说，这是一种组件化的方式，但原始组件只是一个简单的UI组件，而当前组件是一个功能齐全的应用程序。 您只需要设计相应的管道即可完成一个应用程序的开发。
随着5G的到来，微“面向服务”的前端应用和Web的体量已经可以接受。 功能编排将成为云开发的重要组成部分——毕竟，从插件市场的日益普及可以看出一些端倪。
编码
这部分的一句话总结是：
那么，下面大概是三种完全不同的模式。
起初，我只有两个模型。 直到月初，在公司内部听到了相关的分享，得到了第三种模式：大型组织的type flow() 。
这种方法非常适合大型组织的软件开发模式。 高级工程师设计基本模型和软件架构，生成相应的方法名，以及需要的返回结果。 其实这种模式以前就存在过，剩下的就是普通开发者填写相应的代码。 结合其他基础设施，可以直接集成上线。
从表面上看，它看起来像是设计生成的代码，但设计实际上就是代码。
年初，我写了《无代码编程》。 通过这篇文章，我做了更多的无代码/低代码。 已经有大量案例表明，这是一种可行的发展模式。
无代码编程的本质是业务模型+编程模型的抽象，用特定领域的场景解决特定领域的问题。 因此，低代码编程/无代码编程只能解决特定领域和简单场景的需求，而不能解决大部分问题。
无代码编程所做的一件很了不起的事情是，它直接将业务和设计抽象为需求，实现了从需求到代码的直接访问。
DSL就是DSL，就是把一切都变成DSL。 由于我正在写一篇关于如何设计 DSL 的文章，所以我不会详细介绍：
而代码本身也应该是一种DSL，才能进一步完成云平台的提案。 需求、设计、代码、构建、部署、运行都应该抽象成DSL，完成一个真正的云平台。
协作设计文化
软件开发是集体行为，软件设计也是集体行为。 因此，一个好的云开发平台应该融入相互协作的基因。
采用了敏捷，但还是不敏捷，部分原因是：部门墙。 对于非互联网公司（大多数互联网公司都是如此），开发一个软件往往需要多个部门：业务部、技术部、测试部、市场部……
根据我多年的阅读经验，人们采用和开发失败软件的原因不外乎两点：“缺乏协同设计”和“知识转移”。 对了，还有技术水平，不是那么重要。
而“DDD（ ）”和事件风暴，正是软件开发文化的一种实践。 通过协同设计，知识被转移到满足每个人需求的妥协应用程序中。
可能是我对中泰的误解。 我习惯性地称中泰为“清不空的垃圾收集箱”。 然而，它却做了一件不可思议的事情，将“基础设施服务”变成了独一无二的服务。 好吧，戏弄到此结束。
随着中台建设的进一步完善，大量的基础设施将从原来的业务部分统一到这个~~垃圾回收站~~大平台。
有了这个基础部分，我们就可以进入下一步了。
引言2：编程的本质
好了，废话不多说了，先再回答一下那个问题，软件开发怎么才能更高效呢？ 那么，首先我们要解决那个问题：如何解决人类智商不足的问题？
解决复杂问题
因此，首先，让我们介绍解决复杂问题的框架。
PS：复制粘贴大法好，一时爽，一直爽。
有了这个框架，我们得出第一个结论。 对于编程，我们的关键问题是：如何把复杂的问题复杂化？ 因为简单的问题简单，复杂的问题容易解决。
对复杂问题的回应
什么是复杂问题？
引用公司老板的三句话：
这三个问题的答案并没有免费对外开放，有兴趣的可以咨询我——其实都在这篇文章中。
看完文章再回去复习题目。
大型组织的软件开发模型
为了解决上述问题，对于大型组织来说，首先采用的模式是：拆解。
就目前的情况而言，这些部分之间存在一些分歧。 代码对架构作出反应，架构实现代码。 缺乏相应的架构守卫、质量门等，Yu等工作由机器完成。
云开发
嗯，看到这里也不容易。 因为剩下的内容已经不重要了。
什么是云开发？
再一次，让我们看一下定义：
云开发是一种诞生于云端的闭环+编码的软件开发方式。 它允许业务人员、开发人员、运维人员等在同一个云上进行协作，透明地完成整个软件生命周期（需求、设计、编码、构建、部署、运维），而不是彼此孤立，或者需要不止一个软件来完成工作。
因此，它不同于云主机/远程主机开发模式，只需要一个浏览器/客户端/IDE就可以在线完成：
举起我的炸栗子：
它基于这样的原则：
你想要的就是这么简单。 对于开发，只对应领域建模、详细设计、填空开发。
如何搭建云开发平台？
成熟度模型
从定义上来说，我们可以将其分为五个阶段：
第一阶段。 可以依靠人群战术来实现。
第二阶段。 依赖于抽象的软件开发模式。
第三阶段。 证明自己，体力劳动。
第四阶段。 进一步抽象软件开发。
第五阶段。 将人为的部分抽象出来，智能地完成。
那么，嗯，完成这个系统的设计大概需要N个小时。 毕竟，云开发是一个复杂的问题。 我们需要不断拆解系统，将微架构、编码、协同设计三大核心要素结合起来，才能不让我们消失在历史的长河中。
云开发平台的基石
虽然我一直在强调实现只是一个细节，但是对实现机制有一个大概的了解还是很有必要的。
编码环境+设计环境。
微信小程序、支付宝小程序、在线Web IDE、VS Code/几乎成为自定义编辑器/IDE的最佳选择。 这么看，不努力，可能会失去前途，就像当年一样，笑~。
这方面的技术在业界已经相当成熟了，不就是加上一些插件吗。
但是，它们只是一些功能的堆叠，缺乏闭环设计：
大家知道，提交信息规格书是一个表单，可以和需求关联起来； 如您所知，领域建模是一种形式，允许代码与设计相关联。
虽然，在文章的开头，我说过基础设施并不重要。 但是当我们真正需要实施的时候，我们不得不强调它的重要性。 我们需要的东西是：
而围绕着它的，则是各种模型的精炼。
无论在哪个行业，最有价值的东西都在于原则和模式。 原则和模式用于快速提高能力，换句话说，使新手能够像高手一样工作——尽管模式被滥用。 所以：
这些就是核心、抽象、抽取、建模。
正如您可能猜到的那样，构建这样一个平台的难点不在于实施，而在于设计。 你只需要保证当前阶段的信息能够传递到下一阶段，而不是你用什么工具。
你可以使用 Jira、.或者基于 Git + DSL 的方法，只要确保它们可以与下一阶段相关即可。 一步步将信息与设计、编码、构建、部署、运维相关联，然后从运维响应需求，完成设计。
所以？
原型设计和关键因素
作为模式的拆解，我做了一个简单的分类，以便一步步实现整个系统：
需要
事实上，像上面这样的 Given-When-Then 三阶段设计就足够了。 所以在我的故事工具中，评论被用作附加信息的扩展。 使用的 DSL 已经丰富了：
# id: OGr9CObWR
# startDate: 2019-11-21T23:44:27Z
# endDate: 2019-11-21T23:44:27Z
# priority:
# status:
# author:
# title: add executable bin file
# language: zh-CN
@math
功能:add executable bin file
场景:
假设:
当:
并且:
那么:
有了这个设计，我们就可以将这个设计整合到我们的下一步中。
设计
其实UML本身也是一个很好的原型。 只需要创建一个DSL将其中的一部分转换成UML，然后在UI上结合DSL即可实现流程设计：
flow login {
SEE HomePage
DO [Click] "Login".Button
REACT Success: SHOW "Login Success".Toast with ANIMATE(bounce)
REACT Failure: SHOW "Login Failure".Dialog
SEE "Login Failure".Dialog
DO [Click] "ForgotPassword".Button
REACT: GOTO ForgotPasswordPage
SEE ForgotPasswordPage
DO [Click] "RESET PASSWORD".Button
REACT: SHOW "Please Check Email".Message
}
最近在做相应的架构设计平台，结合我的代码生成设计，将设计转化为代码。
代码
代码生成并不新鲜，有很多人在做很多事情。 写一个DSL并用这个DSL描述DSL结合编程语言生成不同的编程语言是我最近一直在做的事情之一。 这并不复杂，只是麻烦。
好吧，我花了很多时间为这一步设计了两个DSL，一个用于生成语言，一个用于单机编程DSL。
同时，对于代码，我们关注：验收标准和适应度函数。
验收标准
适应度函数
借助于此，我们可以连接过去和未来。
构造
对于持续集成，手动配置是一件坏事。 因此，我们使用as Code来抽象管道的构建。 但是，并不能真正解决问题，因为真正的软件开发是非常复杂的。 对于一个项目来说，它有太多的分支，不同的构建。 因此，真正意义上的持续建设应该采用如.
部署
事实上，技术已经足够成熟，我们已经可以实现相关步骤：
代码质量控制和自动化测试决定部署成熟度。
操作
在这一步，我不是很擅长。 以我有限的经验，现有的工具已经足够了。 唯一要做的就是收集数据、抽象模式、构建 DSL，并将它们连接在一起。
-> Code -> ，操作反馈需求。
云开发平台成熟度模型
嗯，看标题就好了。
综上所述
最后，让我们回到这张图：
这就是核心。
哦，顺便说一下，做平台是一项艰苦的工作。
作者简介：黄峰达()，CSDN博客专家。 长期活跃于，CSDN，关注物联网和前端领域。 出版《自己设计物联网》一书和《：全栈成长工程师指南》等6本电子书，翻译《物联网实战指南》。
☞朱广权、李佳琦直播线下、1.2亿人在线等。
☞ “抗疫”新招：WHO联合IBM、甲骨文、微软打造开放数据区块链项目！
☞ 用这个技巧快速搭建一个聊天机器人！
☞据说这是当代极客的【技术风向标】...
☞ 12系列旗舰有望分批发布； 美方威胁吊销中国电信在美营业执照，外交部发言人回应； VS Code新版本发布|
今日福利：在评论区留言，即可获得价值299元的“2020 AI开发者大会”线上直播门票一张。 快来动动你的手指，写下你想说的话。
您如何看待云开发？ 快来看看吧！