企业级开发平台的演进

过去几年中，现代软件开发的整体环境发生了巨大的变化。回想在 2000 年代初期，产业的发展并没有那么快，技术和框架只是在稳步前进。而现在，技术发展的复杂度和多样性已经可以用超音速来形容了，出现了新的编程语言、开发工具、开发方法论等。

由于类似国外的脸书、谷歌，或国内的字节、腾讯这样的企业需要构建全球解决方案的需求越来越多，使得技术变得更加全面也更加复杂。这种超级的复杂度，是构建全球性巨大系统而必须付出的代价。但是对于相对简单的典型业务自动化系统，我们也需要这种复杂度吗？

业务应用系统是自动化的沃土

2000 年代初，电脑开始普及，在“能自动化就自动化”的格言激励下，业务自动化得到了极大的发展。这种自动化的结果就是产生了所谓的业务应用（LOB）系统。这是一个非常通用的术语，描述那些终极目的就是使得业务能更有效运行的非常重要的应用程序（大部分都是定制开发）。

通常，LOB 应用程序有下列特点：

• 特定领域 - 为特定领域的专业人员服务，而不是大众市场

• 全面的业务逻辑 - 包含大量自定义的业务逻辑和数据处理算法

• 以数据为中心 - 高度依赖关系型数据库，并且关系型数据库是应用程序的关键核心

• 丰富的 UI - 有成百上千的功能交互界面，使用相对标准的控件（文本框、复选框、按钮、表格等）

而这些业务应用系统都普遍有一些通用（与具体的业务领域不相关）的需求：

• 支持标准的身份验证机制，比如 SAML 或 LDAP

• 基于角色的访问控制

• 数据库行级别的安全性控制

• 数据更改记录和日志（数据审计）

• 与外部系统集成，提供系统间的互操作性

• 业务流引擎，支持工业标准的 BPMN

• 报表和 BI 能力

• 集成常用的服务，比如电子邮件、文件存储、搜索引擎等

• 可扩展性，随着业务增长，解决方案可以升级

对于业务应用系统的高需求促生了所谓的 “快速应用程序开发工具” 市场，关注如何使得开发业务应用程序更加高效和快速。

快速开发平台（RAD）的演进

九十年代中期，对业务自动化的需求开始呈指数型增长。因此，许多 RAD 平台应运而生，为开发业务应用程序提供了快速通道。RAD 平台将易学的编程语言和高效的开发工具相结合，编程初学者都可以在很短的时间创建基本的应用。彼时的繁荣离不开微软的 Access、Oracle Forms、FoxPro，当然还有 Borland Delphi 的贡献。在 2000 年代末期，基于当时的 RAD 平台已经开发了大量的业务系统。

后来，当时著名的 RAD 平台都错过了正在到来的网络时代，而仍然专注于桌面客户端的开发。随着 Web UI 的流行，对其可扩展性、可用性以及其他相关的需求也变得如往日桌面客户端一样重要了起来。而这些因素使得 Delphi 和其他的 RAD 工具不再流行，这些工具要么不能满足需求，要么演进太慢，没有跟上发展速度。经过几年的停滞之后，成百上千的应用系统变成了难以再继续提供技术支持的遗产项目。甚至连 “RAD” 这个词本身都变成了贬义词，不再意味着“简单易用”和“快乐开发”，而是指过时和没有前途的东西。这种状态说明 RAD 领域也同样亟需进行现代化改造。

那时，Web 开发者没有好用的 RAD 工具，同样的功能，用 Delphi 实现只需要一天，但是改造成 web 则需要一周。这种高昂的代价使得将业务系统迁移至主流技术栈成了“锦上添花”的事。很明显，新技术对于构建全部重新定义的应用系统来说是合适的，但是对于典型的业务应用（比如有上面提到的那些功能）来说，会产生不少重复的开销。这种失衡同时也表示在软件开发工具的市场中有一个未被发现的缺口，现在这个缺口已经被新一代的 Web RAD 平台占据，它们从前辈们的骨灰中崛起，是从零开始将过去的最佳实践与主流技术相结合而开发的全新平台。

RAD 平台的原理

与传统软件开发相比，使用 RAD 平台为什么会高效？其实就是一个抽象加复用的过程，RAD 平台中的这个过程，体现在不同方面：

• 基础架构：现代 RAD 平台通过使用高级别抽象的全栈框架集成主流开发技术，解决这些技术之间的底层复杂性

• 开发工具：通过代码生成、代码检查、代码辅助等技术，提供了编码规范和经验的抽象和复用

• 功能模块：将固定的功能抽象成可以重用的库、扩展组件，提供了功能的抽象和复用

架构和高级别 API

RAD 平台使用高级别的框架，为业务系统定义了统一的坚实架构。使用平台开发的业务系统中所有的边界和限制都源自于此架构，因此，深入了解架构是非常必要的。比如，开发出来的业务系统适合什么样的场景？系统的扩展性怎样？是否模块化？可以用哪种类型的数据存储？能部署在什么样的环境？向后兼容性如何？等等，也许你能想到更多的问题...

有失必有得，虽然选中 RAD 平台会限制我们对框架和基础架构的选择，但是这种预定义的架构通过提供针对业务的高级别 API 能加速业务与应用系统的开发。也就是说，框架将开发人员从底层技术中抽离出来，以便他们更专注解决业务问题。

这种使用高级抽象级别的方法在现代 RAD 平台中大量使用。在不同的编程语言环境中，有几个著名的平台：Ruby on Rails、Grails、Django、Jmix Framework、Laminas Project。

