全栈平台

页面搭建

仅包含前端部分的 low code 平台

店铺装修

非独立页面，依附于业务系统存在的页面搭建

  • shopify
  • 有赞-微页面
  • 淘宝店铺装修

Open Source Love svg3

办公/管理系统 a.k.a no-code

声明式编程

行业综述

技术点

国外

一切改进都是源自于人类的缺陷

How we think

  • 人脑是串行的，无法有效并行思考多条线索
    • 人脑不适合思考并行执行的多线程
      • 【单线程】把共享变量的编程模式改成事务整体提交的模式
    • 人脑不适合思考同时呈现在屏幕上的多个独立的业务流程
      • 代码是按发生时间组织的，在一起的代码未必是逻辑上有关联的业务流程
        • 【按业务切分文件】阅读者应该可以按照自己的任务目标来跟踪索引，而不是默认一个按钮点击引起的处理逻辑都一定要写在一个大文件里
        • 【按变更频率切分文件】业务变更是阅读的首要原因，代码应该按照业务变更的频率来组织。会同时变更的代码应该放在一起
    • 人脑很难管理多份独立可变的状态，本质上每个独立变化的状态就是一个独立的线程
      • 驱动状态数量熵增的三大因素：
        • 因为交互体验的要求，从后端到富客户端到3d动画，状态被复制多份，越来越靠近展示层
        • 因为硬件物理的约束，内存从CPU统一寻址，到异构计算，CUDA，每个硬件核都有一层自己的内存
        • 因为数据量的增长，从统一的OLAP从库，到Data Lake，Data Mart，数据被复制成越来越多份，流水线越来越长
      • 对抗状态数量熵增的手段：
        • 【声明式数据联动】减少独立变化的状态，用表达式来表达 derived state
        • 【全局虚拟数据层】借鉴Unix的统一文件抽象，引入一层统一的虚拟数据层。尽可能把状态转化成 cache
    • 人脑很难理解新增对原有行为的剧烈变化，更习惯逐层稳定叠加。也就是人更希望“控制变量”
      • css 最大的难度在于不正交，新增一条对规则会引起意想不到的效果
        • 【局部化布局】swiftui 的 HStack/VStack/ZStack 布局规则数量少，每条规则作用都是局部的稳定的叠加
      • 性能优化往往需要破坏局部性，因为局部的自治容易引起重复劳动
        • 【局部化IO】系统自动实现 I/O 的批量等可以自动化做的全局优化
        • 【局部化IO】业务写成自治的，但是可以附加额外的手工全局调优。而不是强制要求把业务逻辑从局部抽出去

How we perceive

  • 人眼只能在狭窄的感受野里获得信息
    • 人对时间的感知是来自于对空间的感知
    • 人希望在一个屏幕内从上往下的获取时间顺序上从早到晚的信息
      • callback 的编程方式破坏了屏幕上的顺序和时间顺序的直接映射关系
        • 【协程式IO】用协程取代 callback，把屏幕上的代码撸直
      • 通过 status 字段驱动的业务状态机破坏了屏幕上的顺序和时间顺序的直接映射关系
        • 【协程式业务流程】用协程取代 status 状态机，把屏幕上的代码撸直
    • 因为感受野的限制，源代码没有空间展示所有的细节
      • 类型定义，内存分配等“细节”占用了大量的视觉区域
        • 【IDE细节隐藏】在文本上省略掉细节，由 IDE 进行补全，当鼠标移动上去的时候才展示出来
      • 人最习惯的空间整理方式仍然是层状的文件夹
        • 所有的“架构”设计，最终都是对文件夹和文件的设计。但是一个维度的静态索引（文件夹嵌套）无法满足所有可能的检索需求
          • 【IDE按需索引】由 IDE 来补全文件夹分类不能满足的索引需求，针对阅读者的任务来设计IDE索引
    • 视杆细胞容易忽略形状和顺序的差异，但是对颜色更敏感
      • 语法高亮占用了宝贵的资源，但是并没有考虑阅读者的诉求
        • 【IDE按需高亮】对于不同的任务，阅读者希望找到的重点是不同的，语法高亮应该结合任务来做

