笔者之前的文章介绍了 SAP 的三款低代码开发平台：

• Mendix Studio Pro

• SAP Data Intelligence Modeler

• SAP Build Apps

其中介绍 SAP Build Apps 的文章，有朋友留言：

这玩意真的比前端框架简单好用吗？！

哈哈，对于这种疑问，笔者曾经感同身受。

还记得当我第一次打开 SAP Build Apps 开发页面，想找一个和数据绑定相关功能的情景。

本来想着凭借自己的开发经验，很容易就能找到，所以笔者直接把 SAP 文档扔在一旁，按照自己的直觉去找。结果费了很多功夫没找到，最后不得不认输，老老实实去啃文档。

目前市面上很多低代码平台，最后的产出形式都是 Web 应用。

对于 Web 开发工程师来说，拿起 React 或 Vue 就像工匠拿起自己用顺手了的扳手：npm 拉一把依赖，页面展现，路由、状态、控制逻辑、构建、测试各就各位，想怎么干就怎么干。何必要费时间去学"只能开发一些玩具应用"的低代码开发平台呢？

程序员学习低代码开发，到底是不是多此一举？

笔者在使用这些低代码平台时一直在思考一个问题：它们究竟在多大程度上，增加或者说限制了我们开发所需软件的能力？

首先我们需要区分 No Code 和 Low Code 开发。前者的用户群体几乎没有技术背景、但希望快速做一个小应用出来；

Low Code 则更适合具有一定技术背景，懂一些开发技术，希望在某个特定领域用更少的编码，更短的时间实现更快交付的用户。

上述区分体现了这两种用户群体对低代码开发平台抽象度、可扩展性、可测试性和持续集成/交付的期望上限的差异。

笔者试图回忆自己使用低代码平台时的亲身经历，总结出低代码开发平台共有的一些局限性：

1. 最后 10% 陷阱

低代码开发的一大卖点，即把通用模式抽象成可视化组件与模型，拖拖拽拽就能构建出应用 80% 的功能。

问题是如果要实现的需求落在了这 80% 之外，无法用低代码工具提供的标准功能来实现，那该咋办？

笔者在 ThoughtWorks 官网读到一篇文章：

• Low-code/no-code platforms: The 10% trap and the limits of abstractions

这篇文章提出了一个所谓「最后 10% 陷阱」的理念：即使用低代码开发一个应用，前面 80% 的功能做起来行云流水，接下来 10% 遇到困难，但努力一番也能勉强解决。但剩下最后 10% 的功能无法通过低代码本身来解决。

不过这些问题我们能想到，那些世界一流的低代码开发平台的设计者们也早就考虑到了，也都有应对措施。

比如 Mendix Studio Pro 提供基于 Java Action 的后端扩展功能，能够把复杂计算、特定算法、加密、文件处理、三方 SDK 等封装成可复用的微流活动。

而其前端扩展基于 JavaScript Action，当需要在浏览器或原生端即时执行、或接入前端 npm 库时，可以把逻辑写成 JavaScript Action 暴露给纳流使用，这也是 Mendix Studio Pro 扩展前端与原生端能力的首选方式。

再看 SAP Data Intelligence Modeler，作为 SAP 产品家族的一员，其基因中优秀的 Extensibility 自不必说。

其编辑器的画布背后，是一套基于 Operator 与端口的可执行数据流引擎。SAP Data Intelligence Modeler 本身预置大量标准的 Operators，允许开发人员把自定义代码打包成 Custom Operator，直接在画布里使用；运行层面又提供了 REST API、监控查询接口、外部调度集成等可编程入口，等于把设计时与运行时都留好了拓展位(Extension Point).

所以低代码平台的最后 10% 陷阱问题，一定程度上可以通过平台本身设计完善的可扩展性(Extensibility)来缓解。

2. UI/UX 的个性化需求：巧妇难为无米之炊？

这个痛点算是上面「最后 10% 陷阱」在 UI 开发方面的延续。

低代码平台在 UI 开发领域的长处是「足够好用的通用控件」，当完成 UI 需求的控件并不被平台支持时，要么寄希望于平台提供了自定义控件的功能，要么等待平台厂商的 Roadmap.

诸如复杂交互、精细动画、虚拟滚动、高级图形渲染、可访问性细节这些 UI/UX 需求，在 React，Vue 和 Angular 三驾马车的生态里有海量可复用方案与源码级可控性，但如果强行用低代码开发来完成则显得力不从心。

