为什么现在低代码平台推进阻力那么大？
“在踏出一步之前，首先考虑能否退回去”
现在低代码平台，功能性能这些先不说，能不能提升效率，提升多少，暂不讨论。光“平台和环境锁定”这一点，就是整个行业最大的技术推广障碍。道理很简单，平台有几百个，但是如果选了一个，由于无法生成代码，代表所有的研发和数据资源都要放在这个平台上，将来根本无法迁移。这意味了，“一旦跨出了这一步，将无法退回到原来的道路上！”，这对任何企业和团队都是很难接受的，风险太大。
“以前的代码和研发/数据资源怎么办？”
每个企业，由于长时间的研发和演进，往往都形成了自己的研发体系和自有的研发资源/数据资源，这些资源如何在“低代码平台”上使用也是一个问题。
我们的SDK可以传上去吗？
我们现有的组件可以直接使用吗？
我们团队用惯了elementUI，要怎么接着用？
我们大量各种类型的数据和接口要如何使用？…
“另外，程序员本身也是平台使用的阻力”
对于这样的平台，很多程序员有一个“本能的抗拒”，当然最主要的还是担心如果技术被锁定在某一个低代码平台，会不会影响将来“自身的技术提升”，甚至会不会影响自己的收入？当然，还有更深层次的原因，这和程序员的心态也息息相关。
总之，企业选型什么技术什么平台？肯定是研发总监/CTO/CIO说了算，而他们又会去征求技术团队的意见，如果技术团队大部分人反对，这个技术肯定推不起来。
解决这个问题的两条思路
一、能不能统一低代码平台的标准？
其实根本就不可能，无论是通过开源的方式，还是大厂背书和推进… 其实都不可能。其实，技术只有演进，很少能通过形式化的东西固定下来，除非是已经既成事实的部分。
二、“生成代码”！！！
这也是我想说的，真正可行的，能够被程序员接受的“低代码平台”落地方案。生成的“代码”通过编程语言的方式，将形式统一起来。这也就是实现了“平滑演进”，而非“跃进”，历史上二进制向汇编语言，汇编语言向高级语言，也都是这样的“平滑模式”。
“低代码平台全栈都给你生成代码，所有应用以代码形式保存起来”——这才是能够被研发团队接受的形式。
三、下面是一个代码生成式低代码产品
现在代码生成已经具备“可读”、“可调试”的能力，体验上和手写代码没什么区别，包括维护的方式。
总之，只给程序员助力，不要去挑战程序员，应该是比较理性的做法。其实，对于这样的平台，很大程度上已经不用手写任何代码，包括二次开发都可以在平台上通过拖拽配置的方式完成，但是，为程序员保持“代码”这种接口，很重要！
文章来源：DevPress低代码技术专区
作者：troymeng
– END –
开发者大赛
报告下载
大佬观点
