重庆企业网站定制,微网站制作速成法,网站设计及内容策划,潘家园做网站公司简介#xff1a; 本文将简单谈一谈基于 no-code low-code pro-code 渐进式思路的研发体系。 引子
宜搭负责人骁勇给我举过一个例子#xff0c;我们小时候逢年过节穿的衣服#xff0c;都是去裁缝店选一下材料、量一下尺寸#xff0c;等个半个来月#xff0c;讨回…简介 本文将简单谈一谈基于 no-code low-code pro-code 渐进式思路的研发体系。 引子
宜搭负责人骁勇给我举过一个例子我们小时候逢年过节穿的衣服都是去裁缝店选一下材料、量一下尺寸等个半个来月讨回来就可以穿了衣服合身又喜欢。镜头切回今天我们只需要在天猫、淘宝上看看图片、选择合适的尺寸就可以下单了第二天就可以穿上偶尔一丝不合身偶尔大街上撞衫但我们并不在意因为我们享受到了更多的便利与高效。受益于这个产业制定了很多的标准化模型比如身材模型S、L、XL、XXL我不再需要每次都去量身高尺寸现在标准化生产出来的衣服可以满足超过 90% 的需求除明星或特殊场景之外也不会费心思去量身定制。 服装、饮食、汽车乃至各行各业发展至今都已经形成非常成熟、高效的产业链软件研发行业同样如此业务需求在增长且变化快越是技术密集型的工种越容易带来人力不足的瓶颈。这就越需要更多的标准和模型的制定标准越趋于统一就越高效有时候 “放弃创造力才是最大的创造力”本质是追求普惠可以预见未来绝大多数场景将使用标准化模板通过无定制或低定制来完成业务需求。 期望的软件研发姿势
接下来就简单谈一谈基于 no-code low-code pro-code 渐进式思路的研发体系。
一、 前置概念
在开篇之前先介绍几个概念 云计算主要分为三大类服务软件即服务 (SaaS)、平台即服务 (PaaS) 和基础架构即服务 (IaaS)。
软件即服务 (SaaS) 是一种通过互联网交付应用的模式。客户能够通过 Web 浏览器访问 SaaS 应用这意味着客户无需购买、安装、维护和更新硬件或软件。SaaS 提供商负责确保一切顺利进行而且客户通常能够使用最新版本的应用。平台即服务 (PaaS) 能够提供云平台和各种工具帮助开发人员构建和部署云应用。用户可以通过 Web 浏览器访问 PaaS所以企业无需购买和维护基础硬件和软件。借助 PaaS开发人员还能采用租用的方式挑选所需的功能。采用基础架构即服务 (IaaS)企业可以通过按使用付费的方式“租用”服务器、网络、存储器和操作系统等计算资源。IaaS 提供商负责托管基础架构和处理系统维护及备份等任务这样客户就无需购买硬件或雇佣内部专家对其进行管理。
在 PaaS 层有专门用来支持应用在云上开发、部署、运行的平台称之为 aPaaS (Application platform as a service)在 aPaaS 基础上提供 no-code low-code 方式开发应用的平台称之为 hpaPaaS (High-productivity aPaaS)提供快速应用研发能力比如业务编排、逻辑编排、模型驱动、页面编排等。 以上概念加入了一些我的个人理解不同平台可能有不同解释我们接下来对比一下业内几款明星平台看能给到我们什么参考
二、 业内精品
Microsoft PowerApps微软全家桶服务集成的非常好比如 Excel全站写代码的地方都统一为 Excel 相似的概念 Formula/Fx另外 PowerBI/PowerFlow 十分强大定位 hpaPaaS (low-code)Google AppMaker谷歌产谷歌全家桶服务集成的非常好谷歌工程师文化在 SCRIPTS 体现得比较极致无论是后端、前端都使用开发生态的 JS 语法代码提示十分友好定位 hpaPaaS (low-code);Salesforce SaaS平台领头羊集 IaaS、PaaS、SaaS 与一体的云平台目前市值 1255 亿美元;Sap集 IaaS、PaaS、SaaS 与一体的云平台相比 salesforce使用的技术要新一些体验上要好一些目前市值 1577 亿美元OutSystems提供桌面 IDE最近提供的 OutSystems AI 能够辅助模型设计定位 hpaPaaS (low-code)作为后起之秀表现不俗已获得多轮融资在 2018 年估值 10 亿美元俨然成为下一个独角兽。
应用研发能力对比如下 几点产品体验感受
Google 和 Microsoft 老牌玩家玩 hpaPaaS 这一套相当得心应手体验相当讲究把自家的服务包括三方常用服务整合的非常好。OutSystems 类似微软提供多种流式编排很多时候不需要写代码同时也整合了非常多数据服务比如 Swagger 的 OpenAPI。Salesforce 和 SAP 类似从单一的应用程序到一套应用程序到一个快速应用开发平台企业协作工具再到一个应用程序容器和数据库提供提供了一套完整的生态链以 SaaS、PaaS、IaaS 的分层方式对外输出。
几点参考
高效整合才能降低成本这是所有玩家的心智不容质疑。视角要放大要能够覆盖 90% 场景必须要构建一套完整的生态链从 no-code 到 low-code 再到 pro-code 都要有对应的解决方案且要做到互相之间能够打通这是 Salesforce 和 SAP 给到的经验目前 AppMaker 和 PowerApps 主要针对表单、表格垂直领域还不能够玩大单一领域视角解决的问题有限。可视化的流式编排针对特定场景提效明显应对稍微复杂一点的场景一点也不好玩比如 AppMaker 就粗暴一点直接使用 SCRIPTS书写表达式更舒服不知道使用 OutSystems 的用户是什么感受。
三 、走过的可视化建站
很长一段时间国内兴起了很多可视化建站产品「可视化建站」是「低代码建站」的前身目标也是不用写一行代码拖拖拽拽就可以把一个站点搭建起来但更多的是从表现层前端单一领域去解决问题只能完成静态页面的效果对于真正的业务很难走完闭环。
总结一下突出的问题
纯前端思维比如数据服务接入方式缺少像 AppMaker/PowerApps 支持 DataConnectors 的统一数据接入层和各个系统没有形成有效整合。能解决的场景也有限高度复杂的企业级 CRM 系统不是通篇一律的业务逻辑高度复杂面临定制化考验稍微复杂一点的需要做的工作可能会更多甚至有时候搞不定没有享受到可视化搭建带来的福报。很多专业开发在搭建平台施展不开才华缺少专业级工具支持比如 VSCode、Git。不同角色之间不能有效的形成配合比如后端数据接口不能在可视化搭建工具中反射出来。搭建页面大多以 Schema 形式存储代码也不好 diff在运行时动态渲染也会带来性能问题。......
看到众多业内优秀的设计给我们带来了很多奇思妙想典型的 hpaPaaS 这种架构一定程度上能将我们标准化场景完全解决掉但标准化场景偏消费性质消费我们生产的物料沉淀、场景沉淀等这样的纯 hpaPaaS 平台应对企业级场景肯定会透支我们在为能活 102 年的超大型企业设计商业操作系统时不能一律求快、求简单还需要考虑灵活性、扩展性、复杂性在这套系统上要能源源不断的生产标准化的物料、场景持续将复杂性问题抽象沉淀形成一个有效的生态循环系统我们需要的是一种加强版的 hpaPaaS 平台 —— 企业级 hpaPaaS 平台。
四 、企业级的 hpaPaaS
以我们「企业智能事业部」为例做一下简单的业务分型 中后台业务大多是和表单、表格相关的这对 hpaPaaS 平台来说是好事但真正代表企业级场景特别是财务、法务等系统涉及到的表单可以用魔鬼来形容比如表单嵌套表格表格再嵌套表格存在必然有合理之处无法使用一套规则来描述强大如 AppMaker 或 PowerApps对这类问题基本无解主要是没有提供 backup 机制企业级应用最初始状态大多是定制型应用如何进化为标准化的配置型应用进一步成为解决方案或商业能力这是「企业级 hpaPaaS 平台」需要重点解决的。
将较年轻的产品 AppMaker 和 PowerApps 定义为商业级解决方案将较成熟的 SAP 和 Salesforce 定义为企业级解决方案商业级能解决大多数通用问题而企业级是要能解决更多复杂性问题面对复杂性企业级问题时我认为最起码要做到两点
将不同场景所需要的能力进行分解、分层最后通过能力的整合来应对提升灵活变通能力同时有通用方案和兜底方案多种方案之间应该遵循统一标准是打通融合的。
如果非要用一句话概括企业级 hpaPaaS 能力我认为是从 no-code 到 pro-code 的渐进式能力如下图 实现这样的「企业级的 hpaPaaS」有以下几个重难点
重难点一从 no-code 到 pro-code
以一个简单的业务系统为例来说一下这个过程。
迭代一no-code 开发
最初比较简单符合标准化的 CRUD
进行业务建模配置业务规则根据建立好的模型选择标准化 CRUD 模板直接产出预览、发布。
迭代二low-code 开发
但是有些地方需要稍作定制比如时间戳的格式化、页面上需要额外展示用户详细信息
将标准化生成的产物以可视化编辑打开修改关联字段时间的格式化方式、新增用户信息块保存、预览、发布。
迭代三pro-code 开发
随着业务复杂度变高很多业务逻辑需要写更多代码也希望代码被版本控制、进行 diff 等
将标准化生成的产物在 WebIDE 中打开编辑视图比如关联的动作定位到对应动作代码修改逻辑使用 WebIDE 提供的 git 功能进行代码对比及代码提交保存、编译、预览、发布。
no-code 和 low-code 试错成本低在创业时期我更希望使用这两种方式随着我的业务的成长价值逐渐被认可对该产品的要求也变高这时候我也愿意投入更多这时候可以采用 pro-code 方式对我的项目进行精装修这种渐进式交付能力将越来越多的被推崇。
在这过程中有一个关键点no-code 到 low-code 再到 pro-code 始终遵循的是一个标准在我需要时可以被任意方式打开。
虽然我们期望未来业务研发只有 10% 的工作需要 pro-code 来完成但 pro-code 的相关技术体系也是不可或缺的它就是一个全功能开放的底层架构no-code 和 low-code 在这之上做的更垂直化所以并不是说 10% 就不需要了尤其在做企业级研发pro-code 的存在更是一颗定心丸。
对于 pro-code 核心关键点有
WebIDEpro-code 环节设计上是可以使用桌面 IDE 的方式但未来必定属于云开发时代桌面 IDE 天然的和 PaaS 平台有割裂感过去我们担心 WebIDE 技术不成熟今天 vscode 引领了新一代的编辑器变革带来诸如 coder、theia 等功能和性能都很完备的 WebIDE 技术储备技术上没什么好担心的Git 打通企业级产品没有那么随意一般需要强管控其中版本控制尤为重要不管是 pro-code 还是 no-code最终形态都是一种代码形式的标准产物都应该托管在 Git 仓库上在必要的时候可以进行回溯和对比可视化编辑打通可视化编辑是 low-code 和 no-code 的代表功能通过 Recore 统一 DSL的技术将可视化和 pro-code 打通是 pro-code、low-code、no-code 三者之间形成互通的必要条件。重难点二服务的集成
在上面提到的产品中都有这样的一个设计无论是自家的服务还是别人家的服务通过一个集成平台将他们有机的整合在一起在任何需要的环节都能被高效的使用。 图片源自https://developers.google.com/
我们也提出 OneService 概念期望将与数据相关的接口或服务通过 OneService 集成起来打通生产中的各个环节如下图 重难点三生命力
我们设计的系统比较关心两个问题
能创造多少价值能活多久
我认为一个具有顽强生命力的系统应当在时间维度上持续创造价值有以下几个关键点
适合的土壤大风向以及政策鼓励有强烈市场需求持续标准化标准化不是一个固定结果而是一个动态过程需要有一个进化机制保证标准化的生态具有自洁能力适应行业发展行业渗透打通行业链路上下游将标准、理念融入到行业各节点能够反哺自己的生态并有助于形成规模共同成长带动行业成长行业的成长就是自己的成长。五、 未来可期
SaaS 化的平台以 SAP 和 Salesforce 为代表在欧美国家活的很滋润在中国刚起步从过去一年的变化可以看到国家越来越多的政策在鼓励中小型创新企业意味着未来 toB 市场前景广阔阿里整体风向现在也是 toB钉钉和阿里云已经在这条路上越走越稳让我们看到在 toB 这件事情上时机已经成熟而我们现在要做的就是把本土化的 SaaS 平台做好、做强。
作者开发者小助手_LS
原文链接
本文为阿里云原创内容未经允许不得转载
