低代码开发的优势与劣势，看这一篇就够了

一、前言

从 2020 年低代码盛行以来，围绕这种新的软件开发模式的争议就从来没有停下过。

主流的声音认为，低代码理论上存在的开发门槛低、易用性等特点，能够满足企业在数字化转型中大量的软件开发需求，这也是低代码迅速成为 toB 风口的一个关键因素。但持相反论调的人则声称，低代码是“新瓶装旧酒”，他们质疑低代码是伪需求，同时认为低代码平台暗藏巨大的变革成本。

在一个新生行业或者新鲜的概念出现初期，争论和质疑必不可少，关键在于，伴随着争议的是这个赛道的没落还是跌撞前行。从目前的发展来看，低代码仍处于风口。接下来，作者将不失偏颇的介绍低代码的优势与劣势，以便大家更直观的了解低代码。

二、低代码的劣势

先来讲讲低代码的劣势。

1、能力弱

低代码平台本身是一个开发框架，能在平台上造出什么，很大程度依赖于框架本身的能力。在当前阶段，诸多低代码玩家凭着 BPM（业务流程管理）、BI（数据分析）等厮杀于企业协同领域，无怪乎很多看客视低代码为“玩具”。

但同时也应该看到，一方面，即使“玩具”也能为许多企业信息化转型提供很大助力；另一方面，已经有玩家开始向 APP、游戏甚至更高的层面探索，承载核心业务、复杂应用、多变的 C 端未来可期。

2、灵活性低

虽然很多低代码平台标榜自身灵活性强、解决企业个性化需求，但其前提是在框架能力范围内。如果个性化需求刚好不在框架能力范围内，二次开发实现成本、时间都不容小觑。若企业所选的低代码平台刚好又不够开放，对平台支持和升级的强依赖性会让企业有苦难言，这便是所谓“锁定”。在源码支持和迭代升级方面，目前市面上 JNPF 开发平台做得比较好，良心高性价比。

3、开发者不友好

很多低代码平台框架对开发者是黑盒，这给开发者带来两大问题，一是活难干，二是没前途。

1）活难干是在开发时一旦遇到 Bug、性能等问题，由于不清楚内部实现逻辑，问题排查无从下手，代码调试要反复切换界面，只能浪费时间干瞪眼等平台支持时。这方面问题，JNPF 支持的全源码可以很好的解决。

2）没前途是专业程序员高度依赖低代码平台，而疏于 Coding 会造成能力蜕化，这长期来看意味着失业和放弃未来。

专业开发者是低代码生态中极重要的参与者，如何让专业开发者自愿入局对低代码平台来说也是个挑战。

4、业务方观念扭转难

普通业务人员是低代码平台关键用户，但让业务部门把低代码平台用起来，至少要跨过 3 个门槛：技术门槛、心理门槛、动机门槛。

1）技术门槛，稍有技术含量、需要一定学习成本，就可以拦下很多人；

2）心理门槛，很多人会出于畏惧新事物和学习而拒绝接受；

3）动机门槛，以往业务方动下嘴就能拿到软件，现在让他动手自己干？很多人的懒惰是赤裸裸的现实。

这 3 个门槛绝非不可跨越，但却需要耗费心思。

1）跨越技术门槛，可以采用无代码，但需要平衡灵活性的妥协；

2）跨越心理门槛，需要产品讲好故事、做好交互设计，调整如“BPMN 图、ER 图、外键、函数、脚本”等专业词汇，尽量避免触发用户畏惧心态；

3）跨越动机门槛，需要找到足够痛的场景，通过行业模板、业务模板、交互设计等打造足够简单的操作方式。

5、应用治理、平台性能等

低代码平台降低了应用开发成本，如果应用爆发式增长，出现大量无人或较少人使用的应用，则对业务价值不大，却会带来额外的认知、管理成本。同时，应用数和使用人数的增长，也会给平台性能带来挑战。另外，用户追求个性化前端呈现与平台固化的前端呈现也是一种需要应对的矛盾。

总之，低代码是个好东西，框架本身可以大大提升效率，但同时，它也存在着一些问题。莫要“成也框架，败也框架”。

二、低代码的优势

看了很多低代码平台的劣势，也莫要灰心，先让克里斯坦森为我们打打气。他在《创新者的窘境》中定义了“颠覆式创新”，即比市场上现有产品更为便宜、更为方便的替代品，它服务于低端消费者或新消费群体，步步蚕食传统产品的市场份额，最终取代传统产品的统治地位。低代码平台是否是颠覆式创新，我们拭目以待。

1、降本

