低代码继续受到大量关注和争论。许多软件开发人员仍然想知道使用低代码是否会使应用程序开发过程更好，或者它是否会干扰开发过程并导致劣质应用程序。其他人则担心低代码的安全隐患。
当然，如果使用低代码的必然结果是更高的应用程序复杂性，那么低代码可能会导致安全问题的难度增加。但真的是这样吗？我最近写了很多关于应用程序复杂性的文章，还有很多关于低代码的文章。但是应用程序复杂性与使用低代码之间的相关性是一个有趣的观点。
复杂性与方法无关
需要明确的是，低代码的必然结果不一定是复杂性。就像传统的应用程序开发一样，复杂性可以而且经常会进入产品代码库的生命周期。虽然不是不可避免的，但它很常见。无论应用程序是如何构建的，你都可以采取许多步骤来降低应用程序的复杂性，从而提高性能、可扩展性、可用性和创新速度。
是的，与所有应用程序一样，低代码应用程序可能会变得复杂，并且需要使用简化技术来降低复杂性。但这些问题与使用低代码无关。它们在常规产品开发过程中同样重要。
未知并不复杂
低代码确实增加了应用程序中不是由开发团队直接编写的代码量。还有更多代码是由低代码平台自动生成的，或者包含在你的应用程序运行所需的库中，但不是你的开发人员的产品。因此，当你使用低代码技术时，你的应用程序中通常会有更多“未知”代码。
但未知与复杂性不同。未知代码（由其他人提供并添加到你的应用程序的代码）本身不会增加应用程序的复杂性。
事实上，情况可能正好相反。
低代码降低复杂性
使用低代码开发技术可以减少过度复杂性渗入应用程序的可能性。通过简化应用程序开发人员的认知负荷和时间压力，低代码平台允许开发人员专注于更大的图景、应用程序业务逻辑，而较少关注细节。
细枝末节会发生什么？它们由低代码环境处理。此外，低代码环境将使用标准化的、经过验证的技术来完成这些低级任务。自动生成的代码和库代码早在你的应用程序团队使用它之前就已开发、测试和改进。你使用低代码构建应用程序的次数越多，在你的应用程序中使用的这种预先测试的标准化代码的数量就越多。使用低代码工具来构建你的应用程序会导致更多地使用标准化编码技术、行业最佳实践，并最终实现更多的软件重用。
但是复杂性呢？增加标准化编码的使用和利用软件重用是用于降低应用程序复杂性的常用策略。标准化编码减少了理解应用程序如何工作所涉及的认知负担，而代码重用往往会减少复杂应用程序中可能出现故障的移动部件的数量。因此，使用低代码工具创建的应用程序将比使用传统编程技术开发的功能等效应用程序更简单。
标准化和重用如何影响复杂性？
当我们考虑应用程序的复杂性时，我们通常会考虑应用程序的两个不同方面：组成应用程序的组件的大小和数量，以及应用程序软件的更改率。
增加对可重用代码的使用会减少应用程序中组件的大小和数量，而增加对标准化编码技术的使用往往会降低变化率——至少对于应用标准化编码的模块或组件而言。
任何给定应用程序的实际情况都会更加复杂，但基本原理仍然适用。增加标准化编码技术的使用和增加可重用软件组件的使用往往会降低最终应用程序的复杂性。
这并不新鲜
这种分析对于低代码来说并不是新的或独特的。几十年来，我们一直使用软件抽象来“隐藏”开发人员的代码复杂性。每当我们使用高级语言（例如 C、Java、Ruby 或 Go）时，我们都会抽象出为执行所需操作而创建和执行的实际代码。我们将开发重点放在“更高级别的构造”上，允许编译器或解释器处理创建和运行机器代码的细节。
它并不止于编译器。当我们使用更高级别的软件包、环境和框架时，我们也会抽象出复杂性，以便我们可以专注于更高级别的功能。因此，使用 Ruby on Rails、Spring、Hibernate、Gin、jQuery、Bootstrap 甚至 HTML/CSS，我们正在抽象出复杂性，以便在更高层次上工作。结果是更强大的应用程序和更高的可靠性，更少的开发工作和更低的支持成本。这与当今低代码社区中讨论的论点没有什么不同。
软件开发的世界是一个复杂的世界，每天都有新的挑战出现。软件开发人员经常使用工具、资源、环境和技术来简化软件开发过程。最近，低代码技术得到了改进，低代码平台已成为改进软件开发过程的有用工具，而不会增加应用程序的过度复杂性。
