写给技术管理者的低代码手册系列文章（10）——第三部分：低代码的技术原理与工程基础（第一章）

系列文章

写给那些从事技术管理工作的人员的，对于低代码手册方面的系列文章当中的第一篇，这篇文章是从软件工程所应具备的视角出发，去理解低代码所拥有的价值，以及它存在的边界，还有它未来的演进路径。

被撰写出来的、针对技术管理者的、低代码手册一书中、系列文章的第二篇、其第一部分、所讲述的是、低代码诞生那一刻的、背景情况、此乃第一章内容。

写给从事技术管理工作的人员的低代码手册系列当中的文章（3），——其第一部分内容为：叫做低代码诞生的背景的【第二章】。

提供给技术管理者的低代码手册系列文章的第四篇，其中的第一部分，是低代码得以产生的背景，具体为第三章。

供给技术管理者的低代码手册系列文章的第五篇，其属于第二部分，该部分聚焦低代码的概念、价值以及发展现状，此为第一章。

给技术管理者所写的低代码手册系列文章的第6篇，其中的第二部分，关于低代码的概念、价值以及发展现状、第二章。

写出来给身为技术管理者的人看的低代码手册系列文章当中的第7篇，此为第二部分，内容是低代码的概念、价值以及发展现状，属于第三章。

专为技术管理者编著的低代码手册系列文章之中的第8篇，此部属于第二部分内容，其聚焦于低代码的概念、价值以及发展现状，这是第四章所讲的范畴。

针对技术管理者所写的低代码手册系列文章当中的第9篇，也就是第二部分里，关于低代码的概念、价值以及发展现状的第五章。

引言

低代码，并非是以“降低技术要求”作为目标的那种开发方式，它是软件工程于长期规模化实践里，针对复杂性展开结构性收敛所形成的结果。由于系统规模、协作人数以及生命周期持续扩大，软件开发渐渐从原本依赖个人能力的活动，演变成依赖模型、规范以及工具体系的工程过程。在这个过程当中，愈加多原本潜藏于开发者经验里的决策，被外形化为结构化描述，并且由工具依据统一规则来加以执行。

在低代码平台里头，这种趋势呈现出依靠元数据作为核心的系统表达方式，系统不主要借助代码文本去描述了，取而代之的是经由模型、配置以及规则来予以定义，还会由平台在运行的时候进行统一的解释以及执行。

立足于此种主流工程实践基础展开讲述，本章会对低代码平台于技术层面能够成立的基础条件予以阐释。

第一章 背景：企业软件开发的本质是一个工程问题

低代码不是源于这般一次技术突破，也不是某类厂商主动推进的产品创新，而是软件工程于长期实践当中，被复杂性持续“折磨”以后的自然结果。当软件系统的规模持续扩大，使用年限不断延长，协作人数日益增多时，开发活动自身渐渐从解决业务层面的问题，演变成怎样去控制开发过程以及系统演进风险的工程性质的问题。

理解低代码的技术基础，首先需要回到这一长期积累的背景之中。

1.1 企业软件开发的主要矛盾已转化为工程治理问题

于企业软件开发里，项目规模的增长并非是线性的，系统复杂度的增长也并非是线性的，团队人数的增长同样并非是线性的，而常常呈现出指数级膨胀的态势。技术管理者常常会发现，功能实现这件事情本身已然不再是最大的挑战了。真正对交付起到制约作用的是系统的可控性，真正对演进起到制约作用的是团队协作效率，真正对长期维护产生风险的也是这方面。理解这个要点，乃是去分析企业软件开发现状的前提条件，也是后续去探索工程技术手段、把开发者经验进行外显化的基础所在。

1.1.1 什么是“工程治理问题”

在探讨矛盾转化以前，要先弄清楚于软件范畴内，啥是“工程治理问题”。于企业软件开发里，“工程治理问题”并非指某一特定技术难题，也不是指某次项目管理出错，而是指在系统规模增大、参与角色变多、生命周期延长之后，组织有无一套稳定机制，用以约束、协调以及控制软件工程活动的整体运行状况。在小规模团队中，诸多问题能够借助个人经验与默契协作予以解决。能当面沟通需求以进行变更，可临时做出架构调整的决定，并且质量问题能够交由核心成员来兜底。然而，当系统发展至一定规模的时候，这种依靠人员来运转的模式就会难以持续下去。一旦关键人员出现变动，或者业务节奏变快，又或者协作边界有所扩大，那么原本隐性的决策逻辑以及工作规则就会迅速失效。