开发工具

开发工具是非常重要的部分，不仅能保证高效的开发过程，还提供了更低的进入门槛、更平滑的学习曲线，当然，还有更舒适的开发体验。这些要求其实都能做到，因为特定的 RAD 开发工具是基于平台预定义的体系架构：特定的编程语言、库、底层框架以及项目结构等。

基于对平台使用基础架构的全面和深入的理解，RAD 开发工具可以为开发者提供定制的终极便利。例如下列最常用的功能：

• 直观的可视化编辑器 - 用于新项目启动、项目配置、数据模型、UI 开发等

• 强大的代码生成 - 自动化最常用的脚手架代码和模板代码片段

• 智能提示 - 避免代码错误，包含代码自动修复

• 高级导航 - 在项目结构中的各个部分灵活切换

• 版本升级 - 通过向导式的指引迁移到 RAD 平台的最新版本

• 应用分发 - 支持部署应用系统，一键部署等

这里最生动的例子应该是 Embarcadero（前 Delphi）的 RAD Studio。另一个例子是 JHipster，这是非典型的 RAD 家族成员 - 提供了命令行工具（CLI），关注项目的启动引导，为初始化 Java 项目配置提供许多不同的选择。Jmix 平台提供了 Jmix Studio 是 IntelliJ IDEA 的插件，通过对 IDEA 的增强，提供了最好的 Java 开发体验。

功能模块

RAD 平台主要用于业务应用系统的开发。这种类型的应用有一些通用的需求，比如用户验证、数据访问限制、审计、文件存储、全文搜索、BPM 等等。RAD 平台满足这种需求是通过提供可重用的开箱即用功能或者扩展插件。

这种方案在现代 RAD 平台广泛使用。例如，Jmix 平台提供了 扩展组件市场, Ruby on Rails 提供 gems，Grails 提供 插件，Django 提供 包。

低代码开发平台（LCDP）

如果关注现代 RAD 市场及其发展，您一定听到或了解到大量关于所谓低代码开发平台（LCDP）的宣传。各种口号表达出的理念是：不远的未来将不再需要专业的软件开发人员，而只需要招聘业务主管，通过简单的拖拽或配置即可实现复杂的业务系统。因此，在上面的章节中，我们有意地没有提到任何一个低代码平台。但是如果我们说到 RAD，则不可能忽略 LCDP，因为这些平台造成了一个非常有趣的现象：将开发工具变成了开发人员的竞争对手。

在售卖给业务主管之前，低代码平台强调的主要商业价值是：更便宜、更快、质量更高。没错，虽然需要每年支付以百万计的使用费，但是由于不需要招聘专业的开发人员（费用不低），也不需要对本地运行环境进行维护，最终会获得理想的收益。在低代码平台的演示过程中，业务人员会感到非常惊讶，销售经理仅通过单击鼠标即可创建出基本的业务应用系统。给人的印象是，业务人员（即非专业开发人员）就能够对自己的业务需求进行自动化和数字化。

从技术角度来看，LCDP 与 RAD 基于同样的原理：预定义的架构和高级别 API、即用型的典型功能和开发工具。而最大的区别是低代码平台的适用范围。为了使非专业人士能创建企业级软件，LCDP 将开发过程缩减到只需要绘制流程图即可，但这种方式会牺牲很多其他的软件系统能力：协作开发、对源代码的掌控、可定制性、可扩展性、互操作性、兼容性、性能、自动测试等等。最后您可能会发现，LCDP 仅适合构建非常基本的业务系统。

现在，Mendix、Outsystems 和其他 LCDP 供应商开始尝试将系统的更多能力开放给专业开发者。但是似乎还有很长的路要走，因为目前大多数专业开发人员并没有觉得低代码平台能给自己带来什么益处。

结论

有人会说“快速应用程序开发平台”听起来太老了，是过时的技术。这一点我们也非常同意，现在这个词有很强的负面含义。为了使 RAD 技术重新具有新鲜感，Gartner 提出了新的术语：企业低代码应用平台和企业高效应用平台。但是，深入研究后仍然可以发现万变不离其宗：目的还是为了加速同一类应用系统的开发，当然，也有相同的限制。看起来像是对老牌 RAD 平台的“证人保护计划”，在新名称的掩护下仍然过着幸福的生活。

现代 RAD 框架、工具和平台的市场中产品众多，大多数都支持快速开发 Web 应用。这些产品可分为两类：一类面向专业开发人员并遵循传统开发模式，另一种是面向非专业开发人员，在低代码技术方面的先行者。第一种主要通过提供更高级别的 API 和代码生成功能来提高软件开发速度，可以使专业开发人员避免编写样板代码和通用基础功能。第二种提供了强大的运行时环境和图形设计工具，业务人员很喜欢这种方式，甚至不是因为开发速度快，而是因为这类产品提供了通过画图而不需要编码就能实现一些业务功能的能力。

关于如何选择 RAD 工具，没有人可以给出确定的建议或某些可量化的方法，在很大程度上取决于项目的功能和非功能需求。RAD 和 LCDP 同时存在表明市场对于这两种类型的工具的认知也同时存在。但是，对于某些产品，需要留意产品的定价策略和许可协议，每年的使用费可能高达六位数。而且由于并非运行在可控的部署环境，导致切换供应商的难度也非常大。

查阅更多文章，请收藏我们的博客：https://blog.abmcode.com

欢迎关注我们的同名公众号获取实时推送：