为什么开发人员讨厌低代码

西装喜欢“低代码”工具的想法。 对他们来说，更少的代码意味着更少的工作，更少的工作意味着更快的项目，更快的满意度，更精简的预算，以及最终为那些相同的西装派发高额奖金的肉汁。 谁不喜欢这些东西？

开发者之一。 哦，他们喜欢理论上的这些宏伟承诺（谁不想做更少的工作？），但他们知道，更轻松的开发理论与在截止日期临近而工具无法实现的现实之间存在很大的差距完全不按照他们的指示去做。

[有关低代码开发的全部内容： 为什么开发人员不应该只解雇低代码平台 。 | 25个用于快速构建移动应用程序的简单工具 。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

低代码解决方案占有一席之地。 程序员欣赏他们能够以更少的时间和更少的精力交付可以工作的东西的能力。 他们知道，低代码工具可以产生一种不错的机制，可以搜索，排序和处理表格数据。 他们很高兴在适当的时候使用它们。

但是开发人员也担心会陷入困境，无法适应所有边缘条件，在工具无法自动执行正确操作的所有地方工作。 他们需要处理故障，摆弄未记录的功能，并弄清楚如何满足做事的要求。

开发人员被困在销售承诺的承诺和现实中，即与编写自己的堆栈（换句话说，是高代码方法）相比，使用低代码工具通常更慢，更麻烦。

这是程序员对低代码工具感到沮丧的9个原因，这些工具本可以节省很多时间。

低代码挫折＃1：维护可能很困难

处理低代码解决方案中最棘手的部分通常需要几年的时间。 旧系统已部署并顺利运行，但是每个人都要求进行修复和改进。 很多时候，这些额外功能就位于旧的低代码解决方案的体系结构之外，并且没有简单的方法来添加它们。 如果我们有源代码，我们也许可以深入研究并重建一些勇气，但我们没有。 如果原始设计师知道需要该功能，那么他们将做出不同的决定。 他们可能从一个完全不同的框架开始。 但是他们没有，现在我们被锁定了。

低代码挫折＃2：每个人都得到相同的东西

每个在连锁餐厅吃饭的人都知道无聊和缺乏惊喜。 业务模型依赖于在标准菜单和标准设计上节省资金，同时还提供一致的体验，但这并没有使它变得更有趣。

低代码工具提供了相同的千篇一律的感觉。 一个只有一点经验的优秀开发人员通常只需单击几下即可确定基础工具。 无论有多少配置选项，启动屏幕或自定义CSS外观，底层机制都会显示出来。 对于某些想要完全相同的用户而言，这可能会令人感到安慰，但同时也消除了许多惊喜和新颖性。

低码失败率＃3：一种尺寸无法满足

产品制造商喜欢“一刀切”的产品，因为管道非常简单。 顾客们？ 他们经常讨厌他们，并抱怨“一种尺寸不适合任何尺寸”。

低代码产品易于以相同方式使用。 变更，自定义或编码的内容不多，因此您一无所获。 他们尽其所能，仅此而已。 没有人最终开心。

低代码挫败感＃4：有时候编码比配置容易

通过最小化配置软件的工作，开发人员一直在犯战略错误。 可能是因为Bean计数器会计算指标，例如每行代码的成本。 也许是因为诉讼总是将创建新代码的成本与购买现成产品的价格进行比较。 无论如何，编码人员都喜欢假装为平台或工具配置文件中的参数更改没什么大不了的。

低代码选项往往会推销相同的情况：在指定算法，连接数据库并填写参数时，您无需进行编码。 这只是配置上的不足，每个人都知道配置很容易，只需大声地从智能手机中进行即可。 但是现实情况是，这些击键可能需要几天或几周的时间才能摆弄，直到它们实际执行了应该执行的操作为止。 供应商不希望我们认为它“有效”，即使它花费的时间比实际完成代码的辛苦“工作”还要长。

低代码挫败感＃5：低代码屡见不鲜

多年来，开发人员已经创建了精心制作的调试工具，可以轻松地在任意位置停止软件，并深入了解所有数据结构和算法状态，以了解发生了什么。 低代码工具有意向我们隐藏了所有这些内容，并认为它们在帮我们一个忙。

如果低码部分能够按我们预期的那样工作，那么一切都是阳光和独角兽。 但通常情况是，有些事情会出现问题，我们陷入困境，无法找出黑匣子内部发生的一切。 我们在没有工具的情况下视而不见，正在寻找任何方式来了解正在发生的事情。

低代码挫败感＃6：有时您只需要插入一个函数即可清理数据

任何编写过软件的人都知道，一半的工作正在编写多余的粘合代码，这些粘合代码可以在过滤问题的同时保持数据的畅通。 有时日期采用ISO 8601格式，有时有时会采用某些本地偏好。 有时，数字应为整数，而应为字符串，反之亦然。

低代码产品通过提供过滤器或开关来尝试承担一些工作，而这些通常就足够了。 但是，如果不是，那您就不走运了。 低代码产品陷入困境。 有些人尝试过让您在任意位置插入任意代码块，但有人找到了滥用它们的方法，并引入了巨大的安全漏洞。 例如， Drupal删除了将PHP包含在适当位置的选项 ，以消除潜在的安全漏洞并提高缓存性能。

低代码挫败感＃7：低代码通常效率低下

低代码工具的承诺是，他们知道您的需求，然后神奇地交付它。 但是，这种阅读方法的成本是一堆厚厚的代码，用于处理可能会发生的所有奇怪配置和奇怪曲线。

如果您编写了代码，则可能知道您的公司仅将其数据存储在CSV文件中。 但是，位于低代码总部的团队需要为所有突发事件做好计划，这意味着必须使用JSON，YAML和XML（版本1.0和1.1）。 那里有数十种格式，低代码销售团队希望确保他们的工具可以处理所有格式。 这与特征矩阵中的复选标记有关。

其结果是令人印象深刻的工程，就像防弹的无畏之战一样令人印象深刻，并且它具有第一次世界大战战列舰的所有优雅和敏捷性。

结果是一切都变慢了，效率也降低了。 如果截止日期不太紧，并且数据集也不太大，则可以通过在堆栈上投入更多的计算能力来隐藏它。 但是最终，要格外小心的代码的账单就要到期了。

低代码挫败感＃8：需要经验

许多顶级的开放源代码平台都是用学校教授的流行语言构建的。 庞大的人才生态系统可以分解并重建以Java，JavaScript，Python或PHP等主要语言构建的堆栈。

通常不教授低代码，因为嗯，您不应该在其中包含任何指令。 奉献者将指出，这些工具通常是用通用语言编写的，但这对开发人员而言并不是真正的挑战。 挑战在于捆绑到低代码框架中的额外结构。 这是您要付出的代价，也是团队要修改或扩展平台时需要花时间学习的东西。

低码失败率＃9：您被锁定

有时，启动这些低代码平台之一的感觉就像是加入了暴民。 加入很容易，却很难离开。 减少工作量并站在巨人的肩膀上的代价是，您会迷恋巨人。 如果巨人移动，您将与它们一起移动。 如果巨人停止移动或崩溃，那么您就会遇到麻烦。

From: https://www.infoworld.com/article/3438819/why-developers-hate-low-code.html