主要包括 3 方面，学习成本、开发成本和其他成本。

1）学习成本降低是普通业务人员即可操作，为 IT 研发资源不足的企业降低人力成本。

2）开发成本降低是对于开发者而言，可以复用既有能力，减少低价值代码耗费时间，同时，很多需求变更可通过配置方式实现，缩短了开发、运维等时间。

3）其他成本如沟通成本、测试成本，甚至云架构方式降低硬件成本等。

2、增效

主要包括 2 方面，交付效率和协作效率。

1）交付效率

通过配置即可满足一批新增或变更需求，直接避免了低价值代码开发时间，开发效率提升 10 倍并不夸张。同时，也意味着客户响应效率的极大改善，这是比开发效率更重要的事！

通过配置无法完全满足的需求，虽然仍有开发工作量，但由于可以复用平台能力，也节省了相当一部分开发工作量，提效数据要看具体场景，但总体而言，复用带来的效率提升不容置疑！

由于平台能力复用，会大大缩短端到端交付时长，如测试时长、集成发布时长等都被大大缩短，工程效率的提升，让低代码有超越 DevOps 进化至 NoOps 的可能性。

2）协作效率

沟通效率。一个需求交付要涉及到很多人，如业务人员、产品经理、开发人员、测试人员等。而借助低代码，很多需求可能在业务部门内容就能实现了。需要沟通的人数少了，沟通效率自然就提高了。

天生敏捷精益。敏捷追求的核心关键字，如“尽早交付”、“快速反馈”、“响应变化”等低代码平台生而有之，通过配置快速交付，让程序尽早接受业务校验，迅速得到反馈，并及时调整。精益追求的核心关键字，如“价值”、“消除浪费”、“内建质量”等低代码平台同样生而有之，低成本快速验证，聚焦业务设计而非程序设计，通过业务聚焦、标准化、复用、少人化等消除不产生价值增值的活动，通过平台本身内建质量保障所有应用质量等。

3、提质

Bug 界有个绝对真理，“代码越少，Bug 越少”，低代码平台开发应用所需的代码量决定了其 Bug 量极少，甚至，“No Code，No Bug”。

低代码平台与“中台”也有类似之处，由专家级开发团队打造便于进化的高质量代码。采用“复用”、“统一”的理念，降本增效、打破孤岛。同样，低代码平台也需要警惕“中台陷阱”，本欲“赋能”业务，不料变成瓶颈，以至业务“无能”。

4、价值

主要包括 3 方面，高度贴合业务、缓解低价值需求资源困境、提升程序员价值。

1）高度贴合业务。

一个好的 B 端产品不是功能牛 X，而是恰好能解决客户当下的问题。这就需要产品可以适应不同成熟度的客户，而不是一个标准方案走天下。笔者曾持此理念帮多省、多家运营商落地研发协同平台，针对不同客户成熟度给不同解决方案。传统的标准化产品无法支持此理念，但低代码平台却具备这个能力，笔者对低代码平台的信念之一也源于这种经历。

衍生介绍一下我家的产品了，JNPF 开发平台，是一款基于 SpringBoot+Vue3 的全栈开发平台，采用微服务、前后端分离架构，基于可视化流程建模、表单建模、报表建模工具，快速构建业务应用，平台即可私有化部署，也支持 K8S 部署。

永远是动手>理解的。尝试自己搭建一个应用程序，JNPF：https://www.jnpfsoft.com/?infoq

2）缓解低价值需求资源困境。

IT 团队总会面对做不完的需求，纵有人把控 ROI，也难免频繁出现一种怪相“业务方叫的急，上线后却不用”，这种低价值需求对开发资源的占用是极大浪费。对于低价值需求，先用低代码平台满足基础需求可以改善这种困境。另外，也需要思考一个问题，“低价值需求真的价值低吗”，这些被判定低价值的需求很难拿到开发资源，只能永远在等排期，而低代码平台却能给这些“死刑需求”生存空间，这些低价值需求有可能会是组织创新的一个源泉。

3）提升程序员价值。低代码可以帮程序员减少在低级重复性工作上浪费时间，从而可以有更多时间专注于高价值的代码，可以更深入业务，以更匹配的方式满足业务需求。

5、互联网效应

“低代码平台+云”的生态，让程序开发这门生意，上升到了互联网的层面，兼具了互联网四大效应，梅特卡夫效应、双边市场效应、规模经济效应、协同效应。这才是低代码 2.0 的想象力真正所在！打破信息孤岛，让应用与应用、企业与企业，开发者与开发者互联共通，给“复用率”一次质变！