其主要体现于各环节，包括需求怎样进入系统，架构怎么演进，质量怎样保障，发布如何规范，责任怎样追溯等，要是缺乏制度化支撑这些关键环节。系统便会逐步趋同于失控之态。从本质而言，工程治理所关注的并非“功能怎样实现”。而是“系统怎样被长期、稳定、可持续地建设以及维护”。这表明，工程治理问题跟传统的技术实现问题存在着根本性的差异：

工程治理方面的问题，所关注的是这样一个方面，即在系统长久的演进历程当中，怎样能够使其维持在可控的状态之内，对于这类问题予以解决时，不再是主要依靠个人所具备的能力，而是要求具备系统化的工程机制，这其中涵盖统一的架构规范、显式的约束表达、具有可追溯性的变更历史、可复用的模式封装等等，其核心挑战包含：

两类问题的对比如下表所示：

维度实现问题工程治理问题

关注焦点

如何让功能运行起来

如何让系统长期可控

主要挑战

算法、性能、bug

理解、协作、变更、传承

解决依赖

个人能力

工程机制

时间尺度

当前开发周期

系统全生命周期

典型场景

实现一个新功能

维护一个运行10年的系统

1.1.2 工程治理问题成为企业软件开发的瓶颈

于软件工程发展的早期时期，系统具有有限的规模，业务边界清晰可见，同一团队之中的开发者数量相对较少。在这个时候，开发效率主要是由个人能力所决定的，像是是否对语言熟悉，是否对框架掌握，是否能够迅速地定位问题。工具被具备的价值，也集中于提升编码效率自身。

然而，当系统步入企业级阶段的时候，系统的生命周期从几个月延长到数年，甚至超过十年，团队规模从个位数扩充到几十人、上百人，而且人员流动成为了常态，这时情况出现了根本性的改变。在这个阶段当中，开发活动开始展现出显著的工程特征，协作成本、理解成本以及变更风险，逐渐超越编码自身，变成影响系统演进的主要因素，详细来说存在四种典型表现。其核心矛盾是，以“依赖开发者自觉”的代码作为唯一的系统表达方式，已然不够用了。

1.1.2.1 表现一：理解成本的指数级增长

经过系统长时间的演进，致使其内在逻辑以及状态空间迅速地膨胀，而关键规则和设计决策常常没有以能够追溯形态的文档保存下来。新加入到开发团队里的成员，没办法借助阅读代码或者文档快速了解整体情况，一定要花费大量的时间借由试错或者询问去拼凑认知，这严重地拖慢了人员融入以及开发的节奏。

比如说，有一个运行了12年的订单系统，其代码量从刚开始的数千行，逐渐膨胀到了将近10万行。有一位新进来的高级工程师，花费了一个月的时间，才敢独自去修改一个小小的功能。其中的原因是多方面的，最为典型的就是，订单状态有23种之多，然而仅有11种有文档进行说明。

1.1.2.2 表现二：协作成本的不可控放大

时有多名开发者同时对系统进行修改，若缺失统一领域模型，且没有清晰模块边界，也不存在变更感知机制，那么局部修改在集成之际就容易引发冲突。此问题常常于测试阶段乃至上线阶段才会显现出来，修复所需成本极为高昂。其根源在于协作过程当中缺少预设之“交通规则”，每个人倘若都自行其是，几乎就注定了冲突必然难以避免。

比如说，有两名开发者，他们同时对订单审批流程进行修改，其中一人给核心代理商增添了快速通道，另外一人则为大额订单添加了财务审批。等到合并之后，VIP大额订单既要走快速通道又要进行财务审批，这种逻辑矛盾一直到测试阶段才被发现。这两人都是直接去修改各自的功能代码，而没有依据统一流程模型来协作。

1.1.2.3 表现三：变更风险的连锁反应

当系统模块之间的耦合较为隐晦，依赖关系不透明时，一个看起来颇像是局部的变更，却常常会引出连锁影响，这就使得开发者难以准确地评估修改的范围，常常会遗漏掉边缘或者历史功能，变更所耗费的时间远远超过预期，即便上线之后仍然很容易出现缺陷。

譬如，开发者于修改商品差异化定价的逻辑之际，意外对促销模块造成了影响，缘由是该依赖关系并非呈现于代码或者文档内，而是借助运维团队所管理的数据库触发器达成了联动。

1.1.2.4 表现四：知识传承的断层

关键业务规则，其设计初衷以及历史决策，高度依赖核心成员脑子中的记忆，并未转化成能让团队共享，且可进行持续维护的资产。一旦出现人员离职的情况，这些所谓的“隐性知识”就会跟着消失不见，团队只能借助代价高昂的反向工程以及猜测，去重新挖掘其中的逻辑，这对系统的长期健康构成了严重威胁。

