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