低代码提高的是应用交付效率还是开发效率？

本文作者：得帆信息联合创始人兼CTO徐翔轩

最近跟几个客户和IDC分析师在探讨24-25年国内低代码市场格局变化和趋势时，发现大家对目前低代码供应商类型有不同的见解。有一类产品，即所谓的开发平台类低代码（产品），在我的认知中并不应该属于低代码产品，因为它的价值主张和解决的问题与主流低代码（含无代码）产品不同，特别是其面向的首选开发者主体，以及效率提升的方向差异非常大。

不过，关于产品分类的话题，后续等时机成熟的时候，我会专门写一篇内容表述，不是本文的讨论重点。

今天我讨论的，主要关于「低代码提升效率、低代码提效」。这是一个笼统的说法，低代码如何提升效率、提升交付效率还是开发效率，都需要约定或限定。我以前写过一篇文章《都说低代码能提升交付效率，到底怎么提升？》，在这篇文章中，我通篇用的是“低代码提升交付效率”，而不是“开发效率”。究其原因，主要是我认为，“交付效率”和“开发效率”本质上有较大的差异。

“交付效率”和“开发效率”

这里对“交付效率”和“开发效率”的概念做个约定：

• 交付效率，指数字化应用交付投产效率，并不特指专业开发者的开发效率，其交付主体不限于专业开发者，也涵盖了非专业开发者，包含：ITBP/产品经理/BA、专业开发者、业务开发者等角色；
• 开发效率，特指专业开发者程序开发的效率，即技术人员的编码效率，其交付主体锚定在专业开发者，包括：前端开发工程师、后端开发工程师、移动开发工程师、算法工程师等角色。

作为典型的工具/平台软件，低代码需要抽象化适配的场景，才能够提炼为标准化产品，以实现降低开发门槛和提升交付效率的目标。抽象意味着放弃，因此，低代码平台的标准配置类功能（无代码能力部分）通常会舍弃部分高度个性化的需求和场景（可以参考：低代码平台到底适用于哪些场景？）。

专业开发者的关注视角

专业开发者在整个数字化团队中处于最后端，会面临纷繁复杂的业务需求。在日常工作过程中，不论主动还是被动，专业开发者对个性化需求和个性化场景极为敏感，这些场景包括：性能要求高的场景、展现页面复杂的场景、交互逻辑个性的场景、安全性极致要求的场景、外部用户自注册场景等。

因此，专业开发者的关注视角与低代码平台（其中的配置部分，即无代码能力）的设计思路之间，是存在潜在冲突的。涉及到具体落地和操作层面，我们应该关注如何弥合该冲突，并力求实现1+1>2的效果。

专业开发者与低代码平台如何实现价值加成

从诸多客户的探索、实践经验来看，专业开发者与低代码平台之间的弥合以及价值的加成存在明确解法：

01

明确认知两者的差异性，确认当前主要矛盾，如果主要矛盾是数字化需求过多，团队整体产能不足，应大胆认可低代码价值并且引入该平台，先解决主要矛盾，不追求低代码平台的配置类功能能够“包治百病”；

02

在低代码平台选型时，如当前团队有专业开发者和个性化需求场景，需关注低代码平台的二次开发和扩展能力，最好能适配原生的技术开发框架、工具链，避免对专业开发者的偏好和工作方式带来较大影响；

03

开发效率的提升同样有共性方法，可着眼于技术基础设施/工具链的完善、开发规范/规约的制定、技术开发技能的提升、通用能力沉淀、必要的技术资源补充等。从实战角度看，选择大而全的技术开发平台不是最优解；

04

低代码平台引入后，应该与已有或后续可能引入的技术基础设施/工具链进行融合，包括且不限于：DevOps、CI/CD、认证&SSO、运维监控平台、通用中间件等，且应纳入到整个技术管理体系、规约中。

综上，低代码核心目标是大幅提升交付效率，并不直接提升开发效率，但我们应该通过低代码自身的开放能力和扩展能力，确保与技术基础设施、开发规约的融合，与专业技术开发形成联动，解决更多元的数字化需求场景。