干货文章 | 低代码真的有价值吗？

2024-5-21

文章信息

Article information

作者：瀚码技术钟惟渊（第⼀作者）、独⽴顾问王甲佳（第⼆作者）、瀚码⼀⼑云叨叨AI助⼿（第三作者）。本系列文章由瀚码技术钟惟渊构思、制定大纲、组织了关键素材。其中关于平台软件之争的关键素材由王甲佳提供。文章的执笔、修辞润色由一刀云叨叨AI助手自动生成。

| 缘起

这是⼀系列关于软件平台的⽂章。之所以会有这⼀系列⽂章，源于我近期与⼀名从业近25年的IT⽼炮——王甲佳⽼师的⼀次关于低代码平台的交流。这次交流让我受益匪浅，我的⼀些低代码平台的想法，在王⽼师看来其实并不新鲜。

他在2005年就思考过如何构建业务基础平台，但因为受限于那时的软件技术条件，⾃⼰那些看似天⻢⾏空的想法并未得以实现。随着交流的逐步深⼊，王⽼师甚⾄发出了“⽼骥伏枥，志在千⾥；烈⼠暮年，壮⼼不已”的感叹！18年过去了，现在的软件技术已经出现了翻天覆地的变化，原来做不了的事现在已经可以做了…

当年的软件平台化的争论已经告⼀段落了，结论也不⾔⾃明。

2005年开始，当时以ERP⼚商为代表的标准软件提供商（如SAP、⾦蝶等），陆续推出了⾃⼰的软件平台。⽐如，当年⾦蝶推出的BOS，现在已经进化成了苍穹这样的⼤型软件平台。SAP也从当年的Netweaver进化成了Lightning 和 Force.com这样的PaaS平台。

这⼏年低代码开发平台这样的软件产品的出现和⽕热，⼜引来了关于软件平台化的争论——历史总是惊⼈的相似。每次有新鲜的概念出现，⼈们总是要拿出来吵吵，有的⼈觉得是炒作新概念，有的⼈如获⾄宝。⼈们似乎总是不愿意承认⼀个客观事实：⼈们对于效率和成本的追求是无止境的。

本⽂我先从当前低代码平台的尴尬境地讲起。为了深⼊探讨低代码是必然趋势这个假设，王⽼师将带领读者我和读者朋友回到18年前的2005年，看看当时的先辈们是如何看待平台化软件产品的。了解过去，有助于我们把握未来。

| 代码平台厂商的尴尬

3⽉，某公司在温州召开了⼀场CRM选型的会议。会议室内，⼀位名叫张伟的销售经理正在介绍他所在公司的产品——低代码平台。企业⾼层围着圆桌坐了⼀圈，他们听得很认真，偶尔还有⼈打断张伟，提问题让他回答。这是该企业CRM选型中的⼀幕。在此之前，除了该公司外，还有其他四家公司参与竞标，包括阿尔法、⻉塔、赛⾼和欧⽶伽。现在的局势是五选⼀。

张伟是上海某低代码⼚商的⼤区销售经理。⾃从两年之前加⼊该公司，他已经⽆数次在打单时遇到类似的局⾯。整个演⽰，他表现得相当沉稳。直到有⼈提出：“低代码平台的好处你已经讲了不少了，我们也理解了。基于你这个平台，我们可以构建各种业务系统。但你能不能着重把CRM的功能演⽰⼀下？毕竟，我们这次是CRM系统的选型。”

张伟⼼⾥“咯噔”⼀下：“提这个问题，就说明你对平台软件还没真正理解。你先要讲清楚对CRM的具体需求，我们才能⽤⾃⼰的平台帮你开发和实现呀。”由于⾃⼰的低代码平台⽆法⽴刻满⾜客户的具体需求，张伟只能简单演⽰了⼀下如何在⾃⼰的平台上开发CRM的业务模块。

有⼏个听众显得有些失望，另外⼏个则听得津津有味。会后，企业⾼层旗帜鲜明地分成两派，围绕平台软件展开了⼀场⼤辩论，有⼈情绪过激，⾯红⽿⾚。9⽉16⽇，张伟离开温州，选型尚⽆结果。11⽉，在北京，记者再次⻅到张伟。根据温州那家企业传来的最新消息，CRM选型的范围已经缩⼩到两家——案例很多但不是基于平台化的⽼牌CRM⼚商阿尔法和张伟所在的低代码平台公司。看来战⽃还在继续…

低代码开发作为⼀种新型的软件构建模式，它可以帮助企业快速构建应⽤程序，提⾼数字化转型的效率。低代码平台主要分为模型驱动的低代码平台和表单驱动的零代码平台，其中，零代码平台可以理解为低代码平台的理想化——完全脱离代码，从⽽让不懂代码的业务⼈员能⾃主构建系统，降低门槛。

