低代码平台之殇-(我和低代码平台的相爱相杀)

5,034 阅读12分钟

前言

   低代码平台是前端开发过程中,每隔一段时间都有热度的概念。但是关于代码平台是什么,和为什么最终低代码平台最终走向寂静。缺少相关的信息。本人是5年的前端开发,曾效力于多家公司进行低代码的开发,目前在一个中厂担任前端工程师,我将用3个自己亲生经历的低代码平台的消亡故事。告诉各位领导和产品还有前端同行们低代码平台的概念以及你在选用它时必须考虑的风险,以下故事都是我的血泪史供大家参考。(产品  领导老大们 看故事  技术讨论开发人员可以讨论一下技术点)。

下图用来形容低代码平台的技术形象。

src=http___pic128.huitu.com_res_20190829_781344_20190829232004471070_1.jpg&refer=http___pic128.huitu.webp

Web1.0-2.0 架构 (前端基本功拧螺丝)

src=http___img.alicdn.com_tfscom_i1_2180717753_TB27CWzjwoQMeJjy0FnXXb8gFXa_!!2180717753.jpg&refer=http___img.alicdn.webp

vue 架构 (效率的质变提升)电动

src=http___cbu01.alicdn.com_img_ibank_2016_534_907_2837709435_1657178289.jpg&refer=http___cbu01.alicdn.webp

低代码平台 (我们基于xxx技术创新,在XXX技术的基础上进行创新,结合市面上的创新技术进行了全新的升级,创造性的发明了XXX低代码平台)--论低代码平台创新吹KPI (是否效率提升不说)

故事一

A 公司老大,去某大厂的研讨会后,听到了一个新词语 ,低代码平台。大厂的描述中,低代码平台节约效率。未来前景可观。简直就是未来的风口。
于是老大召集大家开会,问能否去做。二级边缘部门刚晋升的后端技术管理人员。老B觉的这是个非常好的机会。于是果断答应了下来。但是公司没有前端开发人员。老B的资源只能招一个刚毕业的前端小白。但是老B发扬了不怕加班的吃苦精神。和刚招到分公司的小C进行了不断加班去建立了低代码平台。小C是低代码开发的主要负责人。但是他技术不精。前期也没有产品进行范围识别。都是老B要做什么。小C就开发什么。此低代码平台是配置式的低代码平台。需要后端去管理界面配置XML文件,经过接口然后在去控制生成的页面中的表单元素。其他的都不能完成。唯一的亮点可能就是可以配置生成页面。但由于小C基础较差。完全没有项目的文件管理。主要的代码全用vue 写在了一个文件上。并且使用了uni-app  vant  element  等多种插件和框架,藕合性很高。导致后续的维护只能由小C完成。开发了一半后。A公司老大看到了初步成果。于是给老B,增派了一个前端人员小D。
小D被召进来主要是用来接替小C的工作。小C由于建立低代码平台的优秀贡献和老B一起得到了晋升。被老B带去做前景更好的项目。但是由于小C前期使用的技术混乱。代码业务耦合性非常高。小D的工作进展的十分缓慢。老B前期宣传低代码平台极大的提升了前端开发效率,但是实际过程中小D由于不熟悉平台的底层逻辑,一要填坑二要开发新项目,天天加班到凌晨。6个月后老B接了一个2周完成6页面的项目。指定用低代码平台开发。老板专门拿去给投资人融资的。老B指派给了小D,项目开发的完成前2天,老板提出了30%以上的改动。小D硬着头皮加班了5天到凌晨进行修改。  事后由于延期老B对小D十分不满。于是劝退小D。
低代码平台也招到了大领导的不满,在开讨论后决定废弃低代码平台的开发, 至此A公司低代码平台。开发2年,老B,小C因为KPI良好升职,小D出局。由于小C认为低代码平台难用不好维护。选择废弃低代码平台,改用原来的Vue 框架。至此A公司2年工时成果的低代码平台只用了3个月。仅开发一个项目。

故事二

某中型企业B长期做国企的项目。帮助国企开发能源智能化平台。于是B企业管理层,觉得低代码平台。能够完成重复的工作,所以决定采用低代码平台去做前端固定的工程。但由于前期由多个部门的人共同开发。导致项目的文件应用框架十分庞大。低代码平台的代码量巨大。
各个部门之前相互扯皮。由于客户所提出的定制项目的范围不断的改变,为满足客户。低代码平台的代码量越来越高。代码耦合度也越来越高。大批的人员离职。原来的精干的开发人员都离职。B公司想不断的招人进行补充。但是主营业务使用低代码平台的培养人的成本十分巨大。且无法留住人才。无奈B公司管理层决定弃用低代码平台。B公司结果,收入下滑,股价下跌30%。前端团队基本离职,待满3年的前端人员只有个位数。最后低代码平台被弃用。

故事三

