关于低代码平台，之前我也推送过两篇相关的文章，我的观点很简单：东西是好的，有它所擅长和适用的领域，但软件产品不存在银弹，低代码平台一样如此！

现在在搜索引擎上搜“低代码”这样的关键词，你会看到很多夸张的标题，比如：

• “人人都是产品经理”之后，“人人都是程序员”的时代要来了？

• 阿里、腾讯都在押注的新赛道，能让程序员告别脱发和996吗？

• 还有诸多低代码平台的公司拿到各种融资或地区性政府补贴的新闻

甚至我还在福报长的抖音账号中，看到了程序员下午坐在外面喝咖啡，说有了低代码，现在大把时间休息的短视频。。。

低代码平台真的这么神奇？我们在企业数字化转型过程中的开发任务都可以用低代码平台来解决吗？我们开发者996的宿命就这样被搞定了？

如果你正对低代码平台抱有上面幻想的话，一定要好好看看下面的内容！

先表明观点：如果你试图使用低代码平台去解决所有开发问题的时候，很有可能这样的决定将在2-3年之后带来巨大的灾难！

为什么这样说呢？下面结合我们10年前的实践，给大家说道说道！

伪新技术

你没看错，是结合10年前的实践！所以，低代码平台并不是什么新概念，我们10年前就玩过了！

记得以前在宇宙行的时候，就有一阵推行过一套开发平台，里面也是提倡大家用拖拽的方式去实现各项业务功能。

领导们也都非常推崇，希望通过这套平台的使用，对开发效率带来革命性的变化。

当然当时的平台，与如今的低代码平台还是有一些差距，目前所见的平台会更加完善（界面好看了，控件也多了），但从一名从业十多年的开发人员角度去看，并没有质的进步，这样的程度距离淘汰开发者还有很长的路要走。

效率毒药

低代码平台是效率毒药！

按照各种产品的宣传来看，低代码平台的目标是要解放我们，让我们更快的开发产品，那为什么说低代码平台是效率毒药呢？宣传是骗人的吗？

宣传并没有骗人，当我们实际去使用的时候，你会发现，开发一些简单应用的时候，确实会快很多！

同时，在我们过去的实践过程中，开始时候的效率是可以的！这取决于两方面的功劳：

1. 小范围的试错

2. 简单应用的先行

但随着推广的铺开，也逐步的会面临这几个问题：

1. 平台支持成了瓶颈：大量使用问题、各种平台报错都堆积到低代码平台的负责团队。对于平台的人员支持，不可能给每个业务系统都配置一个支持人员吧？所以当应用面一旦扩撒，平台支持团队很快会成为整个系统内的效率瓶颈。

2. 扯皮问题开始增多：当出了线上事故开始定则的时候，原本系统之间可能会存在扯皮，但有了低代码平台之后，系统内的实现也多了一个扯皮方向。到底是组件Bug还是使用问题？使用问题的话，文档写清楚这种特殊情况不行了吗？这种新扯皮姿势的出现，阻碍了解决问题的效率。

之所以说低代码平台是效率毒药，因为在一开始的时候，你是感觉不到的，甚至可能觉得还不错，只有在逐步深化应用，全面推行的时候，它的毒性就开始发作了！

创新毒药

低代码平台是创新毒药！

关于创新，第一点弊端，你一定会想到，就是固化组件的问题，让所有的实现都千篇一律。但这个在如今的低代码平台上，其实有好的解决方案，那就是各种自定义实现。但既然用平台是为了让业务开发更专注业务，同时在使用低代码平台之后，这样的组件创新任务，往往又都回到了平台侧的支持上。

于是，最经典的一幕就出现了：

产品经理：这个功能，我们想这样...这样...再这样...可以不？开发人员：平台没这个模块，实现不了 ... 产品经理：平台能做个模块支持下吗？低代码平台：这个需求，我们下个版本可以考虑下 产品经理：下个版本什么时候？低代码平台：半年后...要么你先用xxx组件 + yyy组件这样...那样...最后...先凑合一下？产品经理：...