然⽽，低代码平台在过去⼀段时间内一直处于尴尬的境地：在甲⽅IT看来，低代码是“业余⼈员”或“⾮专业⼈员”开发的工具，⽆法胜任复杂业务流程和⼤规模的企业应⽤程序开发。在甲⽅业务⼈员看来，软件构建这种事本来就是IT的事，我需要的是⻢上能⽤的业务系统，让我⾃⼰构建业务系统，你还是找IT部吧。不只是甲⽅爸爸，作为⼄⽅的⾮平台软件⼚商对低代码也持观望态度，毕竟——我⾃⼰花了这么多时间沉淀出来的东⻄，即使你的低代码平台很好，如果要切换到你的平台，重构成本且不说，万⼀被我被你绑定了怎么办，万⼀你⼚商嗝屁了我怎么办？——我绝对不想被你绑架。所以，低代码平台可以卖给谁，应该卖给谁呢？

这个问题我有着同样的疑惑：如果低代码平台的受众是⼄⽅或甲⽅IT，那应该就是卖“渔”。如果⽬标客户是甲⽅的业务部门，那就是卖“鱼”。

“王⽼师，你是如何看待这个问题的？”为了让王⽼师打开话匣⼦，我引导道。

“这个问题并不是困扰你⼀个⼈——这个问题困扰了整整⼀代IT⼈”。王⽼师边回答边利索地翻找着他的微信收藏夹，在⼀阵翻找后，给我分享了《中国计算机⽤户》于2005年出版的⼏篇连载⽂章。

| 回到18年前的那个秋天

为向IT前辈致敬，同时也为信息不失真，AI将直接引⽤《中国计算机⽤户》期刊的原⽂。

话题还是要从18年前⼀家公司选型CRM系统的说起。成熟的CRM和平台化的CRM如何选择？让当时智博公司的⽼总犯了两难。

*以上截图为原文引用

可以看出，对于平台型软件，有的赞同，有的反对。在当时的IT环境下，有⼈敢于尝试创新的平台型软件，强调“渔”的重要性，除了⾃主可控，更多可能是出于标准软件是否能满⾜公司差异化的诉求。

这种诉求不是在标准产品的基础上⼆开上线就停⽌了，⽽是上线才刚开始。当时的软件开发⽤的各类组件模块并未像现在⼀样丰富，平台软件，更多是⼀些脚⼿架，或者各类软件库的组合。⼀个软件如此，把所有的软件组合起来就更恐怖了。如果⽤财务的语⾔，⾮平台型的软件产品的总拥有成本是⾮常⾼的。

| 再论低代码平台的本质

我是谁，我从哪⾥来，要到哪⾥去。

困扰画家⾼更和⼩区保安的三⼤问题也同样困扰着低代码⼚商的⽼总。低代码平台的可以将开发⼈员从重复的、繁琐的编码⼯作中解放出来，使他们能够更专注于业务流程的设计和优化。平台提供了⼀个可视化的开发环境，让业务⼈员和开发⼈员可以轻松地协作，实现快速开发和迭代，同时保证代码的质量和可维护性。

何以低代码平台可以实现软件构建效率的提升、质量的提升和成本的下降？低代码平台在提升开发效率、提升软件质量上有做哪些技术上的突破吗？

很遗憾，并没有技术上的突破，⽽是从量变到质变的⼀种必然，⽤现在的话说，是⼀种“涌现”。

如果我们从软件开发的⾓度，将业务软件解构出来，我们会发现，⽆⾮是业务⻚⾯（前），中间的业务逻辑（中）、后端的数据库存储（后）。前端⻚⾯的构建就是以各类前端UI（⽤户界⾯）框架，如VUE、Element等，结合Javascript语⾔和CSS，来定义业务⽤户能看到的操作界⾯和外观。中间，主要是业务逻辑的实现，⽆论是使⽤什么编程语⾔，Java、C#、还是Nodejs，以及他们的各类框架和库，⽆⾮就是处理前端传过来的数据输⼊，按照业务流程（逻辑），查询后端的数据库数据，编写⼀些算法，返回给前端从⽽呈现给⽤户，实现基于UI的⼈机交互。

⽆论是前端、中间层、后端，软件开发经过⼏⼗年的快速发展，已经沉淀了⼤量的组件，这些组件经过不停的迭代，⼤量的实践（尤其是互联⽹公司），可以说是⾮常成熟稳定了。程序员要做的，就是组合这些框架和库，编写⾃⼰的业务逻辑。低代码平台⾃⾝的开发，也是这个逻辑，将各类成熟的组件进⾏组合，技术上，还是那些开发语⾔、开发平台、软件组件。效率来⾃于标准化，质量来⾃于标准化，效率⾼了，质量⾼了，软件开发的成本⾃然下来了。

可以说，低代码是软件开发沉淀到一定程度的必然，是企业追求效率、质量和成本的必然结果。就像⼯⼚⾥的流⽔线⼯⼈必然会被更快质量更好的⾃动化⽣产线替代⼀样。软件开发也⼀样，标准化、流程化，最后⾛向⾃动化。这是软件⼯程的必然趋势，没有⼈可以阻挡。

