为什么我对低代码持怀疑态度 [译]
内容提要
作者对低代码持谨慎态度：客户常被其快速开发吸引，但低代码通常只能满足约80%的需求，剩余20%需大量甚至无法实现的定制。企业往往被迫用冷门专有语言编写定制代码，导致维护人才稀缺；平台升级还可能破坏定制实现，底层数据库结构也变得混乱难懂。作者并非全盘否定低代码，而是建议使用时保持谨慎。
延伸解读
80%的陷阱：剩余20%才是成本黑洞
文章指出低代码常能满足约80%的需求，但剩余20%的定制往往需要大量甚至无法实现的工作。营销人员容易让高管低估这部分难度，导致企业陷入两难：要么接受标准功能与需求有差距，要么投入高成本改造。读者应意识到，低代码的快速开发优势可能被后期定制成本抵消，评估时需重点考察那20%的可行性。
专有语言定制带来人才锁定风险
企业为满足特定需求，常使用低代码平台特有的甚至专有的编程语言编写大量定制代码。这类语言掌握者稀少，导致维护人员只能在狭窄领域寻找，无法从广泛的开源语言开发者中招募。这增加了长期维护的难度和成本，形成对平台供应商的隐性依赖。选择低代码时，需考虑定制代码的可维护性和人才可获得性。
升级与数据结构的隐藏代价
低代码平台的升级可能破坏定制实现，因为工具需要处理非原生设计的任意代码，实际操作中容易产生混乱。此外，经过多次修改后，底层数据库结构可能变得难以理解，例如出现含义不明的字段名或数据因页面调整而分散。这会影响数据分析和系统维护。文章提醒，低代码的长期可维护性和数据清晰度是容易被忽视的风险点。
Q&A
低代码平台通常能满足企业多少比例的需求？
低代码方案大概只能满足公司需求的80%，剩下的20%往往需要大量甚至不可能完成的定制。
为什么企业使用低代码后维护起来很困难？
因为企业常在产品特定甚至专有的编程语言中实现大量定制功能，导致可用的开发人才非常有限，企业不得不在狭窄的专业领域内寻找维护人员。
低代码平台升级会带来什么风险？
低代码平台的升级可能会破坏企业的定制实现，因为在不影响相关联功能的情况下升级软件非常困难，定制代码容易在系统内部产生混乱。
使用低代码工具后底层数据库结构会变得怎样？
底层数据库结构会变得非常混乱，例如字段命名难以理解（如user_attribute_47），或字段移动后数据分散到不同字段中。
作者对低代码的整体态度是什么？
作者对低代码持怀疑态度，并非全盘否定，而是建议人们在使用这些工具时保持谨慎，因为实际中这些工具往往存在许多不易察觉的问题。
企业为什么会被低代码吸引？
企业常被低代码的快速开发和低维护成本所吸引，但最终常因定制困难、维护人才稀缺、升级风险等问题而感到不满意。