这是当时很真实且频繁出现的场景！业务总是千变万化的，然而平台的功能总是滞后的，作为业务开发，必须通过平台实现，很多时候因为缺乏灵活性，让开发失去了原有的创新能力。同时，也成了开发人员拒绝业务需求的神兵利器。

记得在那个时期，基本上所有的项目都是差不多的样子...毫无新意可言，这怎么会促进业务创新呢？平台的迭代速度成为了创新的毒药！

摆正姿态

为什么效率、创新这些低代码平台原本所要追求的愿景最终会成为摧毁团队的毒药，给团队带来负面影响呢？

这里固然有销售方过渡吹嘘的责任（就如前几年阿里中台的乱吹乱用，让不少买单企业骂娘！），但作为引入这类平台的管理者来说，也有不可推卸的责任。

根据过去的负面经历，不妨思考一下：为什么推荐给开发人员会出现那么多反面的效果？

我认为造成这个核心问题还是由于平台提供能力与使用人员能力的不匹配所造成的。

回想一下低代码平台的目标是什么？

• 上手速度快

• 开发效率高

• 研发成本低

• 部署时间短

• 维护成本低

综合起来就是：有效提高团队效率。但到底是提高什么团队的效率呢？既然推向开发团队，受到如此多的白眼，那么推向产品侧？运营侧？是否可行呢？

试想一下，低代码平台的目标是要降低了上手门槛，那么对于开发人员而言，他好不容易具备了门槛知识，突然又用低代码平台来给他用，然后告诉他，你之前的开发方式不用了，可以花更多精力专注于业务的思考了。是不是这样的目标就很奇特呢？从原本更灵活的开发手段，到使用低代码平台的限制方式，不是浪费了原有开发人员所具备的更灵活的开发能力？然后还要开发人员专注去学习业务？那么学习业务的效率和准确度能有保证吗？是不是有种好不容易招了批练武奇才，学会了九阴白骨爪，然后给发了副手套，去挠痒痒么？这是不是一种人才的降级使用呢？

再换个角度想想，如果低代码平台推向产品侧呢？本身他们有更专业的业务背景，然后依靠低代码平台，拖拖拽拽就能完成一套业务系统的开发，这样的使用方式，似乎更配得上低代码平台降低上手门槛的目标？因为没有占用开发人员的资源，因此也为公司极大的降低了研发成本？大大提高了业务系统的开发效率？而开发团队更应该去做的是低代码平台无法做到的那些更具有创新意义，或更具备挑战的开发任务，不是吗？

似乎把低代码平台推向产品侧会得到很好的效果？愿景很美好，但现实也是很骨感的！最近，我就尝试着给几位产品经理朋友，搞了一些小合作，因为正好公司运作也需要一些工具，然后推荐了几个低代码平台让他们去尝试，但结果并不完全令人满意，不过似乎我也从中得到了一些新的启示！

我发现，如果产品经理拥有一些开发背景、学过编程、或是软件专业毕业的话，在使用低代码平台的时候，效果就尤为突出。也许是因为他们的知识背景具备一定软件开发的思维模式，结合对业务的理解，所以对于低代码平台的应用就更为友好！

所以，对于低代码平台，好东西是无可厚非的，但使用姿势一定要正确！任何东西只有用对了地方，才能成为神器！放错位置的神器，有时候连垃圾都不如。

那么你觉得低代码平台如何呢？你们的使用姿势是怎么样的？有没有不舒服的地方呢？留言说说你的想法吧！

往期推荐

Spring Boot 解决跨域问题的 3 种方案

把 14 亿人都拉到一个微信群，在技术上能实现吗？

这样统计代码执行耗时，才足够优雅！

来看看Google的未来工作环境设计，有你喜欢的元素吗？

小小登录，大大讲究！你的登录功能都做到位了吗？

如果你喜欢本文，欢迎关注我，订阅更多精彩内容

关注我回复「加群」，加入Spring技术交流群

喜欢的这里报道

↘↘↘