王⽼师认为，平台软件所带来的绝不仅仅是⽣产⼒的提⾼，⽽是包含在企业信息化中的⽣产关系的变⾰：它本来是软件⼯程技术进步的产物，⼜将软件⼯程技术推向了后台，使企业信息化关注的重点从软件回归管理。软件供应商（包括专门的平台软件供应商）对平台软件的认识还远远没有到位——许多标准化套装软件供应商对平台软件表现出了极⼤的敌意，另有⼀些软件供应商则将平台软件看成是软件⼯程技术的⼀次平凡的升级，⽽绝⼤多数平台软件供应商还在⽤销售标准化套装软件的⽅式销售平台软件。

事实上，平台软件所带来的，远远不是低代码⼚商宣传的那样，使⽤户稍微有⼀些主导权那么简单，它第⼀次将软件⼯程技术推向了后台，让管理活动的主体——管理者有可能充当企业信息化的主要⾓⾊，⽽不是企业信息化系统的被动的使⽤者。

打⼀个通俗的⽐⽅，平台软件给管理者（在企业信息系统建设⼯作⽅⾯）提供了⼀个让管理者有可能方便快捷建⽴企业信息化系统的⼯作台，在这个⼯作台之上，管理者有可能按照实际管理的需要建造⼀个适应性的信息化系统。

传统的软件上线过程，⽆论是甲⽅，还是⼄⽅，都需要投⼊⼤量的项⽬成员，经过⻓时间的项⽬实施才能勉强上线。这种⼤投⼊的交易模式，对甲⼄双⽅都未必是好事，但没有办法，这是⼀个结构性的问题。直到低代码平台的出现，让双⽅的交易⾯有了质的变化，让甲⼄双⽅都能从中受益。

| 我们需要什么样的平台软件

“那你认为低代码⼚商应该要怎么做才能破局？”我作为⼀名低代码平台的从业者，不禁问道。

“很简单，做客户需要的。强调⼀点，我说的是做终端客户需要的。”王⽼师⽤不太清晰的普通话回答道。

“如何理解呢？”

“客户购买低代码平台是为了什么？”

“⽤来构建业务系统啊。”

“那你有他要的东⻄吗？”

“你的意思是，平台只是个平台，要解决他的业务问题，光有平台是不够的，还需要有平台上的应⽤？”

“光有应⽤可能还不⾜够，还需要解决⽅案。技术也好，平台也好，应⽤也好都是⼿段，解决⽅案之所以叫做解决⽅案，那是⽤来解决业务问题的。你只有抓住了业务的痛点，平台化也好，应⽤也好，都是⼿段。基于平台的应⽤，⽆⾮就是修改起来更快嘛。平台化的优势，⼤家让IT享受就好了。⾄于业务部门，有各类提前构建好了的应⽤可供选择，即使不能满⾜100%的需求，但因为你是平台化的，重新配置⼀下流程⻚⾯表单不就⾏了。这就是平台化+业务应⽤模板化的优势啊。”

“是这个道理。基于平台交付应⽤，其实交付的不是应⽤本⾝，⽽是⼀种新型的能⼒，是⼀个授之以渔的模式。”

“业务管理软件的本质是软件，还是管理呢。”

“应该是管理。但如果是这样，我感觉平台软件⼚商并不太可能⽐客户还了解他的业务问题。”

“是的。所以你可以提供平台给他们，低代码化的，最好是零代码化的，降低他们使⽤门槛的同时，你做好⾃⼰的平台。低代码也好，零代码也好，⽆⾮就是⽤户体验会好些，扩展性更强，可以适应企业不断变化的业务流程和组织结构。⽽且，尽可能的使⽤⼀个平台来构建业务系统，各业务系统直接是天然打通的，总拥有成本就降低了。”

“是这个道理。但我感觉甲⽅爸爸都很懒吧，即使给他们⾜够的模板，他们也不想⾃⼰动⼿搞吧？”

“ERP⼚商这么多年，培养了⾮常⼤数量的业务顾问，包括甲⽅⾃⼰，管理⼈员的⽔平也越来越⾼，他们⾮常清楚⾃⼰的业务痛点。另外就是，越来越多甲⽅组织⾃⼰的IT开发团队，构建匹配⾃⼰业务个性的⽀撑系统，打造管理体系上⾯的竞争⼒。平台只要有⾜够的开放性，以甲方为中心的软件小生态就可以构建起来。”

“对啊，只要有订单，还怕没⼈⼲吗？这个平台应该需要有⾜够的开放性，这种开发性的平台，应该可以让伙伴们⼀同受益。”

“那我知道了，王⽼师。⼀个好的低代码平台，应该具备几点优势：扩展性、⽤户体验、开放性。这些特性，是需要⽤零代码、低代码、云原⽣、订阅、AI、集成及开放平台等技术来⽀撑的。”

“是的，传统的信息化建设模式我称之为1.0版本，基于平台的建设模式应该是⼀种结构性变化，我称之为2.0模式，也就是现在说的数字化、智能化。”

⼏天后，我整理了我与王⽼师的⽼⼀代IT和新⼀代IT直接的对话，理清了瀚码技术⼀⼑云平台的底层逻辑，并制作了⼀⻚PPT发给了王⽼师。