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