对于示例来说，在核心开发者离开对应公司之后，团队面临着好多处那种很是神秘的代码，比如说订单金额一旦超过了10万就会自动发送邮件这样的规则呢为啥会出现，其根源是不清楚的，还有那个被标记为“特殊检查”的配置项，它所代表的含义是不被知晓的等等状况。因为欠缺相关文档做支撑，团队在对相关功能进行维护之际，耗费了相当长的一段时间，才算是好不容易勉强理解了其背后的意图。

1.2 亟需软件工程技术将开发者的经验外显化

于企业级软件系统里，工程治理问题的核心矛盾所在，乃是长久积淀的开发经验极度隐性，散布于少数核心开发者的脑海之中或者零散的文档之内。这些经验涵盖业务规则、关键约束、设计决策以及模块间的依赖关系。要是没办法把它显式化，团队在理解、协作、变更以及知识传承方面都会遭遇巨大风险。所以，软件工程技术得把隐性经验转变为可管理、可验证、可追踪的工程资产，进而为长期可控性奠定基础。

1.2.1 从“隐性经验”到“工程资产”

在上面的文字里，我们讲述了工程治理问题于企业软件开发范畴所引发的四种典型挑战。其关键缘由是长时间积攒的开发经验，常常存于个别核心开发者的头脑或者零散的文档之中，并非以一种系统能够理解、能够操作的形态存在。把这些经验予以外显化，达成团队内部的共享以及长期能够追溯，就意味着要让系统规则和设计约束从开发者个人经验里独立出来，从而形成团队共享、长期能够追溯的工程资产。

比如说，于多模块订单系统里，把“VIP客户大额订单需财务审批”这一规则进行显式建模后，开发者在对其他订单逻辑作出修改时，能够迅速察觉到潜在冲突。不光如此，经验显性化不但降低了理解以及协作成本，还使得系统规则能够被追踪、能够被验证，进而形成可管理的工程资产。

1.2.2 从“工程资产”到“工具约束”

一旦经验经转化成为显式工程资产，接下来的步骤乃是予以运用，用于系统化复审以及硬性约束，并非单纯依靠人工判断。仅仅凭借阅读文档或者代码，依旧存在遗漏风险，特别是在多团队并行开发的环境当中。显式资产能够达成：

通过这样一种机制，经验脱离静态文档或者开发者脑海，转而成为能够计算、可以执行的系统资产，开发者从被动依照经验转变为主动依靠系统资产，进而在不额外增添工作量的情形下，明显减少人为失误以及跨团队冲突。

1.2.3 从“工具约束”到“工程范式与管理方法”

那种需要最大化释放显式资产跟自动化审查机制价值的情况，它的关键点成了需要看怎样把它转换成能被复制的工程范式以及管理方法，这可不单单是技术方面的问题呀不过其范围还涉及到组织流程这块还有治理体系呢，工具跟约束得和开发规范、协作流程以及生命周期管理严密联系到一块这样以便构成那种可以推广、能够持续的工程方法，在这个层面进行实际操作的时候一般得依据团队自身的特点去专门定制，其中比较典型的做法是像下面罗列的这样：

经过上述那些步骤，经验不但被显式化以及工具化，而且还进一步形成了能够被复制的工程范式与管理方法。团队不再去依赖个体记忆或者主观判断，并且也不局限于代码和文档这类传统载体，而是借助更高层次的结构化资产、自动化约束以及规范化流程，把长期积累下来的工程智慧固化成可持续的组织能力，为企业软件的长期可控性提供坚实的基础，还为进一步探索元数据驱动的技术路径奠定了前提。

1.3 从显式工程资产到元数据驱动的探索

把经验予以外显化，借助工具开展自动化审查，进行约束执行，最终构建成范式的那样一种方法，已然变成企业软件能够长期保持可控状态的关键工程实践。怎样把显式的工程资产做到“结构化、可操作化”，从而形成一种具备可持续性，、可治理性的系统化方法呢？这恰恰就是朝着元数据驱动（Metadata-driven）方向展开探索的起始点。

1.3.1 元数据驱动的关键理念

用来描述数据的数据称作元数据，相较于语境单一且限定用途的代码，元数据更适宜用于承载多样化的工程资产，在理想条件之下，我们能够把系统运行所需的所有规则、模块关系、约束条件以及设计决策都抽象成结构化的元数据，开发活动并非直接依赖代码或零散文档，而是借助工具对这些元数据进行解析、验证与执行，这种以元数据驱动运行的模式即为元数据驱动，其关键理念涵盖：

