写给技术管理者的低代码手册系列文章(2)——第一部分:低代码诞生的背景

28 阅读4分钟

第一章 企业软件复杂度的逐步累积

1.1 从硬件导向到数据导向

早期的软件开发几乎完全围绕计算机硬件展开。机器语言与汇编语言要求开发者理解CPU指令、寄存器和内存地址,软件的表达方式高度依赖具体硬件体系结构,如SSE指令集中用于比较字符串的pcmpistr,无法运行在不支持SSE的CPU上。这一阶段的软件极其昂贵、开发周期漫长、可复用性极低,应用范围也因此被限制在政府、科研机构和少数大型企业的核心场景中。随着电子工业的发展,计算机开始进入企业管理领域。跨行业、跨规模推广计算机应用的关键,在于找到一种足够通用的抽象方式。

1970年,来自IBM的E.F.Codd博士在ACM通讯杂志上发表的论文《大规模共享数据银行的关系型模型》,为解决这一问题提供了一种切实可行的技术路线。该路线中,现实世界中的业务单据、业务流程和管理决策,被统一抽象为数据的存储、处理与分析,而执行这些操作的软件被统称为“关系型数据库”。企业的用户只需要一个连接到数据库软件的终端,就能用一套近似于英语的、统一的语言来操作这个软件,以此实现所有的业务操作。如用户想要查询姓名中包含“李”的员工档案,需要输入 SELECT * FROM STAFFS WHERE NAME LIKE ‘%李%’ ,界面上就会呈现出纯文本呈现的员工档案信息。

image

图:早期的数据库服务器与操作终端

关系型数据库的出现,标志着企业软件第一次在抽象层面实现了规模化。通过关系模型描述业务实体及其关系,通过统一的数据操作语言处理不同业务场景,数据库成功降低了企业信息化的技术门槛,也显著扩展了软件需求的边界。

1.2 “壳”的出现与复杂度外溢

当数据库从档案管理走向财务、库存、成本核算等复杂业务场景时,一个新的问题随之出现:直接操作SQL对最终用户并不友好,一个业务操作需要多次打印和重复输入,导致操作员工作负荷高、出错概率大。为此,行业选择将数据库抽象为数据模型(数据模型可近似理解为数据库的结构,由数据表、列和表关系构成),在模型之上构建应用软件。这种做法很像是给数据库“套壳”,让用户操作应用,应用去操作数据库,而非用户直接操作数据库。

这一决策带来了企业软件形态的根本变化。业务逻辑开始在数据库与应用程序之间重新分配,用户交互界面成为差异化竞争的核心。随着抽象度更高的新一代高级语言(如C++、Java语言)在应用层的普及,企业软件正式进入“高级语言 + 数据库”的长期技术范式。

image

图:DOS时代的企业软件操作界面

然而,这种分层结构也埋下了复杂度累积的种子:

  • 数据模型持续膨胀:一个小型订单管理系统可能只有十几张表,但经过几年演进后,堪比ERP的系统重,表数量可能增长到数百张
  • 业务规则不断叠加:每次业务流程调整都会增加新的验证规则、计算公式和例外处理逻辑
  • 交互逻辑日益复杂:从简单的表单录入发展到复杂的向导流程、多标签页面和实时校验
  • 应用规模和生命周期显著拉长:企业软件往往需要运行十年甚至更长时间,期间不断打补丁和加功能

企业软件不再是一次性交付的工具,而是需要多年演进、持续维护的复杂系统。

扩展链接

写给技术管理者的低代码手册系列文章(1)——从软件工程视角理解低代码的价值、边界与演进路径