活动回顾?最近看到很多关于低门槛开发软件应用的新闻：《30分钟打造一个核酸检测注册应用》、《2小时紧急抗疫求助申请”、“2000年后毕业的低代码开发者月薪过万”等。近日，广西防城港市发生疫情，一轮大规模核酸检测柳州钢铁集团有限公司职工彭起文在钉钉上仅用30分钟就通过低代码搭建了一个“核酸检测登记”应用。规模化排队登记，现在一部手机，3小时可以检测7000多人核酸??。彭启文说，看到他的低代码程序能帮助到这么多医疗队，他很开心。来源@山海视频截图钢铁工人，社区volunteers、非专业毕业生……随着low-code的流行，很多编程基础薄弱的“新手”展现出了“敏捷开发”的潜力。以第一条新闻为例：核酸注册软件虽然不是什么大工程，但麻雀虽小，五脏俱全。有业内人士测算，如果采用传统的软件开发方式，从需求调研到产品设计、软件开发、前后端联调、测试、发布需要5天（1人为产品，2天；开发2人，3天；测试1人，2天，即10人??/天）。即使用low-code，成本降低90%。看到这个数字，技术负责人肯定又慌了。低代码开发平台采用可视化、模块化、拖拽式的方式代替传统开发方式中编写大量代码进行开发，减少了传统模型开发中需要付出的繁琐重复的编码工作，从而达到“降本增效”的目的。业内人士感叹：“低代码正在模糊专业开发人员与非专业开发人员的界限，慢慢重构员工与IT部门的关系。”一种“摩尔996定律”：平均每18个月，就会跳出某种开发工具，说可以将开发成本降低一半，同时业务需求会增加到原来的两倍.比如编程语言的进化路径：“01001001”式机器语言→“mov”、“add”式汇编语言→“if”、“else”式高级语言甚至高级语言正在高速迭代：面向过程的C、面向对象的Java、面向智能的Python。而这样的迭代也在圈内掀起了“VB刚出来的时候，C程序员看不起VB，PHP出来的时候，所有程序员都看不起PHP”的波澜。低代码会成为下一种语言吗？目前不太可能。但在这里我只想表明，编程语言迭代的背后是市场需求的快速增长。自从20世纪50年代软件开发诞生以来，其需求一直在以越来越快的速度增长，软件开发人员一直是稀缺资源。为了解决这个开发者荒问题，业界也想尽办法，但大致分为两招：1.提高开发者生产力的框架和工具（解决时间和成本问题）2.降低开发门槛，让非开发者也可以开发（这主要解决了稀缺性问题，也减少了时间和成本）。无代码/低代码现在很热门。低代码大火的底层逻辑：数字化转型不可避免，各企业应用开发需求激增，程序员资源极度短缺是大背景。过去反复出现的模块化、可视化、可定制的开发能力。因此，可以预见：程序员不会失业。正如支持二次开发的ERP应用软件的推广一样，并没有减少市场对专业程序员的需求。相反，公司通常需要额外的专家职位来使用这种新的开发工具。因为，对于一个企业来说，最实用、最有效、100%可执行的方案才是企业想要的，因为如果有不合适的地方，管理者可以随时改变。而不是聘请传统的开发和维护团队进行长期运营。对于专业的开发者来说，可能失去的是那些不是高科技、重新发明轮子、不需要创意的项目机会。毕竟单单是确定需求这个环节，就可以让开发人员、项目经理、产品经理“撕破脸”好几周。“工作碗”之争?从某种角度来看，传统的开发模式虽然枯燥繁琐，但毕竟是程序员的工作，现在连重复的“轮子”都不造了。难免让人担心：这不是明明在抢程序员的饭碗吗？但社会不就是这样的进化逻辑吗？任何软件或语言的流行和商业化，都不是程序员个人喜好的结果。它是由背后市场的商业需求驱动的。你能挡得住数字化转型的大势吗？如果没有比低代码更好、更快、更完美的解决“开发者稀缺”问题，那么低代码的普及将成为必然。现有的传统开发人员框架和工具都无法满足这一迫切需求。3个月的发货速度，30分钟的上线速度，大家一目了然。当然，这并不意味着程序员会陷入“以一敌二”的“鱿鱼游戏”。就像各大编程语言在各自领域都处于领先地位一样，可以预见低代码在生态中会达到这样一种“混合共存”的平衡：无代码：比如业界会逐渐停止使用它主要针对业务流程工作流和数字营销内容。低代码：将提供大部分自定义UI布局和应用程序逻辑（前端和后端）的骨干。“高”代码：对于复杂的软件组件，当然还有基础软件（工具、操作系统等），“高”代码将继续存在，如：3D游戏界面（复杂交互）及其底层游戏引擎（逻辑复杂）、超大型CRM系统（一方面实现起来非常复杂，另一方面这种成熟的软件标准化程度高，大多数情况下是现成的SaaS软件可以直接使用）。当然，低代码平台的开发者需求是相当旺盛的。三种不同方法和理念的共存需要互操作性。可以预见，在这种平衡中，用户可以合并任何现有的软件组件，无论是开源的、商业许可的还是由他们的团队构建的。它们不应该仅限于低代码平台的组件，或者需要编写特定于该平台的自定义代码来实现。所以，在混居中，饭碗安稳，不用担心丢了。三宗罪?任何东西的发展都不是那么好，low-code也有被人诟病的三宗罪。1、黑盒焦虑“平台上的各种可视化组件、逻辑动作和部署环境都是黑盒，如果内部出现问题，无法检查和解决。”部署环境是一个黑盒子。一旦出现内部问题，很难排查和解决。这确实是目前使用低代码平台无法回避的最大痛点，但这并不是低代码技术本身的固有缺陷。这种平台问题就好比Windows系统的“蓝屏”问题。如果我们选择用“抽象”来简化我们的日常操作，难免会遇到“黑箱”问题，这让天生喜欢深挖问题根源的技术人有些摸不着头脑。怒了，不过如果是因为蓝屏问题，就不要用Windows系统了！2.维护不便乍一看还不错，一两条命令生成所有东西，但要改东西，就得到最基础的地方去。发现需要继承和重写原来的类才能满足要求。其中一些有错误，因此需要更改。关于可维护性，不成熟的低代码自然需要改进。但事实上，无论低代码还是纯代码，导致应用程序可维护性低下的根本原因并不是开发工具，而是开发人员本身没有遵循软件开发的一些通用原则，比如工程标准化、命名可读性、DRY/KISS/SOLID原则等。因此，低代码平台应该积极引导和帮助开发者提高应用程序的可维护性。著名的低代码平台Mendix提供了很好的借鉴：除了支持基础模型分析重构（无用模型、对象重命名、子逻辑流提取），还提供基于ISO/IEC25010的应用质量监控标准（AQM）能力。当然，lowcode也有自己的适用场景和能力边界。如果业务场景过于复杂，本身不易维护，建议考虑换成“高”的代码方式。3.拼乐高“我尝试过一些所谓的低代码开发平台，要么能力弱，要么体验差，只能开发一些玩具应用。”很多开发者对“拖拽获取应用”的开发方式嗤之以鼻。而且，目前实现的应用都是“趣味编程”、“注册/审核表”等初级案例，在安全性、性能、扩展性等方面都没有保障。但这不正是反映了数字化转型的迫切发展需求吗？当一个真正成熟的企业级低代码开发平台出现在市场上时，它完全有能力以高效的开发方式满足大部分“高级”场景的功能需求。当然，目前低代码的发展还有一个“罪过”：如果各大平台使用专利技术，打造“应用墙”，或者在无代码/低代码时不得已更换“高”代码开发商遭遇限制手段，开发商不禁暴怒：行业是个“毒瘤”！对IT的新反思?归根结底，市场需求驱动着我们的生产工具。疫情的蔓延加速了全球数字化转型浪潮的进程。尽管低代码的概念很新，但技术并不新鲜。就像我们熟悉的编程语言和技术栈的演进一样，如果你以平常心看待低代码，你会发现——低代码就像软件开发生态中的一员：它打开创新发展方式，解决企业发展资源稀缺问题。开发人员和技术管理者需要重新思考并找到开发人员和IT部门的定位：技术民主化的时代不同了，商业环境和模式都变了。在云和AI的加持下，中小企业的数字化自然会带来相应的知识体系和人员业务能力模型的重构。比如现在大家可以在短视频App上轻松剪辑视频，已经不再是摄影专业人士的独门绝技，但互不影响。让专业人士更专注于各行业业务逻辑的低代码抽象。业务人员可以从逻辑层创建应用程序。非常适合短平快、生命周期短的应用，甚至可以用完即焚，比如问卷、统计。只需简单培训即可操作报表，无需麻烦IT部门。掌握全栈技能的“高”代码开发人员从事的应用创建更具挑战性，需要深厚的积累。他们还可以将业务逻辑封装成低代码模块，供低代码开发者使用。写在最后?时代在进步，技术人的板子只会越来越多。前段时间，Gartner给出了预测：到2025年，70%的新应用将采用低代码/无代码技术开发。在网上看到一个朋友的一段有趣的描述，借用一下：当你和前端调试了一个上午的接口，和PM吵了一个下午，然后一直在吵架带着自己的虫子一夜，你终于逃了出来。当梦境被一连串的报警短信惊醒时，你是不是抬头望着星空想：该不该用低码？回过头来看，低代码目前有点像“毒瘤”，但往前看，却是另一个世界。您如何看待低代码？欢迎大家在评论区留言。我们会在评论区选出三位评论和点赞最高的朋友，送上价值200元的独家技术图。欢迎大家参与~最后在此提前祝大家新年快乐，祝大家新年快乐！
