为什么现在低代码平台推进阻力那么大？

“在踏出一步之前，首先考虑能否退回去”

现在低代码平台，功能性能这些先不说，能不能提升效率，提升多少，暂不讨论。光“平台和环境锁定”这一点，就是整个行业最大的技术推广障碍。道理很简单，平台有几百个，但是如果选了一个，由于无法生成代码，代表所有的研发和数据资源都要放在这个平台上，将来根本无法迁移。这意味了，“一旦跨出了这一步，将无法退回到原来的道路上！”，这对任何企业和团队都是很难接受的，风险太大。

“以前的代码和研发/数据资源怎么办？”

每个企业，由于长时间的研发和演进，往往都形成了自己的研发体系和自有的研发资源/数据资源，这些资源如何在“低代码平台”上使用也是一个问题。

我们的SDK可以传上去吗？

我们现有的组件可以直接使用吗？

我们团队用惯了elementUI，要怎么接着用？

我们大量各种类型的数据和接口要如何使用？...

"另外，程序员本身也是平台使用的阻力"

对于这样的平台，很多程序员有一个“本能的抗拒”，当然最主要的还是担心如果技术被锁定在某一个低代码平台，会不会影响将来“自身的技术提升”，甚至会不会影响自己的收入？当然，还有更深层次的原因，这和程序员的心态也息息相关。

总之，企业选型什么技术什么平台？肯定是研发总监/CTO/CIO说了算，而他们又会去征求技术团队的意见，如果技术团队大部分人反对，这个技术肯定推不起来。

解决这个问题的两条思路

一、能不能统一低代码平台的标准？

其实根本就不可能，无论是通过开源的方式，还是大厂背书和推进... 其实都不可能。其实，技术只有演进，很少能通过形式化的东西固定下来，除非是已经既成事实的部分。

二、“生成代码”！！！

这也是我想说的，真正可行的，能够被程序员接受的“低代码平台”落地方案。生成的“代码”通过编程语言的方式，将形式统一起来。这也就是实现了“平滑演进”，而非“跃进”，历史上二进制向汇编语言，汇编语言向高级语言，也都是这样的“平滑模式”。

“低代码平台全栈都给你生成代码，所有应用以代码形式保存起来”——这才是能够被研发团队接受的形式。

三、下面是一个代码生成式低代码产品

 

 

现在代码生成已经具备“可读”、“可调试”的能力，体验上和手写代码没什么区别，包括维护的方式。

总之，只给程序员助力，不要去挑战程序员，应该是比较理性的做法。其实，对于这样的平台，很大程度上已经不用手写任何代码，包括二次开发都可以在平台上通过拖拽配置的方式完成，但是，为程序员保持“代码”这种接口，很重要！