因此业界的一致观点是，低代码的适用领域，主要是那些仅需要简约 UI 和用户交互，问题域收敛、集成半径有限的场景，比如轻量流程与事件驱动的简单应用。

3. 低代码应用的工程化问题

通过外行眼中「拖拖拽拽」搭建出来的企业级低代码应用，如果遵循正规的软件开发流程，同样需要可回归的测试与可演进的工程化实践。

低代码开发相对传统软件开发而言还是一个比较新的领域，不同的低代码开发平台解决的又是特定领域的问题，因此业界在低代码应用工程化这个领域缺乏一些达成共识的最佳实践。

谁负责写测试用例？怎么做高阶 UI 自动化测试？如何把平台资产纳入主干开发？如何做代码审查？安全性如何保证？这些问题的答案目前都依具体的低代码开发平台而定。

所以从工程化的角度考虑，业界也有一些通用的选型标准。

下面两篇 Gartner 和 Thoughtworks 的文章认为：

面向内部用户、表单驱动、报表为主、集成半径有限（少量标准系统/连接器介入），且对上线速度、合规内建、运维轻量有强诉求的团队，可以考虑低代码平台。

面向外部客户、追求差异化体验、交互复杂、需要细粒度性能与渲染控制，或者业界已经提供成熟的工程化最佳实践方案（DevOps、CI/CD、层次完整的测试策略等），选择传统的开发方式是最自然合理的选择。

当然还存在一种「低代码包裹后端流程 + 自研前端」的混合分层策略，既享受到了低代码范式中基于连接器和流程编排进行后端业务逻辑实现的便利，也保留了用户界面的灵活性和可控性。

https://www.gartner.com/reviews/market/enterprise-low-code-application-platform
https://www.thoughtworks.com/en-us/radar/techniques/bounded-low-code-platforms

4. 可移植性与供应商锁定成本的考虑

随着低代码应用完成度的不断提高，应用本身与低代码开发平台的耦合性也不断增加。架构师们会面临一个问题：如果以后想迁移到其他的低代码开发平台，代价有多大？

在笔者看来，这问题就好比"一个基于 Angular 开发的 Web 应用，迁移到 React 的代价有多大？"笔者认为这个问题无解，只能全部重写。

有些低代码厂商可能会声称用自己的平台开发出的低代码应用，可以导出源码或脱离平台运行。但考虑到框架绑定、运行时依赖、运维模型重建等问题，架构师们在做出迁移低代码平台的决定之前，一定都会慎之又慎。

5. 学习曲线并非比传统编程平缓，只是把「学语言」变成「学平台」

某些低代码提供商的主页，强调平台的亮点是「写更少的代码」，但这并不意味着「学更少的东西」。

或许从外行眼中看来，低代码开发仅仅在浏览器里拖拖拽拽，点击几下鼠标，就能生成一个像模像样的应用。

然而他们看不到的是，低代码平台背后的领域模型抽象，Domain Specific Language 设计、权限模型、连接器生态，组织层面的环境与合规策略等，都做了大量的工作。

对于低代码开发人员来说，如果对平台这些背后的工作原理一无所知，在应用开发和维护过程中遇到问题，则会陷入不知从哪里入手分析和定位问题的窘境。

出来混总是要还的。选择低代码开发，开发人员表面上似乎省去了学习某门编程语言的时间，但省下的时间，往往花在了低代码平台使用和错误排查之上。「学语言」变成了「学平台」。

6. 对开发者的吸引力不够

举个例子，一个开发人员，假设每天有 2 个小时可以自由支配用来学习，他有两个选择：

1. 学习 JavaScript
2. 学习一门低代码开发工具

如果只能二选一，他会怎么选？绝大多数开发人员都会选择 JavaScript. 理由很简单，花在这门编程语言上的每一分钟投资，将来都能够稳定持续获得收益：JavaScript 是前端开发框架使用的主流编程语言，也是学习 TypeScript 的基础。JavaScript 也能作为后端 Node.js 开发的敲门砖。

如果选择低代码开发，这种投资不确定性很大，学了之后派不上用场怎么办？不同厂商的低代码平台，解决的是不同细分领域的问题，使用方法和设计思路不会有太多的共同点，没有太多通用性可言。

相对于传统的软件开发来说，低代码开发的需求规模也小得多，这些客观情况都导致开发人员学习动力不足。

以上是笔者对低代码开发痛点的一些个人理解。笔者认为即使在 AI 时代，低代码开发也绝不会替代传统软件开发，充其量只是一种有益的补充手段。