对于低代码平台，之前我也推送过两篇相干的文章，我的观点很简略：货色是好的，有它所善于和实用的畛域，但软件产品不存在银弹，低代码平台一样如此！
当初在搜索引擎上搜“低代码”这样的关键词，你会看到很多夸大的题目，比方：
- “人人都是产品经理”之后，“人人都是程序员”的时代要来了？
- 阿里、腾讯都在押注的新赛道，能让程序员辞别脱发和 996 吗？
- 还有诸多低代码平台的公司拿到各种融资或地区性政府补贴的新闻
甚至我还在福报长的抖音账号中，看到了程序员下午坐在里面喝咖啡，说有了低代码，当初大把工夫劳动的短视频。。。
低代码平台真的这么神奇？咱们在企业数字化转型过程中的开发工作都能够用低代码平台来解决吗？咱们开发者 996 的宿命就这样被搞定了？
如果你正对低代码平台抱有下面空想的话，肯定要好好看看上面的内容！
先表明观点：如果你试图应用低代码平台去解决所有开发问题的时候，很有可能这样的决定将在 2 - 3 年之后带来微小的劫难！
为什么这样说呢？上面联合咱们 10 年前的实际，给大家说道说道！
伪新技术
你没看错，是联合 10 年前的实际！所以，低代码平台并不是什么新概念，咱们 10 年前就玩过了！
记得以前在宇宙行的时候，就有一阵推广过一套开发平台，外面也是提倡大家用拖拽的形式去实现各项业务性能。
领导们也都十分推崇，心愿通过这套平台的应用，对开发效率带来革命性的变动。
当然过后的平台，与现在的低代码平台还是有一些差距，目前所见的平台会更加欠缺（界面难看了，控件也多了），但从一名从业十多年的开发人员角度去看，并没有质的提高，这样的水平间隔淘汰开发者还有很长的路要走。
效率毒药
低代码平台是效率毒药！
依照各种产品的宣传来看，低代码平台的指标是要解放咱们，让咱们更快的开发产品，那为什么说低代码平台是效率毒药呢？宣传是骗人的吗？
宣传并没有骗人，当咱们理论去应用的时候，你会发现，开发一些简略利用的时候，的确会快很多！
同时，在咱们过来的实际过程中，开始时候的效率是能够的！这取决于两方面的功绩：
- 小范畴的试错
- 简略利用的后行
但随着推广的铺开，也逐渐的会面临这几个问题：
- 平台反对成了瓶颈：大量应用问题、各种平台报错都沉积到低代码平台的负责团队。对于平台的人员反对，不可能给每个业务零碎都配置一个反对人员吧？所以当利用面一旦扩撒，平台反对团队很快会成为整个零碎内的效率瓶颈。
- 扯皮问题开始增多：当出了线上事变开始定则的时候，本来零碎之间可能会存在扯皮，但有了低代码平台之后，零碎内的实现也多了一个扯皮方向。到底是组件 Bug 还是应用问题？应用问题的话，文档写分明这种非凡状况不行了吗？这种新扯皮姿态的呈现，妨碍了解决问题的效率。
之所以说低代码平台是效率毒药，因为在一开始的时候，你是感觉不到的，只有在逐渐深入利用，全面推行的时候，它的毒性就开始发生了！
翻新毒药
低代码平台是翻新毒药！
对于翻新，第一点弊病，你肯定会想到，就是固化组件的问题，让所有的实现都千篇一律。
但这个在现在的低代码平台上，其实有好的解决方案，那就是各种自定义实现。
既然用平台是为了让业务开发更专一业务，同时在应用低代码平台之后，这样的组件翻新工作，往往又都回到了平台侧的反对上。
于是，最经典的一幕就呈现了：
产品经理：这个性能，咱们想这样 … 这样 … 再这样 … 能够不？
开发人员：平台没这个模块，实现不了
…
产品经理：平台能做个模块反对下吗？
低代码平台：这个需要，咱们下个版本能够思考下
产品经理：下个版本什么时候？
低代码平台：半年后 … 要么你先用 xxx 组件 + yyy 组件这样 … 那样 … 最初 … 先对付一下？
产品经理：…
这是过后很实在且频繁呈现的场景！业务总是变幻无穷的，然而平台的新性能总是滞后的，作为业务开发，必须通过平台实现，很多时候因为不足灵活性，让开发失去了原有的创新能力。同时，也成了开发人员回绝业务需要的神兵利器。
记得在那个期间，基本上所有的我的项目都是差不多的样子 … 毫无新意可言，这怎么会促成业务翻新呢？这样的平台简直成为了翻新的毒药！
摆正姿势
为什么效率、翻新这些低代码平台本来所要谋求的愿景最终会成为毒药，给团队带来负面影响呢？
这里诚然有销售方的过渡吹牛，就如前几年阿里中台的乱吹乱用，让不少买单企业骂娘！但作为引入这类平台的管理者来说，也有不可推卸的责任。
依据过来的负面经验，无妨思考一下：为什么举荐给开发人员会呈现那么多背面的成果？
我认为造成这个外围问题还是因为平台提供能力与应用人员能力的不匹配所造成的。
回忆一下低代码平台的指标是什么？
- 上手速度快
- 开发效率高
- 研发成本低
- 部署工夫短
- 保护成本低
综合起来就是：无效进步团队效率。但到底是进步什么团队的效率呢？既然推向开发团队，受到如此多的白眼，那么推向产品侧？经营侧？是否可行呢？
试想一下，低代码平台的指标是要升高了上手门槛，那么对于开发人员而言，他好不容易具备了门槛常识，忽然又用低代码平台来给他用，而后通知他，你之前的开发方式不必了，能够花更多精力专一于业务的思考了。是不是这样的指标就很奇异呢？从本来更灵便的开发伎俩，到应用低代码平台的限度形式，不是节约了原有开发人员所具备的更灵便的开发能力？而后还要开发人员专一去学习业务？那么学习业务的效率和准确度能有保障吗？是不是有种好不容易招了批练武奇才，学会了九阴白骨爪，而后给发了副手套，去挠痒痒么？这是不是一种 人才的降级应用 呢？
再换个角度想想，如果低代码平台推向产品侧呢？自身他们有更业余的业务背景，而后依附低代码平台，拖拖拽拽就能实现一套业务零碎的开发，这样的应用形式，仿佛更配得上低代码平台升高上手门槛的指标？因为没有占用开发人员的资源，因而也为公司极大的升高了研发老本？大大提高了业务零碎的开发效率？而开发团队更应该去做的是低代码平台无奈做到的那些更具备翻新意义，或更具备挑战的开发工作，不是吗？
仿佛把低代码平台推向产品侧会失去很好的成果？愿景很美妙，但事实也是很骨感的！最近，我就尝试着给几位产品经理敌人，搞了一些小单干，因为正好公司运作也须要一些工具，而后举荐了几个低代码平台让他们去尝试，但后果并不齐全令人满意，不过仿佛我也从中失去了一些新的启发！
我发现，如果产品经理领有一些开发背景、学过编程、或是软件业余毕业的话，在应用低代码平台的时候，成果就尤为突出。兴许是因为他们的常识背景 具备肯定软件开发的思维模式，联合对业务的了解，所以对于低代码平台的利用就更为敌对！
所以，对于低代码平台，好货色是无可非议的，但应用姿态肯定要正确！任何货色只有用对了中央，能力成为神器！放错地位的神器，有时候连垃圾都不如。
那么你感觉低代码平台如何呢？你们的应用姿态是怎么样的？有没有不难受的中央呢？留言说说你的想法吧！如果你想与更多乏味的灵魂碰撞，也能够退出咱们的技术交换群一起探讨咱们的技术人生！
欢送关注我的公众号：程序猿 DD，分享其余中央看不到的常识与思考