各大厂商都在研发自己的低代码平台，一时之间低代码平台似乎成了国内IT界的宠儿。低代码的火爆并不是偶然，而是资本对效率的极致追求下的必然产物。
低代码平台的优势其实很多人都清楚，降低开发成本、提升开发效率、降低开发门槛等等，鼓吹的人比较多，这里就不再赘述了。我在19年左右开发过低代码平台（当时公司内称为表单引擎），在这里结合自己的一些经历系统地谈一谈低代码平台的痛点。
自由度和使用门槛
低代码平台使用者首要关注的就是自由度了，不少人觉得低代码平台自由度低，在面对复杂业务的时候不能很好处理。其实这个是取决于低代码平台在自由度和定制化程度之间如何取舍，鱼与熊掌不可得兼，定制化程度高，自由度就低，自由度高，配置就复杂，使用门槛高。
有的人会认为低代码平台的作用只在于解决大部分简单的场景的重复低效开发，复杂页面还是坚持用传统的开发方式走。这个观点似乎没什么问题，但是忽略了一个细节，边界在哪？如何去确定一个业务模块是否能够用低代码平台实现？
低代码平台的开发者最清楚低代码平台的能力边界，但是当低代码平台的用户量上去之后，开发者是不可能去看每一个需求是否能用低代码平台开发的（不过免不了被各种问）。其次是低代码平台的熟练使用者，但这要求使用者对需求和平台都有细致深刻的了解，有些看似简单的功能在实现起来的时候就会发现并不能做到。
如果需求不符合平台的功能，那么就只有两条路可以选：
- 升级平台的功能。
- 用传统的方式重写模块。
无论是哪一条路实际上都是巨大的代价，这是某技术群里使用者的真实体验： "我们之前用过一个拖拉拽的，用户提了需求，导致逻辑更改。改了快两个月没改好。如果是改代码，只需要2个小时。以我们的血的教训来看，最终下来，拖拉拽的方式最终都会让我们很被动，甚至成本更高。"
错误排查
一般来说，低代码平台的配置都需要遵循一定的规则，因此在实际使用过程中难免会出现配置错误的问题。一般简单的输入输出错误可以通过校验来提示告诉用户配置不对，但是一些配置逻辑上存在问题是很难提示出来的，因此排查bug就成了一个难点。
部署在线上的低代码平台是无法调试的，低代码平台的用户可能未必是前端，这部分用户本地搭建代码运行环境来调试是基本不可能的。就算由前端来调试，由于低代码和传统开发是截然不同的两种方式，即使是前端基础比较好的用户也很难定位到问题所在。
所以这就造成用户容易困惑是平台有问题还是自己有问题，就不得不一直找平台的人去定位解决问题，这样对平台的开发、运维也是一个很大的负担。
可读性、可维护性
低代码平台的组件就像一个个孤岛，组件之间的交互需要依赖定义好的通信方式来进行通信，也就是需要用到发布-订阅（观察者）模式。传统开发中大量使用这种模式本身就不易于阅读和维护，更何况是在所见即所得的低代码平台，你还得选中相关的组件，阅读其事件配置，跟着事件流一步步地走，一旦事件流较长或分支较多，理解成本就大大增加。
总结
低代码平台实际的使用场景更多地集中在B端应用，适合业务比较稳定的模块，而C端应用，交互较少的展示类模块可以使用（但其实展示类模块使用的性价比也不高），其他的功能性的模块使用需要非常谨慎，毕竟C端的需求更多元化，对于性能的要求更高。
低代码平台现在仍处于比较尴尬地境地，有些做的不好的干脆直接退化为搭原型的工具，而未来的发展会不会更好，目前我的看法是发展有限，毕竟有些矛盾是无法彻底解决的，只能根据自家的情况尽量找到一个合适的平衡点。
说了这么多，其实我并不是想给低代码平台泼冷水，毕竟自己也是花了不少心思在上面的，只是想把所见所闻的坑分享出来，让入坑的小伙伴们有个底。