How we collaborate

  • 人与人之间最高效的沟通的方式是面对面的交互式声波震动
    • 人类低下的沟通带宽根本上限制了一个团队的规模
      • 上线速度要求越快越好，但是加人带来的边际效益递减
        • 减少开会拉齐，团队应该尽可能地自治，而不是什么都要靠 feature team 横向拉通
          • 高内聚，低耦合
            • 【静态链接包】编程工具应该提供更多的组合可能，而不是所有的组合都要在运行时用面向对象的多态来实现
            • 【按变更频率切分包】分工应该按照变更频率来确定，分工应该是明确的
    • 尽可能由最终用户，或者靠近最终用户的团队来解决问题，而不是长距离传递需求
      • 最终用户编程：直接让需求提出者自己来实现需求
        • 把“学习”内置到工具里，需要内置一个教学工具
          • 最终用户的编程工具开发难度高，成本高，投入超过了单个软件的回报
            • 【编辑器预制】把“公式编辑”，“店铺装修”等常见共性需求提前预制
        • 教学工具的目标是教学，而不是把自己标杆为更先进的生产力
          • 【教学内置】提供教学模式和生产力模式的无缝切换
      • 低代码编程：通过提前预制，把工作量前置，减少应用开发者的规模，从而可以在组织架构上把开发者内置到用户组织内部。与此相对应的是文档驱动的外包式开发。
        • “预制”来自于对共性需求的提前预判
          • 【非功能性需求云化】非功能性需求的实现，都是运行在相似的机器上
            • 操作系统
            • k8s
            • RPC 框架
          • 开发者都是人类
            • 编程工具
            • 沟通工具
          • 用户都是人类
            • 【SaaS组件】IM / 电话 / 短信
            • 【Ui组件】字处理器 / 表格
            • 【CRUD生成】惯用的展现和交互
              • 列表详情
              • 树状层级
              • 表格结构
              • 可拖拽白板
          • 【SaaS组件】相对稳定的业务流程
            • 登录注册
            • 支付
          • 行业内相对稳定的业务共性流程
            • 电商
            • HR / 招聘
            • 销售管理 / CRM

How we learn

  • 人的“归纳/理解/学习”能力高度依赖于可视化交互式地操纵与反馈
    • 帮助应该放在任务执行的地方，与其说“可视化”，不如说是“可发现”
      • 【填空题变选择题】单独的语法手册是不好使的，必须提供界面上的按钮，把填空题变成选择题，这样才能启发学习
        • GUI 设计器 / 店铺装修
        • 公式编辑器
        • 审批 / 工作流设计器
        • trigger 流程设计器
    • 人习惯于用手触碰一下对象，然后观测其反馈，从而归纳学习
      • 不可观测的行为无法学习
        • 生产环境的bug无法本地复现，我怎么找规律？
          • 【TestInProduction】tracing，大量的 tracing，流量回放
        • lowcode 平台的bug没有任何线索，除了找平台开发者，我能怎么办？
          • 不能要求用户了解所有的内部细节，“平台”要做到可依赖
          • 业务逻辑问题的定位和生产环境的bug定位一样，靠 tracing
      • 反馈太慢的行为给人的负面感受是指数增加的
        • 本地机器太慢了跑不起来，需要上公司的沙盒环境来复现问题
          • 【云IDE】
        • 改完了代码需要重新编译重新加载
          • 【LanguageServer】交互式开发的时候跳过不必要的编译
          • 【所见即所得】所见即所得的 GUI 开发，本质上就是用解释器执行，换取编译时间的缩减
          • 【HMR】重加载的时候保持页面状态

no code / low code / 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 的工具和平台都是以从根本上降低从头构建一个系统的复杂度为目标的。