为什么开发人员对低代码好感度不高？

程序员们喜欢“低代码”工具的理念。 对他们来说，更少的代码意味着更少的工作和更快的项目、更高的满意度、更精简的预算甚至是更丰厚的奖金，试问谁不喜欢这些呢?

但是他们也都知道，在最后期限接近或者工具不合适时，理想和现实之间往往存在很大的反差。

程序员欣赏低代码以更少的时间和精力交付工作的能力。低代码工具理论上可以产生一种良性机制，可以搜索、排序和处理表格数据。当时机成熟的时候，他们也很乐意使用它们。

但是开发人员也担心低代码出现问题，在低代码出现问题时，他们就需要处理这些故障，并找出解决办法。

开发人在使用低代码工具比编写自己的堆栈(换句话说，使用高代码方法)更慢、更麻烦的现实之间两难。

下面是程序员对低代码工具好感度不高的9个原因。

原因一：维护可能很困难

处理低代码解决方案最棘手的部分通常是在运行几年之后才会出现。旧系统已经部署好并运行得很顺利，但是每个人都需要修复和改进。很多时候，这些额外的特性位于旧的、低代码解决方案的体系结构结构之外，并且没有合适的方法来添加它们。如果我们有源代码，我们也许能够深入研究并重建一些核心内容，但遗憾的是我们没有。如果最初的设计者知道需要这个特性，他们就会做出不一样的决定。但现实是我们依然被维护困难困住了。

原因二：千篇一律

就像去连锁餐厅吃饭一样，我们能轻易地知道菜单，也得不到什么惊喜。商业模式依赖于标准菜单和标准设计，从而节省成本，同时还提供完全一致的使用体验，这并不是一个好现象。

低代码工具就提供了千篇一律的感觉。一个稍有经验的优秀开发人员通常只需点击几下鼠标就可以识别底层工具。无论有多少配置选项、闪屏或定制的CSS皮肤，底层机制都会显示出来。对于一些想要一致性的用户来说，这可能是一种安慰，但它也屏蔽了许多惊喜和新奇感。

原因三:一刀切

产品制造商喜欢“一刀切”的产品，因为流水线要简单得多。客户则更需要定制化，而且他们特别讨厌流水线产品。

同样，低代码产品也很容易使用。只是没有那么多东西可可供更改、自定义或编写代码，所以您只能使用它们，这可能不符合一部分开发人员的心理。

原因四：:有时编码比配置更容易

开发人员一直在犯一个战略性错误，将配置软件的工作量最小化。也许是因为bean计数器计算每行代码成本的指标，也许是因为总是在比较创建新代码的成本和购买现成产品的价格。在任何情况下，编码人员都喜欢假装更改平台或工具的配置文件中的参数并不是什么大问题。

低代码选项往往会带来相同的结果:在指定算法、连接数据库和填充参数时，您并没有编码。每个人都知道这只是配置问题，但实际情况是，这些工作可能需要数天或数周才能完成，直到他们真正按照您的想法运行，但它需要比实际编写代码的“工作”更长的时间。

原因五:低代码意味着盲目运行

多年来，开发人员创建了精心设计的调试工具，可以很容易地在任意位置停止软件，并深入查看所有数据结构和算法状态，以了解到底发生了什么。低代码工具则会故意对我们隐藏所有这些，并且系统自动认为它们在正确运行。

如果低代码部分像我们预期的那样工作，那么一切都是顺利的。但通常情况下，有些事情会出错，我们则会陷入困境，无法弄清黑匣子里到底发生了什么。系统在没有监测仪器的情况下盲目运行，找不到任何方法来了解发生的事情。

原因六:有时您需要插入函数来清理数据

编写过软件的人都知道，一半的工作是编写额外的少量粘合代码，以便在过滤问题的同时保持数据的流动。有时日期是ISO 8601格式，有时它们是本地首选。有时数字是整数，当它们应该是字符串时，反之亦然。

低代码产品试图通过提供过滤器或开关来承担部分工作，这些通常就足够了。但如果不是这样，低代码产品就会陷入困境。有些人尝试过在某些地方插入任意代码块，但是这是一种误用代码的方法，还会产生巨大的安全漏洞。例如，Drupal删除了在某些地方包含PHP代码的选项，以关闭潜在的安全漏洞，并提高缓存性能。

原因七:低代码通常效率低下

低代码工具的承诺是，它们知道您需要什么，然后自动交付它。不过代价是一堆厚厚的代码，它处理所有可能出现问题的奇怪配置。

如果您编写了代码，您可能知道您的公司只将数据存储在CSV文件中。但是，回到低代码总部的团队需要为所有突发事件做好计划，这意味着要使用JSON、YAML和XML，这两个版本都是1.0和1.1。市面上有几十种格式，低代码销售团队希望确保他们的工具能够处理所有这些格式。

这项工作异常复杂而浩大。最终的结果就是一切都变慢了，效率也降低了。如果你的截止日期不是太紧，你的数据集也不是太大，那你可以通过增加堆栈的计算能力来隐藏这一点，但最终结果可能不会太好。

原因八：:需要经验

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

低代码通常不被教授，因为你不需要任何指令。这些工具通常是用通用语言编写的，但这对开发人员来说并不是真正的挑战，挑战在于捆绑到低代码框架中的额外结构。如果他们要修改或扩展平台，这些就是你的团队需要花时间学习的。

原因九：容易被困住

有时启动一个低代码平台， 加入很容易，但是很难离开。 站在巨人的肩膀上，你会尽可能地减少自己的工作量，但是这个巨人的变化会牵动的你的变化，如果它停止运行或者崩溃了，你也会陷入困境。也就是说，低代码业务流程只能随着组件改变，组件的功能和种类限制了开发。