在今天，“低代码” 技术已经很难被描述为⼀种新兴的技术服务形式了。“低代码”这⼀概念，早在1982 年，便由 James Martin 在《无程序员的应用程序开发》⼀书中正式提出。而从90年代起，国外在不同的软件开发发展阶段中，都分别研究并尝试推出了对应的低代码解决⽅案。但真正的时间拐点，要来到2015年前后，随着基础技术设施的不断演进，低代码相关技术逐渐露出曙光，且微软、⾕歌等巨头正式⼊局，低代码赛道正式打开。

作为⼀种商业服务，低代码无疑是明确的，提供完善的可视化开发界面，使用户能够以非传统开发的模式进行应用开发，从而达成低成本、高效率的应用开发。但对于真正的开发模式而言，低代码这⼀概念却是开放的，市面上的产品不论从技术方案、使用方式还是应用场景而言，都早已百花齐放。

那么，什么样的低代码平台才是更适合开发者的呢？我们不妨先从国内市面上最流行的两种低代码平台形态，来聊聊当前的低代码平台。今天我们着重探讨下表单驱动模式。 

表单驱动 - 企业信息化的新中台

⼀般认为，表单驱动是作为 BPM 系统的延续者出现的，再向前溯源的话，更像是早期使用 Excel 来进行数据管理的做法：多个参与者按某种约定，通过在电脑上编辑、 传递文档、信息或者任务，来实现指定的业务目标。

⼀些从 BPM 系统或者电子表格类产品转型而来的低代码开发平台，⼤多延续了这种表单驱动的模式。

表单驱动型的低代码平台自出现伊始，就有着明确的客户群体和应用场景。如果说当前哪种低代码平台最适合让从未从事过软件开发的用户能够快速的完成⼀款小应用的开发，那么，非表单驱动型低代码平台莫属。

表单驱动型平台的核心编辑界面其实只有两个，表单设计与流程设计，通过对表单的设计完成对其抽象数据的建模，并同步绑定数据的创建/编辑界面，再借由流程设计，来定义数据的流程状态，以及不同状态下的可操作角色，字段的可见/可编辑权限等。

在业界的通用观点中，“表单驱动”具有更低的使用门槛和技术门槛，但是应用场景的局限性更高，通常仅用于开发简单的数据填报系统，很难应用在企业级应用的开发过程中。

在理想化的企业内部使用场景中，该平台会由企业中的多个业务部门同时使用，每个部门按照自己的数字化需求来设计表单，同时参与其它部门的表单填写、流传过程。从而使企业中的每⼀个业务相关⼈员都可以在平台上看到与自己相关的所有表单，作为自己的⼯作任务项或关注事项。而这，也是企业信息数字化的切实需求。

为了满足上述场景，表单驱动型的低代码平台的设计思路也就变得明确了。

1. 为了能够让企业的任意⼀个员工都能够很快上手，平台需要最大化的降低实际使用者的学习成本。在用户使用过程中，需要尽量取消抽象的软件设计过程，甚至以牺牲灵活性为代价（比如界面与动态数据的绑定设计），让用户能够与企业业务做直接对应，来达成设计目的。

2. 最好是单⼀平台 + 多个同构微应用的模式。这样才能够有效的聚合信息，让企业信息流转效率上升。单⼀的表单收集型服务（如：问卷星、腾讯问卷等）虽然也能解决信息的收集问题，但对于信息同步，以及流程控制就会显得乏力，而这却是企业提升信息流转的综合效率所不可或缺的能力部分。 

表单驱动的局限同样明显

1. 受限于表单与数据模型强绑定的设计与使用方式，在实际使用过程中，往往难以设计出拓展性佳、复杂关联的数据模型。⼤量的表单，一方面会形成⼤量的数据冗余（不同的表单设计背后所映射的是相同的业务数据），另一方面⼜容易形成数据孤岛（表单设计过程中的关联性设计缺失，无法在其它业务中进⾏数据复用）。同时，由于表单与数据模型的直接对应，也使得对数据的展示、操作界面只能借由当前表单执行，难以设计复杂的数据检索与数据交互。

2. 表单驱动型的低代码平台，通常只能处理数据的采集与展示，而无法基于数据进行更为智能化、自动化的衍生逻辑设计。为了弥补缺陷，低代码平台往往会增加 ⼀些可编程界面，以便用户通过代码途径来解决上述问题。但伴随着编码功能的开放，平台用户的体验也会开始割裂。更真实的情况是，大量对数据建模都算不上擅长的用户，并没有匹配的技术能力来完成代码的编写。

当然，不论如何，在企业数字化场景下，表单驱动型的低代码平台依然能解决日常企业业务中⼤部分简单的信息流转需求。但是对于开发者而言，表单驱动型低代码平台与开发者的工作场景却往往是互斥的。

一方面，表单驱动的目标用户并不是开发者本⾝，甚至平台本⾝，就是为了在企业不具备开发能力，或降低开发成本时而出现的。

另⼀方面，则是因为表单驱动型平台中，应用设计模式较传统软件开发而言，进行了⼤量简化，这导致开发者在使用表单驱动型平台的过程中，往往有大量的软件设计思想无法在平台中实现。

⼀⾔以蔽之，开发者与表单驱动，可能真的没有什么缘分。