您当前的位置:中国科学网>资讯>正文

程序员你的编程方法已过期云开发年代降临

放大字体  缩小字体 时间:2020-04-11 18:44:10 作者:责任编辑NO。蔡彩根0465

作者 | 黄峰达,CSDN 博客专家 Phodal

责编 | 唐小引

头图 | 作者绘制并授权 CSDN 使用

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

如你所见,在过去的几年里,发生了快速的变化(这句话,我已经说烂了)。好比如说:

编程门槛的降低。大量的低编程能力水平可以进入这个行业;

基础设施的完善。只需要执行 git push,便能完成 push to production(尽管四年前我们在项目上实践过);

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

多人实时开发编辑技术。诸如 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 如何设计的文章,我就不展开详细的讨论:

汲取领域名词

模型分析与抽象

模型行为抽象

寻找关键抽象

场景代入

实现 DSL

迭代优化

而代码本身也应该是一种 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 框架拥有子域,简单和混乱之间的一线之隔是灾难性的:骄傲自满导致失败。

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

复杂问题的应对之道

什么是复杂问题?

引用公司大佬的三句话:

场景多且复杂;

人类的智商不够;

语言不统一。

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

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

大型组织的软件开发模式

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

资深开发人员,设计架构;

中级开发人员,review 代码;

普通开发人员,完成开发;

新手开发人员,写写测试。

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

云开发

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

什么是云开发?

再一次地,让我们看一下定义:

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

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

实例化需求

架构、交互的设计

编码的代码化

自动集成与构建

无环境部署

人工智能运营

举起我的炒板栗:

(调试)输入一个 console.log 或者 fmt.Println 便可以在生产环境对应地打出日志。

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

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

(设计同步)模型上添加一个新的字段,对应的完成前端、后端模型的自动化更新。

(代码构建同步)新的分支,新的 pipeline,用完即删。

……

它基于这么一些原则:

代码化优于过程化数据;

流程自闭环优于交互;

度量内建优于可视化。

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

如何构建云开发平台?

成熟度模型

就定义来说,我们大家可以将其划分为五个阶段:

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

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

云开发平台上的云开发平台。(自举)

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

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

无人编程。Human Over

第一个阶段。靠人海战术就能轻松实现了。

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

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

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

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

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

云开发平台基石

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

集成开发环境

编码环境 + 设计环境。

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

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

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

需求关联设计,关联代码;

代码展示设计,关联需求;

构建关联代码,连接部署。

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

基础设施

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

微架构支持

部署和构建支持

自动配置化管理

……

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

模式提炼

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

代码的模式类库

开发流程模式

用户体验设计模式

……

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

全流程闭环

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

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

So?

原型设计与关键因子

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

需求

事实上,采用诸如 Cucumber 一样的 Given-When-Then 三段式设计就够了。所以在我的 story 工具里,利用了注释作为额外的信息扩充。Cucumber 使用的 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

}

最近,我们在做一个对应的架构设计平台,结合我的 https://github.com/phodal/design 用于代码生成设计,设计转为代码。

代码

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

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

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

验收标准

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

DSL 生成代码

适应度函数

软件质量门槛

自动化架构守护

自动化测试生成(回录)

系统演进设计

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

构建

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

部署

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

部署自动化

部署代码化

提交即上线

部署自治

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

运营

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

运营可视化

运营中心化

代码化运营

运营需求化

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

云开发平台成熟度模型

嗯,看标题就够了。

Level 1:可追述、电子化

Level 2:全流程闭环

Level 3:云平台上的云平台

Level 4:代码化云平台

Level 5:自动化优化流程

Level 6:human over

结论

最后,再让我们回到这张图上:

这就是核心所在。

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

作者简介:黄峰达(Phodal),ThoughtWorks Senior Consultant,CSDN 博客专家。长期活跃于 GitHub、CSDN,专注于物联网和前端领域。出版著作《自己动手设计物联网》,以及《Growth:全栈增长工程师指南》等六本电子书,并译有《物联网实战指南》。

【END】

更精彩推荐

朱广权李佳琦直播掉线,1.2 亿人在线等

“抗疫”新战术:世卫组织联合IBM、甲骨文、微软构建了一个开放数据的区块链项目!

快速搭建对话机器人,就用这一招!

据说,这是当代极客们的【技术风向标】...

iPhone 12系列旗舰有望分批发布;美威胁吊销中国电信在美经营许可,外交部发言人回应;VS Code新版发布| 极客头条

今日福利:评论区留言入选,可获得价值299元的「2020 AI开发者万人大会」在线直播门票一张。 快来动动手指,写下你想说的话吧。

点击阅读原文,精彩继续!

怎么看云开发?来在看一下!

“如果发现本网站发布的资讯影响到您的版权,可以联系本站!同时欢迎来本站投稿!