低代碼開發定義
低代碼開發，是一種開發模式，通過圖形化用戶界面來配置和創建應用軟件，而不是用傳統模式那樣主要依靠手寫代碼。對應的，提供給開發者的這類低代碼開發功能實現的軟件，稱為低代碼開發平台(LCDP)。低代碼開發模式的開發者，通常不需要具備非常專業的編碼技能，或者不需要某一專門領域的編碼技能，而是可以通過平台的功能和 約束來實現專業代碼的產出。
從定義中我們可以看到，低代碼開發的工作方式主要依賴操作圖形化的用戶界面，包括拖拽控件，以及修改其中可被編輯區域的配置。這種可視化的開發方式，可以追溯到更早的 Dreamwaver 時期。而隨着前端項目的日趨復雜，這種方式已不再適應現代項目的需求，於是漸漸被更專業的工程化的開發模式所取代。
開發途徑
但是，快速生成項目代碼的訴求從未消失。人們也慢慢找到了實現這個目的的兩種路徑：
一種是在高度定制化的場景中，基於經驗總結，找到那些相對固定的產品形態，例如公司介紹、產品列表、活動頁面等，開放少量的編輯入口，讓非專業開發者也能使用。下一課介紹的無代碼開發，主要就是面向這樣的場景需求。
另一類則相反，順着早期可視化開發的思路，嘗試以組件化和數據綁定為基礎，通過抽象語法或 IDE 來實現自由度更高、交互復雜度上限更高的頁面搭建流程。這種項目開發方式通常需要一定的開發經驗與編碼能力，只是和普通編碼開發方式相比，更多通過操作可視化工具的方式來達到整體效率的提升，因此被稱為低代碼開發。
在實際場景中，尤其是商用的低代碼平台產品，往往提供的是上面兩種開發方式的結合。
基於編寫 JSON 的低代碼開發
當我們去審視一個項目前端部分的最終呈現時，可以發現：
一個項目的前端部分本質上呈現的是通過路由連接的不同頁面。而前端開發的目標就是最終輸出頁面的展示與交互功能。
如果學過瀏覽器基本原理，你會知道：每一個頁面的內容在瀏覽器中，最終都歸結為DOM 語法樹（DOM Tree）+ 樣式（Style）+ 動態交互邏輯（Dynamic Logic）。
在組件化開發的今天，一個規范定義的組件包含了特定功能的 DOM 子樹和樣式風格。因此頁面的內容又可以定義為：組件樹（Component Tree）+ 動態交互邏輯（Dynamic Logic）。
而基於 JSON-Schema 的低代碼開發的切入邏輯是：
在特定場景下，例如開發中后台增刪改查頁面時，大部分前端手動編寫的代碼是模式化的。
頁面組件結構模板和相應數據模型的代碼組織，可以替換為更高效的 JSON 語法樹描述。
通過制定用於編寫的JSON 語法圖式（JSON Schema），以及封裝能夠渲染對應 JSON 語法樹的運行時工具集，就可以提升開發效率，降低開發技術要求。
編寫 JSON 開發的高效性
編寫 JSON 語法樹開發的高效性體現在：
由於只用編寫 JSON ，而隱藏了前端開發所需的大量技術細節（構建、框架等），因此降低了對開發人員的編碼要求，即使是非專業的開發人員，也可以根據示例和文檔完成相應頁面的開發。
由於只用編寫 JSON ，大量的輔助代碼集成在工具內部，整體上減少了需要生成的代碼量。
可以對中后台系統所使用的常用業務組件進行抽象，然后以示例頁面或示例組件的方式，供用戶選擇。
編寫 JSON 開發的缺點
但另一方面，這種方式也存在着一些不足：
輸入效率：單從組件結構的描述而言，使用 JSON 描述的代碼量要多於同等結構的 JSX 語法（參見示例代碼 07_low_code），對於有經驗的前端開發者而言，通常無法第一時間感受到效率的提升。
學習記憶成本：由於引入了新的 JSON 語法圖式，無論對於前端開發者、后端開發者還是非專業的人員來說，上手的學習成本都不可避免。此外，不同組件存在不同屬性，要在實際編寫過程中靈活運用，對記憶量也是一個考驗。而反復查閱文檔又會造成效率的下降（對於這個問題，有個優化方案是利用 IDE Snippets 的選項功能生成對應的語法提示）。
復用性和可維護性：對於多頁面存在可復用業務組件的情況，在 JSON 編寫的模式下往往需要手動復制到各頁面 JSON 中，犧牲了復用組件的可維護性。此外，對於功能復雜的頁面，對應的 JSON 長度也會讓維護體驗變得不太美好。
問題排查難度增加：這個問題涉及面向人群，如果是非專業的人員從事 JSON 的開發過程，當遇到問題時，在如何排查上可能造成阻礙，因此通常需要配備額外的專業人員來提供技術支持。
基於可視化操作平台的低代碼開發
可視化的低代碼操作平台把編寫 JSON 的過程變成了拖拽組件和調試屬性配置，如下圖所示，這樣的交互方式對用戶來說更直觀友好，開發效率也會更高。
可視化操作平台的基本使用方式
絕大部分的可視化操作平台都將界面布局分為三個區域：左側的組件選擇區，中部的預覽交互區以及右側的屬性編輯區。這三個區域的排布所對應的，也是用戶生成頁面的操作流程：
首先，在左側面板中選擇組件。
然后，拖入中間預覽區域，並放置到合適的容器塊內。
最后，調試右側面板中新移入的組件屬性。
調試完成后，進行下一個組件的循環操作直到整個頁面搭建完成。
可視化操作平台的生產效率影響因素
通常來說，在組件數量不變的情況下，編寫 JSON 的產出效率更大程度上取決於編寫頁面的開發者的技術熟練度。但在使用可視化操作平台時卻並非如此：我們會看到，平台本身的很多方面也會直接影響使用者的產出：
首先，平台的功能完備性直接決定了用戶產出的上限：開發者不可能在平台里使用組件區沒有顯示的組件，也不可能創建編輯區不存在的屬性。這就迫使平台開發者需要盡可能完整地陳列所有類型的組件，以及通過定義組件類型描述，來獲取所有可以被編輯的屬性和方法。包括用戶交互和數據對組件的影響，這些都需要平台以合適的使用方式提供給用戶。
其次，平台的邏輯自洽性決定了用戶產出的質量：在代碼的組織上，不同組件之間不可以任意組合，錯誤的組合可能導致顯示與功能的異常。如果平台只是簡單羅列所有組件，而對其中的規則不加以限制，就可能導致用戶在使用過程中出現意料外的產出結果。所以，平台開發者需要有一套完整的組件關聯關系表，並反映到交互呈現中。
最后，平台提供的交互易用性決定了用戶的產出效率：盡管大部分低代碼平台都提供了相似的區域操作邏輯，但真正影響用戶使用效率的往往是很多細節的控制。例如，與單純依靠光標選取組件相比，在側邊欄提供節點樹的方式可以更大程度減少誤選；與簡單陳列所有組件相比，合適的分類，以及當選擇特定組件時篩選出可添加的部分組件，更能減少用戶搜索的時間，同時減少可能的出錯；一些平台提供了操作棧回放的功能，能減少用戶誤操作后的修復成本，等等。
低代碼開發的產品
低代碼開發的產品有很多，其中既包括商用的產品，例如 Kony、OutSystems、Mendix、Appian、iVX（國內）等，也包括開源類的產品，例如阿里飛冰、百度 Amis、貝殼河圖、Vvvebjs、react-visual-editor 等。這里就不一一介紹了，感興趣的話，你可以進一步搜索了解。
總結
這篇介紹了低代碼開發的概念和它的基本應用場景，也了解了低代碼開發的兩種基本開發模式：基於編寫 JSON 的方式和基於可視化操作平台的方式。
前者對普通的項目開發流程做了抽象，將編寫不同功能模塊的代碼變為只編寫組件語法樹描述信息，這種方式在一定程度上降低了使用者的技術要求，提升了開發的效率，但是在一些方面仍然不甚理想。而平台化的開發模式相對而言解決了編寫 JSON 模式下的一些問題，但是要搭建一個功能完備、使用邏輯自洽和交互性良好的平台也並非易事。