低代碼繼續受到大量關注和爭論。許多軟件開發人員仍然想知道使用低代碼是否會使應用程序開發過程更好，或者它是否會干擾開發過程并導致劣質應用程序。其他人則擔心低代碼的安全隱患。

當然，如果使用低代碼的必然結果是更高的應用程序復雜性，那么低代碼可能會導致安全問題的難度增加。但真的是這樣嗎？我最近寫了很多關于應用程序復雜性的文章，還有很多關于低代碼的文章。但是應用程序復雜性與使用低代碼之間的相關性是一個有趣的觀點。

復雜性與方法無關

需要明確的是，低代碼的必然結果不一定是復雜性。就像傳統的應用程序開發一樣，復雜性可以而且經常會進入產品代碼庫的生命周期。雖然不是不可避免的，但它很常見。無論應用程序是如何構建的，你都可以采取許多步驟來降低應用程序的復雜性，從而提高性能、可擴展性、可用性和創新速度。

是的，與所有應用程序一樣，低代碼應用程序可能會變得復雜，并且需要使用簡化技術來降低復雜性。但這些問題與使用低代碼無關。它們在常規產品開發過程中同樣重要。

未知并不復雜

低代碼確實增加了應用程序中不是由開發團隊直接編寫的代碼量。還有更多代碼是由低代碼平臺自動生成的，或者包含在你的應用程序運行所需的庫中，但不是你的開發人員的產品。因此，當你使用低代碼技術時，你的應用程序中通常會有更多“未知”代碼。

但未知與復雜性不同。未知代碼（由其他人提供并添加到你的應用程序的代碼）本身不會增加應用程序的復雜性。

事實上，情況可能正好相反。

低代碼降低復雜性

使用低代碼開發技術可以減少過度復雜性滲入應用程序的可能性。通過簡化應用程序開發人員的認知負荷和時間壓力，低代碼平臺允許開發人員專注于更大的圖景、應用程序業務邏輯，而較少關注細節。

細枝末節會發生什么？它們由低代碼環境處理。此外，低代碼環境將使用標準化的、經過驗證的技術來完成這些低級任務。自動生成的代碼和庫代碼早在你的應用程序團隊使用它之前就已開發、測試和改進。你使用低代碼構建應用程序的次數越多，在你的應用程序中使用的這種預先測試的標準化代碼的數量就越多。使用低代碼工具來構建你的應用程序會導致更多地使用標準化編碼技術、行業最佳實踐，并最終實現更多的軟件重用。

但是復雜性呢？增加標準化編碼的使用和利用軟件重用是用于降低應用程序復雜性的常用策略。標準化編碼減少了理解應用程序如何工作所涉及的認知負擔，而代碼重用往往會減少復雜應用程序中可能出現故障的移動部件的數量。因此，使用低代碼工具創建的應用程序將比使用傳統編程技術開發的功能等效應用程序更簡單。

標準化和重用如何影響復雜性？

當我們考慮應用程序的復雜性時，我們通常會考慮應用程序的兩個不同方面：組成應用程序的組件的大小和數量，以及應用程序軟件的更改率。

增加對可重用代碼的使用會減少應用程序中組件的大小和數量，而增加對標準化編碼技術的使用往往會降低變化率——至少對于應用標準化編碼的模塊或組件而言。

任何給定應用程序的實際情況都會更加復雜，但基本原理仍然適用。增加標準化編碼技術的使用和增加可重用軟件組件的使用往往會降低最終應用程序的復雜性。

這并不新鮮

這種分析對于低代碼來說并不是新的或獨特的。幾十年來，我們一直使用軟件抽象來“隱藏”開發人員的代碼復雜性。每當我們使用高級語言（例如 C、Java、Ruby 或 Go）時，我們都會抽象出為執行所需操作而創建和執行的實際代碼。我們將開發重點放在“更高級別的構造”上，允許編譯器或解釋器處理創建和運行機器代碼的細節。

它并不止于編譯器。當我們使用更高級別的軟件包、環境和框架時，我們也會抽象出復雜性，以便我們可以專注于更高級別的功能。因此，使用 Ruby on Rails、Spring、Hibernate、Gin、jQuery、Bootstrap 甚至 HTML/CSS，我們正在抽象出復雜性，以便在更高層次上工作。結果是更強大的應用程序和更高的可靠性，更少的開發工作和更低的支持成本。這與當今低代碼社區中討論的論點沒有什么不同。

軟件開發的世界是一個復雜的世界，每天都有新的挑戰出現。軟件開發人員經常使用工具、資源、環境和技術來簡化軟件開發過程。最近，低代碼技術得到了改進，低代碼平臺已成為改進軟件開發過程的有用工具，而不會增加應用程序的過度復雜性。

原文標題：??Does low code make applications overly complex????