某中型厂的领导C,想赶上前端技术潮流。进行技术性创新,认为前端低代码化是未来潮流。于是找到了某全栈开发工程师老D。老D经验丰富。技术能力很强。且专门负责公司的架构,不做具体的项目和定制。为了达到当年的KPI。接下了这个项目要求。老D很清醒的知道低代码的使用场景。于是老D将低代码平台应用到了数据看板项目。和商业处理优化中。老D采用的低代码平台是可拖拽式的低代码平台。业务应用场景单一。所以后端人员可以根基业务配置json很轻松的进行前端开发。得到了大家的好评。
但是领导C决定扩大战果。将之前业务场景复杂,变化多的产品A和产品B也低代码平台化,并且希望非开发人员也能使用帮助开发人员减轻负担。老D思索后接下来这个任务。由于业务场景十分复杂。配置已经不能满足需要。If else 场景十分的多。基于可实现的角度。老D在这个基础上引入了一个可视化的脚本编辑功能,就此此低代码平台变成了一个需要写js脚本的平台。并且无法使用直接的vue写法。约等于js的第一代,操纵dom去改数据。于是老D不断优化,但是也只是不断增加api,去实现之前vue实现的功能点,且不能定义组件。领导C为了证明低代码平台的便利性,将原来别的组负责的业务工作也划分到本组,并且将原来6个人的岗位缩小到4个人进行开发,新召入的用低代码开发项目的新人都感觉压力很大准备离职。老D以自己只负责技术架构为由不参与业务开发。此次低代码开发的结果,领导C ,老D升职。新召的新人成为KPI的炮灰。低代码平台实际降低了开发效率,当扩展为业务很复杂场景时。导致了崩盘。低代码平台不仅没有增加效率,反而导致了离职和冗余。

低代码平台失败分析

故事就是这些,真实绝无杜撰。先和大家闲聊一下。就前端来说。其实最有名且影响力最大的平台想必前端开发人员都知道,Dreamveawer,这个Adobe公司的最早的前端入门工具,就是一个可拖拽的HTML生成器。可到了现在却很少有人使用了。原因大家都知道。总结就是功能弱,无法满足所有的业务场景。而后面大红的vue 和react框架替代了HTML的CSS模版编辑的模式本质上就是能满足多种复杂的交互场景。一个技术如果能满足更多场景,且能用更方便的模式去实现功能,不用推广,市场会自然演化淘汰旧技术。而不用特地去动用管理的行政命令去强制使用。

说回图。放上这个图是想告诉大家。大部分的低代码的平台,在最开始的时候,就不知道要具体做什么。 这是低代码平台失败的重要原因之一。低代码平台给研发人员开发工作,尤其是前端工程师来说就好比学会电动螺丝刀之后要发明一个可换头的螺丝刀去打螺丝。原因仅仅是可以去给高层吹KPI和绩效。这3个故事中低代码平台的考虑都是领导推动,但是一个真正的好的软件工程师是不会去这样轻易的下决定的。因为一个好的软件研发者都明白一个词语叫做技术边界。有些事情是无法兼得,只能去平衡和取舍。有了这些常识我们来看下低代码平台的天生缺陷问题。

如果一个研发人员要去开发一个低代码平台,那么他必须首先意识到低代码平台的几个根本矛盾。

1 低代码平台的业务越复杂,代码越复杂。维护成本上升,到了一定程度效率会失控。低代码平台业务需求和代码复杂度对立
2 低代码平台技术的天花板 低代码平台的技术天花板可以对标现在的vue,试问一下自己能否清楚vue所有的原理,并开发出一个超越vue的平台。一个划时代的低代码平台所需要的资源公司能否给你
3 低代码平台技术的客户到底是谁?如果是给研发使用是否有必要,如果是和客户使用,客户为什么要用低代码平台。你是目标市场是哪里
4 低代码平台的设计成本,使用成本是否是公司能够给你承担的。开发一个低代码平台的成本是巨大的。很多公司根本就不会给你专门的人和时间去开发。是否想过到底要做一个什么产品。痛点在哪里。有没有市场调研?开发成本和使用成本的矛盾

回到具体的故事,以上3个低代码平台的失败案例都是我亲身经历。多年以后我回顾这几段经历,总结经验我设想过我若回到以前,以我现在的技术水平,是否在当时能做的更好。我自己做了很多思维实验。答案是否定的。根本的原因在于我能做的就是用更先进的技术,更合理的软件工程原理去实现工程去解决问题,但是我却没有能叫停的能力。好比一辆车,性能再好,加速在快。但是没有刹车。结果也就只能失控。而在这个3个故事中,刹车的掌握是在领导手上。开始的莫名其妙,研发人员甚至都没有说反对的权利。即使反对,领导说同意,你能否说服一个以kpi是创新技术的领导不用一个可以轻易刷kpi的平台?一个开始不知道使用范围,也不知道何为结束的产品,甚至连客户都不知道是谁的工程。如何成功?就算是故事3中的老D技术能力十分强悍,最终使用的开发的效率也是倒退的。

低代码平台的经验总结

低代码平台前面说了很多,难道真的是一无是处吗?答案是否定的,凡事都有二面性,有优点也有缺点。我在观察市面上的一些低代码平台时也发现了一些我个人认为很有趣比较成果的尝试。比如易企秀制作的电子请柬。个人认为十分有价值。原因是此低代码平台的场景单一,就是用于非开发人员去写电子请柬。业务需求不会无限扩张。技术范围功能都有固定的边界,且使用人员不需要懂前端的一些代码。以这个视角去看。在某些固定且重复的工作场景。将重复且有定制需求的任务非给非开发人员。确实是低代码平台的一个完美的应用场景。只是在中国的管理环境和状态下。工程师们的低代码平台开始就奔着高大上去。却忽视了开发的最根本的问题。 这件事情是否有意义。身为工程师格局如果大一些,效率优先是基本追求。其次是为前端这个环境做一些最前沿的开发尝试。新技术的意义,往往就二个方向,更快的效率和更强大的功能。 如果突破不了这个我们也就仅仅是在1.1 1.23 1.34 这样的小数位去尝试,本身毫无意义。就比如你一直开发的插入,冒泡排序本质上还是个N*N 的算法。 认识你自己认清自己在做什么事情。才是一个合格的工程师。认识自己是明辨是非的基础。 仅在此向不断学习前进的前端小伙伴们致敬。