为什么要构建低代码平台
背景
坐标三线城市，团队不到百人，公司在成立之初，乘着互联网金融的东风，飞速发展，在人员和业务扩张的同时，产生了非常多的问题。在解决问题的过程中，团队出现了引入成熟的低代码平台的呼声，起初我是拒绝低代码的，因为用过比如ADF,X6等商用框架，也接触过国内顶级外包大厂的框架（基于Eclipse深度定制的那种），确实对交付效率有提高，但是一旦遇到性能或者设计问题，就非常难解决，经常被同事吐槽“5%的时间完成了95%的工作，那5%的问题消耗了95%的时间”。再就是很多程序员对低代码是抵触的（学不到技术，背框架的锅等等）。
尽管存在这些疑虑，我逐渐认识到，低代码在提升交付效率方面具有不可忽视的价值。它通过统一架构和技术标准，降低了对个体能力的依赖，对于标准化输出的软件产品确实大有裨益。也曾考虑过引入成熟的低代码方案，但是技术团队一直比较摇摆，反对者多，应声者少，除开个人的小九九，更多的还是所有的低代码都有自己的适用范围，并非完全满足当下场景，在交期面前，全新的技术体系带来太多的不确定性，即没人去做承诺，也没人去做决策，于是各种问题长久的积累下，技术债务到了爆发的临界点。
在快速扩张与人员增长的双重压力下，技术体系野蛮生长，研发过程混乱不堪，小山头林立，同样的问题在多个项目中反复出现，因为团队业务涉及实际交易（钱），频发的生产事故给团队的经营曾经产生过很多困扰，很多问题影响至今无法完全消除（以后细说😁）。
项目管理不善
在前后端分离开发的大背景下，虽然让前端开发的工程化能力得到了极大的加强，但是团队角色增加的同时，也提高了对开发规范和约定的依赖，增大了人员调度的复杂度，不同的项目前后端的工作量差异较大，开发人员工作安排非常的不线性，开发人员的工作饱和度差异非常大，抢人和借了不还成了常态。
产品设计标准缺失
公司虽然行业能力强大，但是缺乏专业的软件设计背景，顶层设计中对除业务功能以外的功能没有认知，导致非业务（基础功能、运维功能等）功能设计缺失，同样的问题在不同的项目中有不同的解决方案，同样的业务在不同的开发团队中实现方案迥异，难以形成合理和有效的业务积累。
运维困难
项目没有有效知识传承，这种传承不光体现在项目管理本身，更体现在公司整体技术积累上，银行严格的运维和发版流程让开发人员的排除生产问题的难度激增，即考验研发人员的技术能力（纯命令行操作）也考验软件设计能力（日志埋点、异常设计等），经常出现人走了项目崩了的情况。
人员技能差异大
三线城市的软件开发人员技术能力上下限差异非常大，培训机构速成的人非常多，在没人用和至少能干点活这件事上，往往都会选择后者，这种饮鸩止渴的行为虽然暂时缓解了进度焦虑（人员配置齐全了），但是代码质量实在堪忧（屎山和防御性代码到处都是），如果严格按照一个开发人员日常需要的技能点对现有开发人员进行要求（java，框架，js，操作系统），那80%的开发人员将会失业。
面临市场压力
当前市场处于收缩状态，主要体现在大厂开始做下沉市场，客单价的持续下降，进入存量市场血拼阶段。拿PPT和原型或者静态页面就去忽悠客户的时代一去不复返。竞争者不光能满足客户的业务需求，同时在易用性，可维护性，可配置性等方面造成全方位的降维打击。且通常会将配置化和开放能力作为控标手段，同时基于配置化和开放能力的二开效率，在项目交付过程中是有明显的优势的，在开发阶段的人员投入要远远少于纯代码开发模式。
低代码要解决的问题
稳定的基础功能
低代码平台将多租户、用户管理、数据权限控制等基础功能标准化，集成了安全机制与多种第三方服务，能够以更高效率部署服务，减少重复工作。
可视化图形界面开发
通过无代码的表单编辑器，产品经理和初级开发人员可以快速搭建原型，大幅优化项目交付周期。
业务流程配置化
优化业务流程的开发过程，实现业务流程配置化。
将业务流程通过图形化界面进行配置化管理，把业务调度从代码控制转向数据控制，便于业务组件的积累和重用。
审批流支持
提供灵活的审批流程支持，可广泛应用于各种复杂的业务场景，提升系统的适应性和扩展性。
报表可视化
提供报表设计与编辑功能，借助API或SQL快速生成并展示数据报表，提高数据可读性。
模板和电签
通过模板快速生成文本，支持电子签名功能，提高合同和文件管理的效率。
结语
低代码并不是万能的解决方案，但它可以有效地化解当前技术分散的局面，推动技术体系的逐步统一。作为解决特定问题的具体工具，低代码平台通过组件化的方式，逐步形成软件设计的标准步骤，提高团队的基础能力。从长远来看，它为团队的技术积累和成长创造了良性循环，有效的支持团队持续发展。
