低代码开发是一种快速开发应用软件的方式。使用这种方式，开发人员只需要编写少量的代码，甚至完全不写代码，大部分工作都是使用图形化、拖放式的界面完成。

“低代码”（low code）一词最早是由市场研究和咨询公司 Forrester 在 2014 年提出，用来指代那些用图形化界面简化软件开发工作、降低开发门槛的工具平台。

低代码平台的逻辑，就是把应用软件中常见的基本功能、逻辑、界面，封装成一个一个乐高积木一样的基础组件，开发时，只需要用图形界面把这些“积木”组合起来，就能实现复杂的应用软件。

组装积木的工作，甚至可以由业务人员、领域专家自己完成。

如果应用比较复杂，那么有些功能，可能无法通过组合已有的积木来实现。这时，就可以让专业的开发人员编写代码、开发新的积木，以插件的形式把新的积木装回低代码平台中，来实现那些功能。这一部分代码，就是低代码中的“少量代码”。

为什么我们需要低代码开发

近年市场上出现了各种低代码平台，比如国外的 Outsystems、Mendix、Zoho Creator，国内的 ClickPaaS、APICloud，等等。

这些低代码平台的的出现，是因为有越来越多的企业 - 无论是正在数字化转型的企业，还是所谓的数字原生企业 - 需要大量持续迭代的应用软件系统，来适应数字时代瞬息万变的商业环境。

开发这些应用软件系统，如果使用传统的开发方法，需要专业开发者，成本高，时间也长。相对而言，低代码开发是一种门槛更低、更便宜、更快的开发方法。

低代码开发大量使用图形化界面，降低软件开发的学习门槛。根据 Mendix 的数据，70% 的之前没有编程经验的用户，能在一个月内学会低代码开发。

低代码平台也能让专业的开发人员提高效率。传统软件设计开发的思维方式、模型，在低代码平台中仍然适用。与此同时，低代码大量的可复用组件，内置的通用功能和管理功能，大大节省了开发人员的时间。

典型的低代码平台长什么样

一个低代码的平台，至少要包括图形化的开发环境、开放的数据集成能力、以及应用软件生命周期的管理工具。

图形化的开发环境是低代码平台的基础，是它们被称为低代码的必要条件。

如果从数据的视角出发，开发一个业务应用软件，我们通常要回答这些问题：系统里会存储什么数据；谁用什么方式录入这些数据；如果不需要人工录入，数据是怎么产生的；在存储之前，数据要经过哪些加工，会产生什么新的数据；谁能够查看这些数据，以什么方式查看。

使用低代码平台提供的图形化开发环境，开发者可以在不写代码的情况下，回答上面的问题：建立软件的数据模型；编辑软件界面（UI），设定数据的录入和展示的方式；定义数据的加工逻辑，编排工作流。

数据集成能力， 对于低代码平台来说，是必不可少的，这是因为企业的业务应用软件不会独立存在，它一定是要跟其他系统连接和进行数据交换的。

它可能连接客户所在的社交媒体、电商平台，可能要通过某个第三方支付工具完成收款，也可能要访问企业内部其他系统中的业务数据。

在低代码平台中，跟外部系统的集成通常被设计成插件系统。一个插件就实现跟某一类或者某一个外部系统的数据交换。它们被称为连接器（connector）。

低代码平台要内置很多连接器，连接常见的数据源和应用软件、SaaS 。

低代码平台也要支持第三方、或者平台的使用者，开发新的连接器，用来与一些不在内置连接器覆盖范围的、或者企业定制的外部系统集成。

低代码平台要支持应用软件的生命周期管理。因为，就算使用“新”的开发方法，软件开发的过程，仍然是要管理的。一个应用从开发、测试、到部署、运维的这些步骤，并不能省略。

开发者在给应用软件增加或者调整功能时，不能直接修改正在使用中的生产版本。这是因为开发再小的功能，都有可能出错，都要经过测试和验证。

通常来说，开发者先要在独立的环境中开发完，测试没问题后，才把自己的工作提交到集成测试环境中测试，最后才能发布到生产环境中，真正运行和支持业务。

实际工作中，这个过程可能包含更多的步骤和更多的环境，也可能更少，无路如何，至少是要区分开发环境和生产环境的。

如何选择低代码平台

虽然低代码平台都有上面这三个功能模块，但每个平台实现它们的方式不同，而且通常都有各自的侧重点，产品形态差别很大。

选择低代码平台，要从多方面考虑。

首先，要看应用场景。有的低代码平台在开发和生成全渠道的用户界面上更有优势，适合面向客户的应用；而有的低代码平台则更侧重于数据加工处理和工作流编排，适合用于内部协作管理的应用。

然后，要考虑使用低代码的人员。谁来使用，是专业开发者，还是业务人员？有几个人一起开发？不同的低代码平台对使用人员要求不一样，有些要求有一定的软件开发技能，有些则是完全面向非技术人员；不同的低代码平台对多人协作的支持程度也不一样，如果有多人同时开发，那么就要考察低代码平台对多人协作的支持。

第三，要看低代码平台集成外部系统的能力是否满足应用的要求，能不能集成目标用户所在的社交平台，能不能集成企业使用的其他系统。如果不满足，可否通过定制插件的方式添加新的集成能力，定制开发的成本有多高。

第四，低代码平台的性能和可伸缩性，当用户流量大幅变化时，能否调整保持服务的稳定。

第五，低代码平台能不能满足企业的 IT 治理要求。这些要求可能关于部署方式、数据的备份和容灾机制等。

第六，低代码平台对数据的处理是否满足监管需求。这取决于你所开发应用系统的用户所在地，比如面向欧盟用户时需要满足欧盟的通用数据保护条例（GDPR）。

第七，不同低代码平台的价格和收费模式不一样，要结合你所开发应用的预期用量，评估开发成本和长期的维护成本。

第八，低代码应用的可迁移性。跟传统开发方法不同，低代码开发需要使用某个厂商开发的特定低代码平台。使用低代码平台开发的业务系统，后续的迭代更新，也依赖于低代码平台，也就是依赖于该厂商对自己产品的维护。要减轻这种厂商锁定的程度，在选择低代码平台时，就要考虑低代码平台可迁移性。可迁移性意味着开发好的应用可以被导出成可理解、可修改的、能独立编译、部署运行在于平台无关的环境中的代码。

低代码开发的前景

低代码开发不会取代传统的编写代码的软件开发方式，就像操作系统的图形化界面，在发展了四十年后，并没有完全取代命令行工具一样。

但在应用开发上的效率优势，以及更广大的适用人群，会让低代码开发越来越被接受。

未来将会有更多人的工作涉及到某种意义上的编程或者软件开发，他们可能不写代码，而是通过图形化界面定制数据的采集和处理、编排工作流程，让计算机系统帮助自己和工作伙伴完成各种任务。

低代码不仅让更多人参与应用软件的开发，也让专业开发者受益。

我自己也是一个程序员，写过很多代码。使用低代码平台开发应用软件后，就不愿再用传统方法开发同类型软件了，因为低代码开发确实能减少很多低水平的重复性工作，提高效率。省下来的时间，仍然可以用来写代码，实现更复杂的、低代码方式不适合完成的功能。

所以有理由相信低代码平台的前景。正如咨询公司 Gartner 的预测，“到了 2025 年，将有 70% 的应用通过低代码来开发实现”。