最近看到不少低门槛开发软件应用的新闻：“30 分钟搭一款核酸检测登记应用”、“2 小时紧急上线抗疫求助应用”、“00 后低代码开发者毕业月薪过万”等等。

近期，广西防城港市出现疫情，全市展开一轮大规模核酸检测。柳钢工人彭期文在钉钉上仅用 30 分钟就通过低代码搭起一款“核酸检测登记”应用，原本需要大规模的排队登记，如今手机一扫，3 小时就能完成 7000 余人核酸检测。

彭期文称，看到自己做的低代码程序能够帮助到这么多的医疗工作团队，还是感到十分高兴。

图片来源 @山海视频截图

钢铁工、社区志愿者、非专业毕业生……随着低代码的流行，很多弱编程基础的“小白”都表现出“敏捷开发”的潜质。以第一则新闻为例：核酸登记软件虽说工程量不大，但麻雀虽小，五脏俱全，有业内人士测算了下——

也就是说，使用了低代码，成本降低了 90% 。技术一把手，估计看到这个数字，肯定又得慌了。

低代码开发平台通过可视化、模块化、拖拽式来代替传统开发方式的写大量代码来进行开发，减少了传统模式开发中需要付出的冗杂的、重复性的编码工作，从而达到“降本增效”的目的。

业内人士感叹：“低代码，正在模糊专业开发者与非专业开发者之间的界限，在慢慢重构着员工与 IT 部门之间的关系。”

开发圈有流传一种“摩尔 996 定律”：平均每 18 个月就会有某种开发工具跳出来说能让开发成本降低一半，同时业务的需求就会增加到原来的两倍。比如，程序语言的进化路径：

“01001001”式的机器语言→“mov”、“add”式的汇编语言→ “if”、“else”式的高级语言

即便是高级语言，也在高速迭代着：面向过程的 C、面向对象的 Java、面向智能的 Python。而这种迭代，也在圈内引发了一波波如「VB 刚出来时，C 程序员看不起 VB，PHP 出来时，所有程序猿都看不起 PHP」 的梗。

低代码会是下一代语言吗？目前看不大可能。但这里只是想表明：编程语言迭代的背后是市场需求的高速增长。软件开发自上世纪 50 年代诞生以来，它的需求在以越来越快的速度增长，而软件开发人员一直是一种稀缺资源。

而为了解决这个开发人员短缺问题，业内也使出了浑身解数，但一般分为两大招数：

一、提高开发人员生产率的框架和工具（解决了时间和成本问题）

二、降低开发门槛，让非开发人员也能够开发（这主要解决了稀缺性问题，但也减少了时间和成本）

不难看出，第二招已经演变为不同的名称，如第四代语言、计算机辅助软件，当然还有现在大热的无代码 / 低代码。

低代码大火的底层逻辑：数字化转型不可避免、各企业应用开发需求激增、程序员资源极度短缺是大背景，将过往来回重复的开发能力模块化、可视化、可定制化。

因此，可以预见：程序员不会失业。就像支持二次开发的 ERP 应用软件的推广，并没有降低市场对专业程序员的需求。相反，企业往往还需要为这种新开发工具额外安排专家岗位。因为，于企业而言，最实用、最有效且百分百可以实施到位的方案才是企业想要的，因为但凡有不合适的地方，管理者可以随时去改。而不是招聘一个传统的开发及维护团队来进行长周期操作。

于专业开发者而言，可能失去的是技术含量不高的、重复造轮子的、无需创造力的项目机会。毕竟，光确定需求这个环节，就能让开发者与项目管理者、产品经理“撕”上几个星期。

从某种角度看，纵然传统的开发模式枯燥、繁琐些，但毕竟是程序员的活，现在连重复的“轮子”也不给造了。难免会让人担忧：这不明摆的抢程序员饭碗吗？

但社会不就是这样的进化逻辑吗？任何软件、语言的流行并付诸商业化，说到底并不是出于程序员的个体喜好，而是背后的市场商业需求所推动的。

你能阻挡数字化转型的大势吗？如果没有比低代码更好的、更快的、更完美的解决“开发者稀缺”的问题，低代码的流行就成了必然。

现有传统的开发人员的框架和工具都跟不上这种迫切需求的节奏。3 个月的交付速度与 30 分钟的上线速度，大家一目了然。

当然，这也并不意味着程序员会陷入「一个取代另一个」的“鱿鱼游戏”中。

正如各大编程语言在各自的领域各领风骚一样，可以预见低代码会在生态中达到这样一种“混合共存”的平衡：

• 无代码：比如业界将慢慢不使用主要用于业务流程工作流和数字营销内容的代码。

• 低代码：将提供大多数定制 UI 布局和应用程序逻辑（前端和后端）的主干。

• “高”代码：对于复杂的软件组件，当然还有基础软件（工具、操作系统等），“高”代码将持续存在，比如：3D 游戏界面（交互复杂）及其底层的游戏引擎（逻辑复杂）、超大型 CRM 系统（一方面是实现很复杂，另一方面，这种成熟软件的标准化程度较高，大部分情况下可以直接用现成的 SaaS 软件）。当然，本身低代码平台的开发程序员的需求就相当旺盛。

