在今天，“低代码” 技术已经很难被描述为一种新兴的技术服务形式了。
“低代码”这一概念，早在1982 年，便由 James Martin 在《无程序员的应用程序开发》一书中正式提出。而从 90 年代起，国外在不同的软件开发发展阶段中，都分别研究并尝试推出了对应的低代码解决方案。但真正的时间拐点，要来到 2015 年前后，随着基础技术设施的不断演进，低代码相关技术逐渐露出曙光，且微软、谷歌等巨头正式入局，低代码赛道正式打开。
同期，国内的低代码厂商也开始尝试布局，2018 年左右，互联网巨头阿里、腾讯、百度的纷纷入局，也间接为整个行业奠定了方向。据艾瑞咨询《2021 年低代码行业研究报告》中所示，截至 2020 年，中国低代码市场共有 59 起融资事件，融资规模达亿元以上者依然有 13 起之多。而同期市场规模也逐年增至 15.9 亿（2020年），据测算，该市场规模将于 2025 年达到 131 亿，未来 5 年复合增速为52.6%。
截至截稿，36 氪企服点评的低代码开发板块中，已录入国内厂商/产品共计 109 款。种种迹象都表明，低代码市场，已经逐渐行至中场。
作为一种商业服务，低代码无疑是明确的，提供完善的可视化开发界面，使用户能够以非传统开发的模式编写应用，从而实现低成本、高效率的应用开发。但对于真正的开发模式而言，低代码这一概念却是开放的，市面上的产品不论从技术方案、使用方式还是应用场景而言，都早已百花齐放。
那么，什么样的低代码平台才是更适合开发者的呢？我们不妨先从国内市面上最流行的两种低代码平台形态，来聊聊当前的低代码平台。
表单驱动 - 企业信息化的新中台
一般认为，表单驱动是作为 BPM 系统的延续者出现的，再向前溯源的话，更像是早期使用 Excel 来进行数据管理的做法：多个参与者按某种约定，通过在电脑上编辑、传递文档、信息或者任务，来实现指定的业务目标。
一些从 BPM 系统或者电子表格类产品转型而来的低代码开发平台，大多延续了这种表单驱动的模式。当前市面上主要采用这种模式的低代码平台，常见的有：简道云、明道云、宜搭、氚云、得帆云等。
表单驱动型的低代码平台自出现伊始，就有着明确的客户群体和应用场景。如果说当前哪种低代码平台最适合让从未从事过软件开发的用户能够快速的完成一款小应用的开发，那么，非表单驱动型低代码平台莫属。
表单驱动型平台的核心编辑界面其实只有两个，表单设计与流程设计，通过对表单的设计完成对其抽象数据的建模，并同步绑定数据的创建/编辑界面，再借由流程设计，来定义数据的流程状态，以及不同状态下的可操作角色，字段的可见/可编辑权限等。
在业界的通行观点中，“表单驱动”具有更低的使用门槛和技术门槛，但是应用场景的局限性更高，通常仅用于开发简单的数据填报系统，很难应用在企业级应用的开发过程中。
在理想化的企业内部使用场景中，该平台会由企业中的多个业务部门同时使用，每个部门按照自己的数字化需求来设计表单，同时参与其它部门的表单填写、流传过程。从而使企业中的每一个业务相关人员都可以在平台上看到与自己相关的所有表单，作为自己的工作任务项或关注事项。而这，也是企业信息数字化的切实需求。
为了满足上述场景，表单驱动型的低代码平台的设计思路也就变得明确了。
- 为了能够让企业的任意一个员工都能够很快上手，平台需要最大化的降低实际使用者的学习成本。在用户使用过程中，需要尽量取消抽象的软件设计过程，甚至以牺牲灵活性为代价（比如界面与动态数据的绑定设计），让用户能够与企业业务做直接对应，来达成设计目的。
- 最好是单一平台 + 多个同构微应用的模式。这样才能够有效的聚合信息，让企业信息流转效率上升。单一的表单收集型服务（如：问卷星、腾讯问卷等）虽然也能解决信息的收集问题，但对于信息同步，以及流程控制就会显得乏力，而这却是企业提升信息流转的综合效率所不可或缺的能力部分。
而表单驱动的局限也同样明显：
- 受限于表单与数据模型强绑定的设计与使用方式，在实际使用过程中，往往难以设计出拓展性佳、复杂关联的数据模型。大量的表单，一方面会形成大量的数据冗余（不同的表单设计背后所映射的是相同的业务数据），另一方面又容易形成数据孤岛（表单设计过程中的关联性设计缺失，无法在其它业务中进行数据复用）。
同时，由于表单与数据模型的直接对应，也使得对数据的展示、操作界面只能借由当前表单执行，难以设计复杂的数据检索与数据交互。 - 表单驱动型的低代码平台，通常只能处理数据的采集与展示，而无法基于数据进行更为智能化、自动化的衍生逻辑设计。为了弥补缺陷，低代码平台往往会增加一些可编程界面，以便用户通过代码途径来解决上述问题。
但伴随着编码功能的开放，平台用户的体验也会开始割裂。更真实的情况是，大量对数据建模都算不上擅长的用户，并没有匹配的技术能力来完成代码的编写。
当然，不论如何，在企业数字化场景下，表单驱动型的低代码平台依然能解决日常企业业务中大部分简单的信息流转需求。但是对于开发者而言，表单驱动型低代码平台与开发者的工作场景却往往是互斥的。
一方面，表单驱动的目标用户并不是开发者本身，甚至平台本身，就是为了在企业不具备开发能力，或降低开发成本时而出现的。
另一方面，则是因为表单驱动型平台中，应用设计模式较传统软件开发而言，进行了大量简化甚至是阉割，这导致开发者在使用表单驱动型平台的过程中，往往有大量的软件设计思想无法在平台中实现。
一言以蔽之，开发者与表单驱动，可能真的没有什么缘分。
模型驱动 - 传统软件开发的模式再造
不同于表单驱动从早期电子表格模式的逐步进化，模型驱动则是从传统软件开发模式中提炼和总结而来的。
模型驱动型平台使用可视化建模技术来定义数据关系、流程逻辑和构建用户界面，使开发人员和业务用户能够快速交付应用程序，而不需要代码。在当前市场中，如：Mendix、OutSystems、活字格、ClickPass、微搭等，都属于模型驱动的范畴。
相对于表单驱动而言，模型驱动与开发者可能要亲近许多。如果说表单驱动是为了让不具备开发能力的用户也能够开发应用，那么模型驱动，则是为开发者提供了另一套形不似但神似的开发工具。
模型驱动型的低代码平台，更像是对传统软件开发模式的业务再造，将大量原来只存在于开发者脑海中的设计模式，实际地构建出用户界面来进行设计操作。同时，平台还将开发过程中各环节的设计工作进行了范式定义，使得各设计模块可以更好的集成。
换个角度来说，模型驱动对开发者的软件设计知识要求并没有降低，而是改造了编程方式，使得以前开发者需要编写代码的工作，可以通过可视化界面来定义和配置，从而加速了应用开发的过程，提升了整体效率。
以数据模型与用户界面的绑定方式来举例：
在表单驱动的设计中，用户需要先进行表单设计，当表单确定后，对应的数据模型也会被自动推断确认完毕。自此，表单就与数据模型完全绑定，表单的修改亦会直接影响数据模型。而数据实体也仅支持表单进行修改。
但在模型驱动的设计中，数据建模与用户界面设计是完全分离的。用户可以先通过数据模型设计界面进行建模，再利用户界面设计器进行界面设计，最后通过平台的数据绑定机制，为指定的界面绑定数据模型，以实现最终的数据展示。
而这种模型驱动的绑定方式，与传统软件开发中的 MVC 设计模式，其实保持了一致的：分别设计 模型（Model）层，与视图（View）层，并通过控制层（ Controller）层来控制模型层与视图层的绑定关系。只不过，在模型驱动的低代码平台，模型层、视图层、控制层都可以分别使用可视化界面直接进行设计，而无需编写代码。
不过，如果在专业开发者的眼中，这可能会有一些开倒车的嫌疑。
无论是表单驱动，还是模型驱动，希望构建的应用设计模式都是让模型层与视图层直接产生绑定关系。模型驱动相比于表单驱动的优势，也在于其支持模型的动态拼装，让模型层与视图层的绑定关系更灵活。
但在真正的企业级应用开发中，在模型层与视图层之间，其实还存在着一层业务层。除了控制视图与模型的关系，业务层最大的作用，在于单独对业务行为进行了定义。既可以是由终端用户直接与应用交互产生的业务行为，也可以是由系统主动根据数据模型、业务特征自动触发的业务行为。
同时，业务层的出现，使得业务行为可以单独控制不同数据的处理逻辑，比如多重判断、事务管理、兼容容错等等。这也是软件工程领域中对”高内聚、低耦合“这一设计目标的直接实践。
最后，业务层通过对业务行为与数据操作进行定义，可以极大的提升模块逻辑的复用性。比如在常见的复杂业务中，往往需要对多个数据模型同时进行操作，如果无法单独设计业务层，就只能在不同的视图位置中，重复多次的设计数据模型操作过程，而重复设计过程中，些许的不一致，往往就容易导致更复杂的业务错误。
所以回到模型驱动的语境里，诚然数据模型与视图的动态绑定模式，已经像极了传统软件开发模式，甚至在做小型应用时，开发者已经能够直观的感受到效率提升。但对开发者而言，这依然不是最终的工具。
业务层的缺失，并不只是业务行为定义的缺失。使应用更具智能化、自动化的运算能力，也会因此无处安放。比如对数据的哈希摘要算法、对大量数据的批处理算法、非常规数据的编解码能力、条件化定时任务甚至是用户推荐算法、用户画像生成、多要素智能推送等，在传统软件开发中虽然屡见不鲜，但在低代码平台中，却无处施展，需要另辟它径。
当然，随着市场发展，相信各大低代码厂商依然会逐步拓展自身平台的能力版图，让越来越多的应用能力可以在自身平台中被开发者使用。但至少在今天，即便是模型驱动，也还是无法完全满足开发者的需求。
第三种可能性是什么？
虽然在国内，低代码平台主要指向表单驱动与模型驱动两大类低代码平台，但在海外，言及低代码，却是另外一番景象。
与国内低代码的普遍认知不同的是，海外更推崇的模式是将低代码能力工具化，并尽可能做到领域专属，而非全能。虽然在国外也不乏有 OutSystems、Mendix 这样的大型低代码平台，但近些年更得开发者青睐的，却是一些特定领域内的低代码/无代码服务。
在资讯网站 nocode.tech 中所收录的低代码工具中，根据工具的能力范围，将其分为如表单设计、应用设计、市场工具、客户支持工具、分析工具、自动化工具、数据库工具等在内的 37 种类型，截止目前，已收录的低代码/无代码工具服务超过 200 款。
在工具之上，国外也逐步诞生了围绕低代码工具进行应用开发的社区、教学乃至行业。通过使用多种低代码工具，并借由 API 进行拼装，使之形成完整的业务应用，也是当今流行的低代码开发趋势。有意思的是，为了提升 API 拼装效率，市场中还同步涌现了大量用于拼装 API 的低代码工具，使整体开发效率可以进一步的提升。
在国内市场，也逐渐涌现出了类似的服务形态。如低代码电子表格服务维格表，就将自己定位为面向 API 的多维表格，而软件集成服务集简云，也开始尝试提供国内各在线服务的 API 集成能力。
相比于使用独立的低代码平台，选择集成多种低代码工具，会极大的拓展应用的能力半径。在单个低代码平台中，其能力半径和应用设计界面都高度依赖于平台本身。但选择多个低代码工具相互集成的方案，则可以极大的规避这个问题。
同时，使用 API 的对接模式，也为业务深度提供了可靠保证。在传统开发中，API 的出现，使能力的提供方与使用方真正分离。我们既可以在业务应用中直接调用 API 实现能力，也可以自行编写代码来接入 API 的能力，再向业务应用提供更合适的 API。通过这样的业务封装，可以有效的保障业务的层次与隔离性。
不止如此，随着微服务架构的流行，API 也逐渐成为了企业自研应用中的一等公民。通过 API 来封装能力，体现业务，又被其他业务进行集成，一直都是传统开发中的最佳实践之一。
所以我们不免会提出这样的假设，当开发者真正迈入低代码的领域时，更合理的结合模式，依然是能力领域独立，API 先行，集成性大于封闭性的架构形态。
Methodot，API 先行的新一代开发平台
为了能够让低代码能力真正的提升一线开发者的日常开发效率，行云趣码认真的研究了大量市面上现有的低代码平台，以及海内外的行业趋势。
在开发者世界中，能够快速的补齐自己的能力短板，但又能发挥自己真正擅长的专业领域，一直都是开发者最期望出现的研发模式。而当前市面上的大部分低代码平台，虽然能够达到快速完成特定工作任务的能力，但平台本身的出现，却也对开发者原本擅长的能力，形成了限制。
能不能有一款平台，可以让开发者在享受低代码工具效率的同时，也能通过编写代码和能力集成来提升应用能力的上限呢？如果有的话，那么它不应该是一款低代码平台，而是一款富含低代码工具能力的开发平台。
Methodot 正是这样的一款一站式在线开发平台，平台本身内置了多款低代码开发工具，也同时具备完整的编程开发能力。
在 Methodot 中，开发者可以自由的选择使用低代码方式或是代码方式来完成特定工作的开发，可以是前端界面、可以是数据建模、也可以是 API 集成。与此同时，平台也上架了大量的开源低代码工具套件，让开发者按需要进行集成。
同时， Methodot 还提供了微服务架构可视化编辑器，让服务能力真正的作为了应用设计工程中的一级对象，无论是传统开发，还是低代码开发，是自研应用，还是第三方服务对接，都可以快速的进行集成，而无需担心业务系统的拓展性。
不仅如此， Methodot 还深度整合了云原生技术能力，通过对软件开发模式进行完整的再造， 集研发工具、交付引擎、运行环境三维一体，为开发者打造出了新一代的研发空间。换句话说，在 Methodot 中，可以同时进行代码编写、编译、构建，并直接进行部署直至对外提供服务，无需准备编码、调试环境，更无需单独购置服务器资源。
当前， Methodot 已经正式上线，以期为广大开发者提供传统开发与低代码开发相融合的在线开发服务。同时， Methodot 已同步推出了免费版本，并保证基础功能完全开放，欢迎广大开发者前来试用。
云原生，低代码，写得少，做得快。
这就是 Methodot，您的一站式云原生应用在线开发平台。
