开发人员不喜欢低代码和无代码的 8 件事

低代码和无代码 (LC/NC) 工具制造商正面临一场艰苦的战斗，试图说服人们，尤其是专业开发人员，使用甚至只是尝试他们的工具和平台。少数平台已经进入这个市场，但大多数软件开发无疑仍然是由编写代码的专业人员完成的。

从工具制造商的角度来看，缺乏兴趣似乎令人困惑。更快的开发、更低的成本、更少的错误、更容易的部署、托管的环境——为什么有人会拒绝这些乌托邦式的视觉工具制造商喜欢展示的东西？为什么这么多人宁愿继续与困难的语言、复杂的错误跟踪和晦涩的环境设置作斗争？

我一直在与开发人员交谈，阅读文章，并在讨论论坛上搜索这些问题的答案，并整理了一些提出的原因。

这对他们的事业没有帮助

学习低代码工具可能需要大量的时间和精力投入，但学习特定的 LC/NC 工具几乎没有专业价值。即使在软件开发公司很少使用 LC/NC 工具的情况下，下一个雇主也很可能不需要员工开发人员通过学习该工具获得的技能。

大多数开发工作都需要对广泛使用的语言和框架有深入的了解和经验，并且没有像 React、Angular、Python、Java 或 C# 这样广泛使用的低代码工具。

很少有开发工作需要了解 LC/NC 工具，而且开发人员知道 LC/NC 工具后找到更好工作或赚更多钱的可能性非常低。因此，开发人员最好花时间学习和完善就业市场上需求量很大的无数技能、框架和语言之一。

开发人员花了数年时间学习如何编写代码

近 70% 的开发者回复了2021 年 Stack Overflow 开发者调查声明他们拥有计算机科学或相关学科的学士学位或更高学位。这意味着大多数开发人员花费数年时间学习编程、学习各种语言、系统架构，以及普遍练习和完善编写代码的艺术。使用 LC/NC 工具通常意味着放弃他们来之不易的经验和投资所代表的优势。因此，大多数开发人员更愿意依靠他们已经辛苦获得的宝贵技能也就不足为奇了。

如果 LC/NC 工具确实兑现了它们的承诺，那么未来将不再需要编写代码来创建应用程序。编程将移动到更高的抽象级别，应用程序将从现有组件组装而不是编码。因此，程序员基本上威胁要通过使用和支持更多地使用 LC/NC 工具来使他们来之不易的技能变得多余。因此，LC/NC 工具不成功实际上符合他们的利益。

开发人员不太关心速度

当开发人员为软件公司工作时，他们通过交付具有特定特征的代码获得报酬。这些包括易于阅读、可测试、结构良好、可靠、高效、遵循标准等。维护中等复杂应用程序的开发人员会明白确保代码尽可能简单和易于理解的重要性。这些品质对于代码的可维护性至关重要。

代码通常由更高级的程序员审查，他们也关心这些品质并强调它们。与开发人员相比，他们可能对更快地完成工作更感兴趣，但他们知道代码错误、效率低下、编写晦涩难懂且难以扩展是难以维护的。

这个糟糕的代码会导致很多麻烦，并且会变得非常昂贵。虽然交付代码的速度是相关的，但代码的组织和编写方式通常优先于交付速度。

因此，向开发人员推销 LC/NC 工具的开发速度实际上可能不会产生预期的影响。

开发人员喜欢编码

人们是模糊的和情绪化的。他们有相互冲突的优先事项，经常不确定、不准确和撒谎。通常他们甚至不知道自己在做什么以及为什么要这样做。人们可能会很困惑。计算机要简单得多。计算机只是按照程序员给出的指令进行操作，如果这些指令不正确，程序就会失败。定义一组任务并看到它们立即准确地完成的精确度给了许多人一种安全感和快乐感。

编码中有许多开发人员真正喜欢的创意元素。编程是一个非常复杂的谜题，充满了脑筋急转弯，跨越了几十个模块、多层和数千行代码。单个 Web 应用程序可以很容易地包含五种或更多不同的语言一起工作（例如 HTML、JS、CSS、C#、SQL）。制作由联锁运动部件组成的复杂物体，并观察它们在微妙的循环中工作，因为它们发挥了内置逻辑的后果，这可能会令人着迷，并带来强烈的成就感。