三种不同方法和理念的共存需要互操作性。可以预见，在这种平衡中，用户可以合并任何现有的软件组件，无论是开源的、商业许可的，还是由他们的团队构建的。它们不应该局限于低代码平台的组件，或者需要编写特定于该平台的定制代码来实现这一点。

所以，在混合共存中，饭碗稳稳的，不必担心会丢。

任何事物的发展都没有那么美好，低代码同样也有备受诟病的三宗罪。

1、黑盒焦虑

“平台上的各种可视化组件、逻辑动作和部署环境都是黑盒，如果内部出问题无法排查和解决。”

没错，低代码平台上的各种可视化组件、逻辑动作和部署环境都是黑盒，如果一旦内部出问题，就很难排查和解决。这确实是目前使用低代码平台时绕不开的最大痛点，但并不属于低代码技术本身的固有缺陷。

这种平台问题，就如同 Windows 系统之于“蓝屏”问题一样，我们选择使用“抽象”来简化平时的操作，就不可避免会遇到“黑盒”问题，让天生爱刨根问题的技术人有些忿忿，但如果因为蓝屏问题，就不用 Windows 系统了吧！

2、不便维护

一开始看起来很美好，一两条命令什么都生成了，但是要改个什么东西，抽丝剥茧最后到最基础的地方，发现需要继承重写原来的类才能实现需求，有的里面有 bug, 要改特别绕。

关于维护性，尚未成熟的低代码自然有需要完善的地方。但其实，无论低代码还是纯代码，造成应用可维护性低的根本原因不是开发工具，而是开发者自身没有去遵循一些软件开发的普适原则，比如工程规范性、命名可读性、DRY/KISS/SOLID 原则等。

因此，低代码平台应该积极引导和帮助开发者去改善应用的可维护性。知名的低代码平台 Mendix 就提供了很好的参考：除了支持基本的模型分析与重构（无用模型、对象重命名、子逻辑流提取），还提供了基于 ISO/IEC 25010 标准的应用质量监控（AQM）能力。

当然，低代码也有自己的适用场景和能力边界。如果业务场景过于复杂，本身就不便于维护，建议考虑换“高”代码方式。

3、拼乐高

“试用过一些所谓的低代码开发平台，要么能力很弱，要么体验太差，只能开发点玩具应用。”

很多开发者对于“拖拖拽拽搞定一个应用”的开发方式嗤之以鼻。而且现在实现的应用也都是类似“趣味编程”、“登记 / 审核表单”之类的初级案例，安全、性能、可伸缩性都没有保证。

可这不正是反映了当下迫切的数字转型开发需求吗？

当市面上真正成熟的企业级低代码开发平台出现以后，完全有能力以高效的开发方式满足大部分更“高级”的场景的功能需求。

当然，目前低代码的发展还有一宗“罪”：如果各大平台使用专利技术，创建“应用墙”，又或者在无代码 / 低代码开发人员遇到限制时，将“高”代码替代作为最后手段，就会让开发者忍不住暴怒一声：行业“毒瘤”！

归根到底，市场需求推动了我们的生产工具。疫情蔓延加速了全球数字化转型浪潮的进程，低代码概念虽然新，但技术并不新，就如同我们熟悉的编程语言、技术栈的演进一般，保持一种平常心看待低代码，就会发现——低代码不过是软件开发生态中的一员一样：开拓了新的开发方式，解决了企业开发资源的稀缺的问题。

而开发者、技术管理者则需要重新思考并寻找开发者及 IT 部门的定位：

• 技术平民化

时代不同了，商业环境和模式变了，有了云和 AI 加持，中小商业的数字化自然会催生相应的知识体系和人员业务能力模型的重构。如现在人人都可以在短视频 App 上轻松视频编辑，而不再是摄影专业人员独门技能，但也互不影响。

• 让专业者更专注

低代码抽象了各行各业的业务逻辑，业务人员从逻辑层就可以实现应用的创建，非常适合于短生命周期的短平快应用，甚至可以用后即焚，例如调查问卷、统计报表，经过简单培训就可以上手操作，不用再劳烦 IT 部门。而掌握全栈技能的“高”代码开发人员，从事更具挑战也需要深厚积累的应用的创建，也可以封装业务逻辑成低代码模块供低代码开发者使用。

时代在推动，技术人的栈道只会越来越多。前段时间，Gartner 给出了一个预测：到 2025 年，70% 的新应用将由低代码 / 无代码技术完成开发。网上看到一位朋友有趣的描述，这里借用一下：

当你与前端联调了一上午接口，又与 PM 撕逼了一下午需求，再与自己的 bug 抗争了一整晚，好不容易遁入梦乡又被一连串报警短信吵醒时，是否有抬头对着星空思考：该不该用低代码呢？

向后看，低代码目前有点“毒瘤”，但向前看，却是另一番天地。


文章来源：51CTO技术栈