低代码的局限性：为什么它无法替代软件开发

延续[[BPM与SOA时代集中式工具失败的具体教训]]，伴随BPM套件而来的还有零代码/低代码理念——让业务利益相关者能在没有IT参与的情况下、不写代码就构建可执行流程模型，这个想法对业务方极具吸引力。但要实现这一点，低代码方案往往需要非常重的工具，让非开发者靠拖放预置元素来搭流程，配上复杂的引导流程教用户如何配置——这类不太懂技术、参与软件项目的人有个专门称呼叫”泛开发者”（citizen developer），确实回应了当下开发者短缺的真实需求。但作者的一线观察是：低代码方法对相对简单的流程可能够用，一旦遇到复杂业务流程或集成场景就明显不够，低代码产品经常无法兑现承诺，泛开发者搞不定核心流程实现，公司最终还是得回到IT部门、指派专业开发者来完成这项工作——而这些开发者还得重新学习一套专有的、厂商相关的应用开发方式，学习曲线陡峭又令人沮丧，组织内部人手不够时又被迫求助外部的、和BPM厂商合作的系统集成商，这些顾问要么不够熟练、要么太贵、要么根本解决不了问题（往往三者兼具）。低代码平台还带来三个具体代价：无法采用行业最佳实践（自动化测试、框架集成、完善UI都受限于厂商预设路线，很难突破）；无法利用开源/社区的知识和工具改进（拿不到GitHub上的代码示例，只能看厂商专用向导工具的指导视频）；工具本身通常很重，难以适配现代虚拟化或云原生架构。这些现实问题让不少公司彻底放弃了流程自动化工具——但这不该被理解成”流程自动化没用”，而该理解成”低代码取代软件开发”这条路走不通；更可取的方向是把软件开发和流程自动化结合起来：灵活性的真正含义不是抛开开发者，而是让不同责任人都能用图形模型来理解和讨论，同时依然让普通开发人员参与实现、复用现有解决方案生态，工作流厂商预建的集成能力也能进一步减少构建工作量。