低代码工具的使用从商业普通用户发展到专业程序员等更广泛地采用，一些低代码开发工具（如来自 Salesforce.com 和 Zoho 的工具）起源于为普通商业用户提供的工具；其他（Outsystems 和 Oracle）作为程序员的低代码开发工具。虽然它们可能看起来相似，但开发体验的差异在它们的采用中起着重要作用。
虽然低代码的潜在生产力提升是真实的并且赢得了很多关注，但基于他们多年来代码开发的最佳实践，专业程序员对他们的开发平台的期望高于业务用户。我们自己的开发团队已经经历过这种情况，因为他们采用了 Oracle 低代码平台来构建 Oracle 的 SaaS 应用程序集。根据我们的经验，我们希望分享一些技巧，以帮助您的开发团队为企业级应用程序采用低代码。在确定专业开发人员是否会顺利采用低代码工具时，请考虑这五个标准。
1. 低代码开发工具应该能直接访问代码
专业开发人员喜欢编码。查看代码有助于他们了解正在发生的事情并以熟悉的方式调试问题。然而，许多低代码工具就像一个黑匣子：你使用可视化开发工具，平台就会发挥它的魔力。使应用程序工作的代码是隐藏的。如果应用程序出现问题或平台不支持开发人员需要的功能，这种方法可能会导致问题。
使用提供直接访问代码的工具，专业开发人员会感到更加轻松。他们可以深入代码视图以了解究竟发生了什么，甚至可以增强平台的开箱即用功能。
检查您使用的平台是否使页面布局和可视化业务逻辑流的代码可访问和可修改。它是否让开发人员直接编码？它是否使用 JavaScript 和 HTML 等标准语言来进行这些修改？开发人员能否同时增强 UI 和业务逻辑层的功能？
2. 低代码开发工具应该支持团队开发和 CI/CD
寻找集成和支持功能的低代码工具，以支持开发人员越来越喜欢的基于敏捷方法的开发。其中包括用于协作团队开发的基于 git 的版本管理、自动化应用程序测试的能力、代码审计和创建 CI/CD 管道以更快地交付应用程序更改。例如，检查开发人员是否可以直接为以声明方式开发的业务逻辑生成自动化测试，以及它们如何适应测试驱动开发等实践。
3. 低代码开发工具应该支持模块化
在构建企业级应用程序时，低代码工具应支持多个开发人员同时在同一个应用程序上工作——在许多情况下，在同一个页面上——同时工作。
您的工具应该减少一位开发人员的更改可能与另一位开发人员的更改发生冲突的情况。这就是模块化发挥作用的地方。将一个大页面分解为可以独立开发的区域，然后组合成一个完整的解决方案有助于消除冲突。优先考虑微服务而不是单体架构。
如果减少此类冲突对您很重要，请寻找两个开发人员可以将功能添加到同一个 UI 页面的工具，同时每个开发人员在单独的文件中定义他/她的逻辑。一些工具提供页面片段，这些片段提供页面的可重用“部分”，可以独立开发然后组合成单个页面。
4. 低代码开发工具应该支持行业标准
大多数开发人员更喜欢市场广泛采用的技术，这样他们花在学习新工具和框架上的时间也会为他们的下一份工作服务。这也有助于他们在开发过程中，因为当他们遇到问题时更容易找到帮助。
因此，开发人员更喜欢使用流行语言和标准的低代码平台，而不是专有技术。如果您是 IT 经理，坚持使用非专有平台可以更轻松地找到和招募合格的开发人员。寻找使用 JavaScript/HTML/REST 等标准完成开发的平台。
这样，遇到不知道该怎么做的开发人员就可以在流行的 JavaScript 论坛中搜索答案。当他们需要访问外部系统时，他们只需要一个标准的 REST API。这也将让他们使用他们最喜欢的服务器端语言为他们的应用程序开发后端，并轻松地从该工具访问它。
5. 低代码开发工具支持可扩展性
一个好的低代码平台将包含大量功能，但您总是会遇到一些开箱即用的东西，例如独特的 UI 组件或需要实现的复杂逻辑。依赖行业标准的平台将使扩展它们变得更加容易。理想情况下，您将能够选择现有的组件和库，并轻松地将它们插入平台，在那里可以从低代码工具的声明性接口调用它们来创建 UI 和业务逻辑。