比如，于一个订单跟库存系统里，VIP客户的审批规则，库存校验逻辑，价格策略等，都以元数据形态定义于统一的模型之中。开发者在增添功能之际仅需要增添元数据，系统能够自动解析该元数据跟既存的别的元数据，自动开展约束校验，保证新增逻辑不会破坏已有规则。如此一来，团队从“依赖经验以及手工审查”转变为“依赖结构化模型以及自动化验证”，明显降低理解成本以及变更风险。

1.3.2 元数据驱动的工程价值

元数据驱动，它不单单只是技术手段，而且更是工程实践的某种延伸，其价值主要是体现在三个方面，这三个方面分别是：

依赖元数据驱动，显式工程资产由静态记录转变为动态可操作资源，开发者可围绕这些资源协作，工具也能围绕这些资源进行协作，同时开发者和工具还能围绕这些资源进行验证，并且开发者和工具还能围绕这些资源执行，借此切实把经验从个人脑海以及散乱文档中解放出来，达成企业软件工程治理的结构化，达成企业软件工程治理的可控化，达成企业软件工程治理的可持续化。更关键的是，这些元数据自身拥有可执行的特性，可以直接作用于约束检查等环节，一步达成目标。

1.3.3 元数据驱动在软件工程中的地位

以元数据为驱动的实践，其影响可不单单只改变了技术实现手段，而是有一种更为显著的效果尽显于前，提升了工程治理能力。透过把系统规则、结构和约束清晰地显现出来，采用元数据驱动此方法可有妙处，能在自动化审查时起到作用，于执行约束之时发挥效能，在依赖分析方面展现价值，借此让企业在开展复杂系统的开发工作时，在系统维护期间，以及系统不断演进进程里，皆能够维持一种高度可控的状态。

在企业数字化范畴之内，存在着诸多关键场景，其中涵盖 IT 资产管理，数据治理，业务流程建模以及系统配置管理等，在此种情形下，元数据驱动已然成为大型复杂系统开发时的重要实践方式，它不但使得系统规则跟约束从隐性经验那儿实现解耦，还提供了具备可验证性、可追踪性的工程资产，进而让开发者能够于统一标准之下展开协作，降低理解所需要耗费的成本，减少变更所带来的风险以及降低知识传承出现断层的可能性。在展现形式那里，绝大多数元数据是针对专门业务领域搭建而成的，能够把这一类元数据看作等同于领域特定语言（DSL）；还有一部分元数据自身运用的是通用的语言，也就是通用语言。

实际上，元数据所驱动的价值以及成熟程度已然在较多软件领域之中获得了充分的验证。

BPMN流程HTML页面ORM映射RDLX报表

企业借助 BPMN 元数据，来定义流程节点，定义触发条件，定义责任人，系统依据元数据，自动执行审批，自动执行任务分派，自动执行状态流转，流程修改，即时生效，无需手工去调整业务逻辑，从而实现流程可控性以及快速迭代。

界面的布局，以及表单字段，还有校验规则等，均借助元数据来配置，前端平台依据元数据生成完整的页面，像基于 HTML 的 Web 页面，以及基于 XML 的 Android 原生界面等，修改布局或者样式，仅仅只需调整元数据就行，这降低了前端开发以及维护的成本，与此同时保证了界面的一致性以及规范化。

由元数据对数据库表结构、字段约束以及关联关系予以描述，ORM 或者自动生成工具依据元数据来创建表、接口以及校验逻辑，拿.NET EntityFramework、Spring JPA等这事来说，使其确保数据一致性以及约束完整性，与此同时降低手工操作的风险。

基于元数据配置实现报表模板 ，以及维度与指标 ，使得 BI 系统能够自动生成报表 ，并且自动生成大屏。业务分析人员能够迅速调整视图 ，也能够快速调整指标。业务分析人员无需手写 SQL ，此外仍无需编写报表代码。如此一来 ，可提高数据可视化效率 ，同时可降低错误率。

这般实践表明，元数据驱动并非仅仅在单一技术的层面适用，而是得以涵盖企业软件开发、运维以及分析的多个维度的环节。借助把系统核心规则、约束以及依赖关系予以显式化的方式，企业能够达成跨模块协作、迅速应对业务变化，并且为长期的可持续演进提供稳固基础。

当代企业软件工程领域，元数据驱动渐成可控性以及工程治理能力的关键标识，它使系统的长期一致性、透明性与可验证性，从仅单单凭借开发者经验，转而依靠统一的工程资产和可执行规范。此方法不但于实践里证实了可行性，还为进一步探寻自动化、智能化的软件构建模式给予了稳固基础，为后续低代码等技术路径的运用铺平了路途。

相关标签： # 低代码 # 技术原理 # 工程基础 # 企业软件开发 # 元数据驱动