软件存在的原因是为了让生活更轻松，我们从根本上构建软件来帮助人们做得更好。一旦你知道如何编写代码——用任何语言——你就可以构建任何你能想象到的东西。想象一些东西然后从无到有创造它是一种快乐，尤其是当它对他人有用并让他们快乐时。

开发人员不会选择技术堆栈

开发人员在项目中停留的时间越长，他们在扩展应用程序方面就越好，他们在发现和解决问题方面的效率就越高。当开发人员离职时，他们通常会随身携带有关应用程序复杂细节的深入了解。这种知识很难重新获得，当这些员工被替换时，他们支持的应用程序往往会进入不稳定阶段，有时甚至会陷入混乱。因此，尽管软件公司对稳定性很感兴趣，但软件开发人员通常只在一个雇主那里呆几年。

软件公司用来减轻知识损失的一种策略是使用在开发人员社区中广泛使用和众所周知的技术。使用众所周知的堆栈可以更容易地找到有技能的人来雇用。它还可以帮助这些人了解使用他们构建的应用程序的来龙去脉。开发人员可能是决定将哪些技术用于项目的影响者，但通常是高级工程师甚至管理层使用这些标准来决定堆栈。因此，向开发人员推销 LC/NC 工具可能会错失良机。

押注工具是有风险的

客户往往很难确定他们将来可能会在哪里申请。这是可以理解的，因为未来很难预测。因此，应用程序所有者需要适应不断变化的需求，以确保应用程序的商业成功。这通常意味着修改商业模式并改变支持这种模式的技术。经验丰富的开发人员知道这一点，并且喜欢构建能够适应未来不断变化的需求的开放系统。创建这种适应性强的系统的最佳方法是使用支持良好的语言和框架对其进行编码。

许多 LC/NC 工具都是新的、不成熟的，并且具有很大的技术限制。这些限制通常不会被宣传，而且通常也只是很少记录。软件公司真正找到这些限制的唯一方法是尝试一个工具并构建一个真正的应用程序。大多数限制只有在投入大量时间和精力后才会变得明显。软件开发既昂贵又冒险，而这些未知因素进一步增加了开发人员、软件公司及其客户的风险。

锁定交易

许多平台不允许将该平台中构建的应用程序导出为通用的、可编辑的格式。他们锁定应用程序，从而要么将开发人员绑定到平台，要么要求他们从头开始重建他们的应用程序。考虑到未来的需求是不确定的，而且 LC/NC 工具的局限性通常会一直隐藏到项目的后期，因此开发人员可能会非常警惕被锁定也就不足为奇了。

LC/NC过去曾多次失败

可视化开发工具并不新鲜。视觉发展的早期尝试已经在 50 年前进行。从那时起，大量好的和坏的可视化开发环境和平台来来去去，但它们都没有对应用程序的创建方式产生重大影响。

任何押注任何这些工具、投入时间和精力来学习它们并说服客户在其中任何一个上构建项目的人都输了。这段历史表明，我们今天遇到的任何工具都不太可能在十年后仍然存在。许多开发人员可能会仔细考虑这些事实，并认为 LC/NC 是一条死胡同。

怎么办？

那么，LC/NC 是失败的原因吗？在严肃的软件开发世界中是否没有 LC/NC 的位置？ LC/NC 工具制造商能否以某种方式克服这些障碍并激励更多开发人员使用 LC/NC 产品？

由于对 LC/NC 工具和宣传它们的营销传播缺乏信任，许多开发人员更喜欢代码。为了说服任何专业人士使用 LC/NC 平台，平台制造商要求开发人员信任他们。为了建立这种信任，工具制造商最好听取开发人员和软件公司提出的担忧，并在规划平台功能和与目标群体沟通时将其考虑在内。

诚实和真实地披露功能限制、发布克服限制的方法、拉平平台的学习曲线以及允许将应用程序导出为可编辑格式，尽管它们可能无法说服所有开发人员，但它们朝着正确的方向迈出了一步。