我从毕业后就一直在一家做低代码的公司工作，做低代码是一件非常复杂且糟糕的事情。

# 用户视角

# 低代码比代码更难学习

大部分人都会有这样一种感觉，低代码比代码更难学习。

主要的原因是，代码往往是图灵完备的，虽然实现一个功能可能会非常麻烦，需要编写很多东西，但是你只是写更多的代码，所以诞生了程序员这个职业。

而低代码的用户往往不是专业性很强的程序员，低代码总是希望用最简单和轻松的方式去完成一件事情。它总是以一个简单的按钮、设置项、操作开始，然后背后不知道做了多少事情。低代码就是预设好很多已经被编排好的流程，然后以一种简单直观的方式暴露给用户。

这还是在基于你开放的低代码功能是逻辑自洽的基础上，因为实际上，你的流程可能是混乱不堪的，被各种混杂的需求所裹挟，不断增加新的流程。

在追求通用性的同时，还在追求易用性。 这就是低代码的癌症。

因为低代码的难学，用户不愿意付出学习成本去使用，导致了低代码平台的推广成本很高。

到最后，可能只有自己内部的人会使用，然后，用户可能就只能把项目外包给我们？

有趣的是，低代码平台被创造出来的最初目的可能并不是卖产品，而是为了更加高效地交付外包项目。低代码平台可能从设计之初就没有优先考虑用户的易用性，而是追求功能丰富，能满足各种用户需求，让交付外包项目更快。

# 无法满足所有需求

现实世界的需求千奇百怪，不要认为仅仅靠低代码就能完成它们。

有很多的需求都是“脏需求”，没有通用性，仅仅是单个项目的指标，它们不应该被设计到低代码软件中去。一个优秀的低代码平台，只应该做通用的需求，而不是所有需求，不够通用的需求，都应该被定制开发。

# 开发视角

# 复杂和臃肿的架构

我认为低代码和阿里曾经鼓吹的中台的概念非常像，可以说，低代码就是技术中台，但是技术中台不一定是低代码，中台也不止只有技术中台。所以，中台有的问题，低代码也有。

阿里因为集团非常庞大，子公司和团队非常多，每个子公司和团队都有自己的业务，其中涉及到很多重复的内容。所以，就希望有一个提供通用服务的中台，然后每个前台的团队就可以利用中台提供的服务，快速实现业务的搭建，而不用自己重复搞一遍。

这个想法并没有什么问题，看上去可以优化企业的效率。但是，在执行的过程中，遇到了一些问题。

随着接入的业务越来越多，阿里的中台变得越来越庞大，越来越复杂。很多东西，看上去是一样的，但是具体到更加细节的地方，又不太一样，需要特殊处理、特殊对待。

低代码和中台面对的问题类似，为了处理更多的特殊情况，让这个软件看上去更加“低代码”，不停地编写更加复杂的 if-else。

这个问题导致了随着时间的推移，低代码平台的复杂度非常高，整体的架构非常臃肿，外加上迭代久了多多少少会有一些技术债，在后期推进新功能的时候非常困难。

# 总结

• 从用户的角度来说，低代码很难学，而且还不一定能满足需求。
• 从程序员的角度来说，低代码平台只要持续维护下去必然会导致软件变得极其复杂和臃肿。