开发人员不喜欢低代码和无代码的八个原因试用他们的工具和平台。少数平台已经进入这个市场，但大多数软件开发无疑仍然是由编写代码的专业人员完成的。从工具制造商的角度来看，缺乏兴趣似乎令人费解。更快的开发、更低的成本、更少的错误、更容易的部署、托管环境——为什么会有人拒绝这些乌托邦式视觉工具制造商喜欢炫耀的东西？为什么这么多人喜欢继续使用难懂的语言、复杂的错误跟踪和晦涩的环境设置？我一直在与开发人员交谈、阅读文章并在论坛中搜索这些问题的答案，并将提出的一些原因汇总在一起。这对他们的职业生涯没有帮助学习低代码工具可能需要花费大量时间和精力，但学习特定的LC/NC工具几乎没有专业价值。即使在软件开发公司很少使用LC/NC工具的情况下，下一位雇主也很可能不需要员工开发人员通过学习该工具获得的技能。大多数开发工作需要对广泛使用的语言和框架有深入的了解和经验，并且没有像React、Angular、Python、Java或C#这样广泛使用的低代码工具。很少有开发工作需要LC/NC工具的知识，并且开发人员找到更好的工作或了解LC/NC工具赚更多钱的机会非常低。因此，开发人员最好花时间学习和完善就业市场上需求量很大的无数技能、框架和语言中的一种。开发人员花了数年时间学习如何编码。在2021年StackOverflow开发人员调查中，近70%的开发人员声称拥有计算机科学或相关学科的学士学位或更高学位。这意味着大多数开发人员花费数年时间学习编程，学习各种语言、系统架构，并普遍练习和完善编写代码的艺术。使用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平台，平台制造商要求开发人员信任他们。为了建立这种信任，工具制造商最好倾听开发人员和软件公司提出的担忧，并在规划平台功能和与目标群体沟通时将其考虑在内。诚实如实地披露功能限制、发布克服这些限制的方法、拉平平台的学习曲线以及允许将应用程序导出为可编辑格式可能无法说服所有开发人员，但它们是朝着正确方向迈出的一步。
