最近很火的低代碼到底是什麽？
原創
最后编辑：李晓琳 于 2021-08-30 16:25:59
1139次查看
本篇目錄
低代碼是一種軟件開發方法，它可以更快地交付應用程序，並且只需最少的手工編碼。低代碼平台是通過建模和圖形界面實現應用程序可視化開發的工具集合。低代碼使開發人員能夠跳過手工編碼，從而加快將應用程序投入生産的過程。
據Gartner稱，到2024年，低代碼將負責65%以上的應用程序開發活動，而爲應對COVID-19大流行提供數字化解決方案的壓力只會加速這一應用程序的采用。爲了理解這種開發方法的日益流行，理解低代碼的概念、低代碼平台的組成以及低代碼解決的問題是很重要的。
典型的低代碼開發平台有以下三種：
除了这些基础，没有两种低代码工具是完全相同的。有些非常有限，更类似于可视化数据库前端，如90年代的FoxPro。有些专注于小众业务需求，如case management。其他人则采用低代码术语来描述与实际应用程序开发无关的专用构建工具。无代码工具也在其中，尽管它们更多地迎合了商业用户和公民开发人员。
IT組織交付創新解決方案的壓力不斷放大。然而，以傳統開發方式的企業中，只有少數一流的企業具備滿足市場需求的財力和人力資源。大多數公司都被大量積壓的工作壓得喘不過氣來，難以招到足夠合格的員工，而且他們不斷被要求用更少的錢做更多的事。此外，如果說疫情教會了我們什麽的話，那就是適應新的和不可預測的需求的靈活性對企業的生存至關重要。
因爲低代碼大大降低了軟件開發的複雜性，任何規模的公司采用這種方法都有能力提高開發人員的生産力和速度。它提升了開發人員的價值，使敏捷團隊能夠利用他們對如何創建和維護高質量的web和移動應用程序的理解，同時通過嘗試新技術來展開翅膀。使用低代碼，UI/UX設計師可以進行前端開發，而後端開發人員可以嘗試構建消費者應用的原型。
簡單地說，低代碼是開發人員完成更多工作的一種方式。使用低代碼，他們可以花更多的時間創建和構建，而在重複性工作上花的時間更少。當然，學習最新流行的JavaScript框架或使用尖端的NoSQL數據存儲是很有趣的，但當自己花時間調試不熟悉的代碼時，競爭對手已經把MVP推向了客戶市場。
與其手工編寫另一個用戶管理系統，處理最新編程框架的特性，或者在一行應用程序代碼之前編寫10個測試，不如直接創建一些新的、有價值的東西。既然這些問題已經解決了，而且模式已經被很好地理解了，爲什麽還要從頭開始呢？
讓我們比較一下使用普通web框架創建的應用程序和使用低代碼創建的應用程序。
傳統軟件開發過程
无论是使用.NET MVC、Spring Boot还是Ruby on Rails，都要经历大致相同的步骤：
確定需求-規劃架構-選擇後端框架、庫、數據存儲等-選擇前端框架-選擇部署堆棧、設置CI、創建運維計劃-創建線框圖和原型-在所選擇的JavaScript框架中手工編寫Ul代碼-編寫測試
-定義模型並將它們連接到數據存儲-定義並編寫業務邏輯-創建視圖來提供或從前端接收JSON數據-應用于您的工作流和UI-使用發布的接口或支持的庫集成第三方API-重複直到測試通過-爲安全性、性能、質量和用戶接受度進行測試-部署、補丁、監視和更新，直到應用程序的壽命結束。
低代碼開發過程
確認需求-選擇任意第三方API-在可視化IDE中畫出軟件工作流、數據模型和用戶界面
連接API-如有必要，加入任何手動代碼到前端或自定義自動生成的SQL查詢-測試用戶接受度-部署生産，然後只需一次單擊就可以推送更新。
可以看出， 低代码以7步代替了16步，而在web和移动应用程序中手写代码的大部分时间几乎都是重复性工作。如非必要，为什么每次开始一个新项目时我们都要重蹈覆辙？低代码使我们能够使用经过战斗测试的基础知识直观地创建应用程序，而我们的重点是为世界提供有价值的东西。
據Gartner稱，到2024年，低代碼將負責65%以上的應用程序開發活動，而爲應對COVID-19大流行提供數字化解決方案的壓力只會加速這一應用程序的采用。爲了理解這種開發方法的日益流行，理解低代碼的概念、低代碼平台的組成以及低代碼解決的問題是很重要的。
什麽是低代碼平台
低代碼平台是一組工具，能夠可視化地開發和交付完整的應用程序。拖放界面是低代碼平台的核心。您不必編寫數千行複雜的代碼和語法，而是可以使用低代碼快速而直觀地構建具有現代用戶界面、集成、數據和邏輯的完整應用程序。應用程序的交付速度更快，只需最少的手工編碼。在本文中，您可以了解關于低代碼的更多好處。典型的低代碼開發平台有以下三種：
- 可視化IDE：用于可視化地定義應用程序的UI、工作流和數據模型的環境，並在必要時添加手寫代碼。
- 連接到各種後端或服務的連接器：自動處理數據結構、存儲和檢索。
- 軟件生命周期管理工具：用于在測試、登台和生産中構建、調試、部署和維護應用程序的自動化工具。
除了这些基础，没有两种低代码工具是完全相同的。有些非常有限，更类似于可视化数据库前端，如90年代的FoxPro。有些专注于小众业务需求，如case management。其他人则采用低代码术语来描述与实际应用程序开发无关的专用构建工具。无代码工具也在其中，尽管它们更多地迎合了商业用户和公民开发人员。
IT組織交付創新解決方案的壓力不斷放大。然而，以傳統開發方式的企業中，只有少數一流的企業具備滿足市場需求的財力和人力資源。大多數公司都被大量積壓的工作壓得喘不過氣來，難以招到足夠合格的員工，而且他們不斷被要求用更少的錢做更多的事。此外，如果說疫情教會了我們什麽的話，那就是適應新的和不可預測的需求的靈活性對企業的生存至關重要。
因爲低代碼大大降低了軟件開發的複雜性，任何規模的公司采用這種方法都有能力提高開發人員的生産力和速度。它提升了開發人員的價值，使敏捷團隊能夠利用他們對如何創建和維護高質量的web和移動應用程序的理解，同時通過嘗試新技術來展開翅膀。使用低代碼，UI/UX設計師可以進行前端開發，而後端開發人員可以嘗試構建消費者應用的原型。
簡單地說，低代碼是開發人員完成更多工作的一種方式。使用低代碼，他們可以花更多的時間創建和構建，而在重複性工作上花的時間更少。當然，學習最新流行的JavaScript框架或使用尖端的NoSQL數據存儲是很有趣的，但當自己花時間調試不熟悉的代碼時，競爭對手已經把MVP推向了客戶市場。
低代碼的工作環境是什麽樣的？
用低代碼構建軟件和用其他方法構建軟件是一樣的。除非你從頭開始用機器代碼編寫所有東西——彙編語言不算在內——否則你已經在別人的工作基礎上走捷徑了。與其手工編寫另一個用戶管理系統，處理最新編程框架的特性，或者在一行應用程序代碼之前編寫10個測試，不如直接創建一些新的、有價值的東西。既然這些問題已經解決了，而且模式已經被很好地理解了，爲什麽還要從頭開始呢？
讓我們比較一下使用普通web框架創建的應用程序和使用低代碼創建的應用程序。
傳統軟件開發過程
无论是使用.NET MVC、Spring Boot还是Ruby on Rails，都要经历大致相同的步骤：
確定需求-規劃架構-選擇後端框架、庫、數據存儲等-選擇前端框架-選擇部署堆棧、設置CI、創建運維計劃-創建線框圖和原型-在所選擇的JavaScript框架中手工編寫Ul代碼-編寫測試
-定義模型並將它們連接到數據存儲-定義並編寫業務邏輯-創建視圖來提供或從前端接收JSON數據-應用于您的工作流和UI-使用發布的接口或支持的庫集成第三方API-重複直到測試通過-爲安全性、性能、質量和用戶接受度進行測試-部署、補丁、監視和更新，直到應用程序的壽命結束。
低代碼開發過程
確認需求-選擇任意第三方API-在可視化IDE中畫出軟件工作流、數據模型和用戶界面
連接API-如有必要，加入任何手動代碼到前端或自定義自動生成的SQL查詢-測試用戶接受度-部署生産，然後只需一次單擊就可以推送更新。
可以看出， 低代码以7步代替了16步，而在web和移动应用程序中手写代码的大部分时间几乎都是重复性工作。如非必要，为什么每次开始一个新项目时我们都要重蹈覆辙？低代码使我们能够使用经过战斗测试的基础知识直观地创建应用程序，而我们的重点是为世界提供有价值的东西。
低代碼的局限性
盡管低代碼使快速創建工作應用程序成爲可能，但許多低代碼平台都需要權衡。當需要擴展規模、與現有系統集成，或在極端條件下（如黑色星期五的移動銀行應用程序）執行時，應用程序可能會在功能和非功能需求的重壓下屈服。如果用低代碼構建的應用程序需要更新，或者底層技術需要更改，那可能會是災難。
禅道項目
