no、low、pro code的区别

  • no code
    • 自己编程给自己用，给用户的感觉是一个更强大的办公/实用软件。
    • 主要的手段是用图形化操作等方式降低学习曲线。no code 一定要面向非常固定的领域才能做到好用。
  • low code
    • 编程给其他人用，为此创造了一个 citizen developer （全民开发）的概念。
    • 主要的手段是平台预制好常见的需求，减少需要从头写的代码。
    • low code 也要面向指定的领域才能让平台提前预测需求，但相比 no code 可以不把使用场景限定得那么死。
  • pro code
    • low code 的平台自己不会选择 low code 来创建这个平台本身，因为 low code 并没有降低从头构建一个系统的成本。
    • 但是 pro code 的平台自己会选择 pro code 来创建这个平台本身，比如 react 开发者会选择用 react 来创建自己的开发工具，因为 pro code 的工具和平台都是以从根本上降低从头构建一个系统的复杂度为目标的。

平台分类

一切能通过少写代码来完成业务的方式都可以纳入低代码体系。

不同的实现方式

  1. 打造Paas平台，根据jsonSchema数据直接渲染页面。中后台、客户端产品均可使用。
  2. 利用jsonSchema编译pro code。中后台、客户端产品均可使用。
  3. 设计图+机器学习直接渲染页面。基于sketch、蓝湖直接输出代码的特性实现，目前多为H5宣传页

不同的使用群体

  1. 通用型的低代码平台，接近零代码平台的体验，类似易企秀，大多是提供给公司外的用户使用。
  2. 领域型的低代码平台，主要方向是简化开发工作量，偏产品经理、项目经理使用。
  3. 给开发提供工具的低代码，

不同的使用方式

  1. 图形化拖拽
  2. 基于表单配置
  3. 设计图直出

ps：1、2均依赖规范化的jsonSchema做数据存储。

注意事项

  1. 相比独立开发一个页面，搭建场景开发可能随处都要求着严谨的设计，任何你认为的微不足道都不应该被忽视
  2. 数据模型解决方案更多只是一套开发范式，没有规范约束的搭建系统是不可维护的
  3. 独立和统一并不矛盾，虽然搭建的目的是自由组合，但在设计开发时却必须足够重视统一的思想。

核心思路

  1. 生命周期自动化
    • 低代码最吸引人的一点是，拖拉拽就可以快速预览和上线。
    • 这意味着，在这种模式之下，融合了软件开发生命周期几个步骤，需求、设计、编码、构建、部署、运营（+运维），并实现了部分的自动化。
    • 为此在这个要素上，它同理于云开发模式，只是要求的范围更大。所以，我们需要打通更多地环节，才能实现更多的自动化。
  2. 流程代码化、数据化
    • 在低代码的流转过程中，系统需要存储中间态的结构化数据，或者是领域特定语言编写的数据，以解耦不同环节。
    • 对于一个组织而言，如果计划购买一个低/无代码编程平台，那么需要一个中间态的语言或者数据。
  3. 持续完善的基础设施
    • 在实施低代码时，它需要大量的基础设施，如：
      • 大量快速可用的后端 APII
      • 分钟级部署后端 APIe
      • UI 组件集丰富
      • ……
    • 除此，过程中还会有各种的新需求接入，因此还需要不断地完善：
      • 方便与第三方服务集成。
      • 灵活性。支持多语言等。
      • 对应基础设施接入机制。

ps：复杂度同力一样不会消失，也不会凭空产生，它总是从一个物体转移到另一个物体或一种形式转为另一种形式。我们尝试降低一部分开发者得难度的同时，也意味着我们需要将这部分复杂度拉由自身来解决。

如何实现拼装

应用 => 页面 => 组件（模块） => 属性。

组件属性可配置主要依赖 json Schema描述，属性配置就是要实现一个jsonSchema规范的可视化面板，较复杂的功能点是对数组、对象类型的递归。

image.png

标准化jsonSchema

  • 版本化、语义化、渐进性描述
    • 协议有版本控制，语义清晰，保证简洁易懂，可读性强
    • 从小往大渐进性大描述组件、区块、页面、应用，实现递归嵌套
  • 不引入新概念、可与标准源码互转
    • 不引入新的语法概念，代码部分纯js语法，降低上手门槛；
    • 明确每一个属性与源码对应的转换关系，可生成跟手写无差异的高质量标准源代码
  • 可扩展、可流通、面向多端
    • 支持第三方npm包引入，增强协议描述能力的拓展性。
    • 产物能在不同搭建产品中流通，不涉及任何私域数据存储
    • 不仅能面向React，还能面向小程序、vue、Rax等移动端技术栈。
  • 国际化支持（我觉得这部分，对于公司内部使用的低代码平台来说比较次要）

ps：建议参考阿里的formilyjs，最好加上“版本号”的概念。

各低代码平台的流程架构图

incluna

image.png
image.png

MPM

image.png
image.png
image.pngimage.pngimage.pngimage.png

方舟

image.png
image.png
image.png
image.png

Formily

image.png
image.png

云凤蝶

image.png

优秀开源框架

个人看法

  1. 低代码平台多种多样，最适合中小厂去沉淀的是“面向某个领域的低代码设计”和“整合开源框架做通用的中后台低代码设计”。
  2. 考虑分阶段实施
    • 第一阶段，提供高级组件、微服务及基础工程，帮助开发人员实现“低代码”。
    • 第二阶段，全面整合第一阶段的劳动成果，达到项目经理能够配置完成的水平。（这个阶段还可以考虑自动化部署等场景）
    • 第三阶段，与市场上的一些低代码平台靠齐，做到客户能使用。
  3. 实施过程建议不要脱离生产实际，以帮助公司提效为前提，不建议憋大招。（整体方向朝着第三阶段去做）

好文收藏