低代码在22~23年左右的时候，这个概念是最火的，同时期，若依开源项目也在这期间加入了低代码的功能。
之后，在23年低代码的风潮达到了鼎盛，但是之后就陷入了 各种声音的质疑中，最后陷入的沉寂。
正文
低代码的没落并非是低代码本身的没落，而是需求本身的没落。
低代码平替
低代码并非万能银弹，在开发者的世界里，是不可能存在万能的银弹的。
银弹，即纯银质或镀银质的子弹。在古老的欧洲民间传说、鬼怪题材的小说和电影，尤其是19世纪以来哥特小说风潮影响下，银色子弹往往被描绘成是狼人和吸血鬼、女巫以及其他怪物的克星，一发即可致命，并具有驱魔的效力。
后来在开发中，有人比喻为万能解法，因为很多西部片和小说中的不死邪魔经常都被一发银弹解决，这种不讲道理的方式，就被戏称为银弹，在戏剧中也有类似的玩法，叫做机械降神，不过这个就不细展开说了。
无论是银弹还是机械降神，都是比喻一种万能解法，而在开发者的世界中，这种万能的银弹是不存在的。
低代码的诞生和火爆，离不开早些年互联网的火爆，各种ToB（面向公司老板），ToC（面向客户），ToG（面向政府）等业务的不断上扬和增加，这时候，不可避免的出现了N多的管理系统。
一旦管理系统落成，那么不可避免的，就要对表的增删改查。
这时候，很多开发者不可避免的要一遍又一遍的陷入前端写表单列表，后端写curd的接口，在这种重复业务中不断耽误时间，加班赶进度，却十分枯燥的情况。
针对这种情况，于是才有了低代码。
但是低代码，却绝非是现代才有的概念，而是很早之前就有的概念，早在现代低代码概念爆火之前，就有类似的说法。
说穿了，低代码就是配置化系统的变种，但是生成出来的代码又需要一定开发技术去按照需求修改，相对于传统的工具系统，这种低代码平台肯定更好用。
譬如ERP，CMS及等工具系统，对已经固定的业务线，仅仅需要配置就可以配置好一个系统，供用户使用，这应该就是最早的低代码系统。
应用场景
低代码并非是小型公司可以玩转的东西，这东西的诞生是为了解决特定的场景内的需求。
个人曾在公司有幸接触过相关业务，所以这里分享一下低代码的具体的应用场景及基础要求。
适合的场景
注意，需要满足以下绝大多数条件的，可以考虑在公司产品中加入低代码的功能，否则开发用来造轮子的工作时间会远大于使用低代码这个轮子的节约的时间。
- 重复的业务场景，需要消耗大量人力时间去写重复的增删改查工作量
- 业务线路稳定，不会频繁变动，多数业务逻辑可以拆分成简单的增删改查实现
- 表单关系简单，相互之间交互关系不大
- UI风格稳定，需求方对UI不做大规模的变动要求，并且基于这个稳定的UI库，形成一套属于公司自己的风格
- 稳定的组件库，能够极大程度减少代码生成文件的代码量，便于改动
- 如果有双端适配的要求，那移动端也要有稳定的组件库和设计风格，同时业务量不要统一
- 前端基建相对稳定，脚手架，工具包，组件库都统一，并基建代码和业务代码能够并行推进，相互干扰程度小
- 稳定的权限管理功能，从路由到按钮级别的管理，不是一个混沌的权限管理系统（在很多中小厂中至今没有一个像样的权限管理系统）
- 前端负责人需要对公司业务有较为深层的了解，能够把控和预测公司接下来的发展方向，不会完全受制于设计或者后端，不至于一点话语权也没有。
综上，我们会发现，这并非是个小公司使用的工具。
低代码的诞生，是一个团队的工作成果。
稳定的UI，业务线，产品化的前后端框架，成熟的运维人员，几乎缺一不可。
低代码热门的场景，大概是中型公司或者大厂业务部门中常用的工具，通过这东西，应该可以快速生成一些增删改查的表单，快速完成项目任务。
而小厂接到的业务，多数个性化要求较高，甚至是外包业务，根本就不在乎你用什么技术，混乱的项目管理根本不适合低代码的的使用。
低代码优劣
开发者固然要追求更新潮，更有趣的技术，这是一个开发者固有的技术素养。
但工程不能，工程是一个公司，一个团队的心血，工程要以稳定为主，你可以小步迭代，决不能贸然使用不稳定的技术。
毕竟，所有的技术诞生，都是为了解决某种特殊的需求，不要为了技术追星，去强上看上去很酷炫的技术。
这里我列举一下低代码的优劣，各位可以根据自己的需求权衡，是否在公司内使用
优势
- 大量节省人力，原本一个项目至少需要一个熟手前端，后端同时协同开发数月才能完成一个项目，而使用低代码之后，简单的项目完全可以由一个运维人员通过简单的配置，生成一个系统，个性化的页面申请给开发部调整，将数月级别的项目缩减到两周。
- 可以快速迭代项目，很多时候需求方不清楚自己需要什么，而我们通过对表单的和列表的配置，很容易就能让客户明白自己的缺陷和需求，这样便于快速迭代，但是注意，不要被客户套进去。
- 使用简单，基本上一个运维人员通过培训，只要稍微有点项目经验和些许的开发经验，就可以覆盖一个项目现场，一旦完成交付后，还可以快速迭代到下一个项目现场。
劣势
- 技术固化。随着项目的不断推进，低代码系统涉及到的组件库必须得稳定维护，组件库会随着项目的增多而不断臃肿，随着时间的增加，低代码的尽头必然是需要前端组长花很大的力量去维护和平衡各个项目现场的需求。
- 项目臃肿。很多人在使用低代码的时候，简单生成了代码，后续这里不用之后，就隐藏废弃，代码也不会删除，时间长了之后，这种废弃代码就堆在业务系统中，久而久之，这项目就会很臃肿。
- 依赖管理困难。各个前端项目没有版本锁，当时Pnpm也没有流行开来，现在相对来说应该好的多，但是随着时间的推移，这种组件库的适配早晚也会在依赖管理上出问题的。
结语
很多大厂的为了做业绩，在那两年几乎把这玩意吹成了万能银弹，这是不对的。
在它的固有领域内，低代码能极大节省人力，减少开发者的业务工作量，让开发者更专注于自身的开发优势，不过这也让开发者更远离业务，难以进入业务管理层了。
总之，有利又有弊，是否使用低代码，需要根据自身情况做决定。
最后，给自己的掘金引个流：工程提速，低代码的意义 - 掘金 (juejin.cn)。
希望大家能关注我，多多点赞，谢谢！
参考
无