【编者按】文章不是要批评低代码，而是建议人们在使用这些工具时保持一定的谨慎态度。
我对低代码持怀疑态度。
在我从事软件咨询工作期间，经常遇到客户被低代码的快速开发和低维护成本所吸引。但他们最终常常因为以下几个原因而感到不满意：
他们需要真正量身定制的功能，而这是低代码方案无法实现的。 很多低代码方案大概只能满足公司需求的 80%。但剩下的 20% 却是工具无法直接实现的。市场营销人员通常很擅长让高管相信，这些工具能轻松搞定剩余的 20%，但实际上，这 20% 往往需要大量甚至不可能完成的定制。公司面临的选择是：这个工具的标准功能是否足够接近他们的需求，还是要试着对工具进行改造，以满足他们的特定需求？
他们在产品特定甚至是专有的编程语言中实现了大量定制功能，导致可用的开发人才非常有限。 通常情况下，企业会尝试改造低代码工具，以完全符合它们的需求。结果，它们最终得到了使用特殊语言编写的大量定制代码，这种语言的了解者非常少。如此一来，企业不得不在非常狭窄的专业领域内寻找维护人员，而不能从广泛的、开源语言开发者中挑选。
低代码平台的升级可能会破坏他们的定制实现。 在不影响与之相关联的功能的情况下升级软件是非常困难的。低代码工具需要处理那些原本不是为它设计的、由任意代码实现的用例。理论上，通过严格的 API 合约可以实现这一点，但实际上我发现许多工具在实际操作中会让定制代码在系统内部产生各种混乱。
经过一系列修改后，底层数据库结构变得非常混乱。 我见过许多公司使用低代码工具来处理那些对底层数据进行精确分析至关重要的过程。但当他们查看底层数据模型时，却发现它难以理解，比如不清楚user_attribute_47代表什么含义，或是为什么把一个字段从应用程序的第一页移动到第二页后，数据就被分散到了不同的字段中。
这篇文章不是要批评低代码，而是建议人们在使用这些工具时保持一定的谨慎态度。根据我的经验，尽管有人说在适当的情况下低代码可以表现得非常出色，但我实际观察到的是，这些工具往往存在许多不易察觉的问题。
文经转载自宝玉老师的个人博客(微博@宝玉xp )，链 接https://baoyu.io/translations/software-engineering/why-im-skeptical-of-low-code
作者 | Nick Scialli
出品 | baoyu.io
– END –
大佬观点
西门子低代码-王炯 | 西门子低代码-阮铭 | 微软-李威 | 微软-徐玉涛 | 葡萄城-李佳佳 | 葡萄城-宁伟 | SAP-陈泽平 | 华为-周明旺 | 华为云-董鑫武 | 钉钉宜搭-邵磊 | 轻流-严琦东 | 腾讯云微搭-骆勤 | 网易数帆-陈谔、严跃杰 | 百特搭-姜楠
用友-刘鑫 | 数睿数据-张超 | 奥哲-朱鹏喜 | 炎黄盈动-汤武 | 普元信息-孟庆余 | 得帆-李健达 | 瀚码技术-钟惟渊 | iVX-孟智平
Treelab-何浚炫 | 阿里-汪凤震 | 明道云-薛晨 | 上海斯歌-傅正斌
公众号后台回复【加群】
