我对低代码持怀疑态度。
在我从事软件咨询工作期间，经常遇到客户被低代码的快速开发和低维护成本所吸引。但他们最终常常因为以下几个原因而感到不满意：
他们需要真正量身定制的功能，而这是低代码方案无法实现的。 很多低代码方案大概只能满足公司需求的 80%。但剩下的 20% 却是工具无法直接实现的。市场营销人员通常很擅长让高管相信，这些工具能轻松搞定剩余的 20%，但实际上，这 20% 往往需要大量甚至不可能完成的定制。公司面临的选择是：这个工具的标准功能是否足够接近他们的需求，还是要试着对工具进行改造，以满足他们的特定需求？
他们在产品特定甚至是专有的编程语言中实现了大量定制功能，导致可用的开发人才非常有限。 通常情况下，企业会尝试改造低代码工具，以完全符合它们的需求。结果，它们最终得到了使用特殊语言编写的大量定制代码，这种语言的了解者非常少。如此一来，企业不得不在非常狭窄的专业领域内寻找维护人员，而不能从广泛的、开源语言开发者中挑选。
低代码平台的升级可能会破坏他们的定制实现。 在不影响与之相关联的功能的情况下升级软件是非常困难的。低代码工具需要处理那些原本不是为它设计的、由任意代码实现的用例。理论上，通过严格的 API 合约可以实现这一点，但实际上我发现许多工具在实际操作中会让定制代码在系统内部产生各种混乱。
经过一系列修改后，底层数据库结构变得非常混乱。 我见过许多公司使用低代码工具来处理那些对底层数据进行精确分析至关重要的过程。但当他们查看底层数据模型时，却发现它难以理解，比如不清楚user_attribute_47代表什么含义，或是为什么把一个字段从应用程序的第一页移动到第二页后，数据就被分散到了不同的字段中。
这篇文章不是要批评低代码，而是建议人们在使用这些工具时保持一定的谨慎态度。根据我的经验，尽管有人说在适当的情况下低代码可以表现得非常出色，但我实际观察到的是，这些工具往往存在许多不易察觉的问题。
