写给技术管理者的低代码手册系列文章（2）——第一部分：低代码诞生的背景【第一章】
第一章 企业软件复杂度的逐步累积
1.1 从硬件导向到数据导向
早期的软件开发几乎完全围绕计算机硬件展开。机器语言与汇编语言要求开发者理解CPU指令、寄存器和内存地址，软件的表达方式高度依赖具体硬件体系结构，如SSE指令集中用于比较字符串的pcmpistr，无法运行在不支持SSE的CPU上。这一阶段的软件极其昂贵、开发周期漫长、可复用性极低，应用范围也因此被限制在政府、科研机构和少数大型企业的核心场景中。随着电子工业的发展，计算机开始进入企业管理领域。跨行业、跨规模推广计算机应用的关键，在于找到一种足够通用的抽象方式。
1970年，来自IBM的E.F.Codd博士在ACM通讯杂志上发表的论文《大规模共享数据银行的关系型模型》，为解决这一问题提供了一种切实可行的技术路线。该路线中，现实世界中的业务单据、业务流程和管理决策，被统一抽象为数据的存储、处理与分析，而执行这些操作的软件被统称为“关系型数据库”。企业的用户只需要一个连接到数据库软件的终端，就能用一套近似于英语的、统一的语言来操作这个软件，以此实现所有的业务操作。如用户想要查询姓名中包含“李”的员工档案，需要输入 SELECT * FROM STAFFS WHERE NAME LIKE ‘%李%’ ，界面上就会呈现出纯文本呈现的员工档案信息。
图：早期的数据库服务器与操作终端
关系型数据库的出现，标志着企业软件第一次在抽象层面实现了规模化。通过关系模型描述业务实体及其关系，通过统一的数据操作语言处理不同业务场景，数据库成功降低了企业信息化的技术门槛，也显著扩展了软件需求的边界。
1.2 “壳”的出现与复杂度外溢
当数据库从档案管理走向财务、库存、成本核算等复杂业务场景时，一个新的问题随之出现：直接操作SQL对最终用户并不友好，一个业务操作需要多次打印和重复输入，导致操作员工作负荷高、出错概率大。为此，行业选择将数据库抽象为数据模型（数据模型可近似理解为数据库的结构，由数据表、列和表关系构成），在模型之上构建应用软件。这种做法很像是给数据库“套壳”，让用户操作应用，应用去操作数据库，而非用户直接操作数据库。
这一决策带来了企业软件形态的根本变化。业务逻辑开始在数据库与应用程序之间重新分配，用户交互界面成为差异化竞争的核心。随着抽象度更高的新一代高级语言（如C++、Java语言）在应用层的普及，企业软件正式进入“高级语言 + 数据库”的长期技术范式。
图：DOS时代的企业软件操作界面
然而，这种分层结构也埋下了复杂度累积的种子：
- 数据模型持续膨胀：一个小型订单管理系统可能只有十几张表，但经过几年演进后，堪比ERP的系统重，表数量可能增长到数百张
- 业务规则不断叠加：每次业务流程调整都会增加新的验证规则、计算公式和例外处理逻辑
- 交互逻辑日益复杂：从简单的表单录入发展到复杂的向导流程、多标签页面和实时校验
- 应用规模和生命周期显著拉长：企业软件往往需要运行十年甚至更长时间，期间不断打补丁和加功能
企业软件不再是一次性交付的工具，而是需要多年演进、持续维护的复杂系统。
扩展链接
写给技术管理者的低代码手册系列文章（1）——从软件工程视角理解低代码的价值、边界与演进路径
写给技术管理者的低代码手册系列文章（3）——第一部分：低代码诞生的背景
