放屁，現(xiàn)在那個程序員不在使用低代碼工具，你真的以為低代碼這個概念是最近才有的嗎？你懂個屁，低代碼一直都是高效的生產(chǎn)力工具；

這是我看到標題為 《“行業(yè)毒瘤”低代碼》這篇文章的第一反應(yīng)；

好了，平復(fù)一下激動的心，在開始之前，考慮到有的小伙伴可能還不太了解低代碼開發(fā)，咱們先介紹一下 “低代碼開發(fā)” 這個概念到底是什么；

低代碼的概念

低代碼開發(fā)（Low-Code Development，LCD），這個概念是在2011年被正式提出的，開發(fā)者主要通過圖形化用戶界面和配置來創(chuàng)建應(yīng)用軟件，而不是像傳統(tǒng)模式那樣主要依靠手寫代碼。對應(yīng)的，提供給開發(fā)者的這類低代碼開發(fā)功能實現(xiàn)的軟件，稱為低代碼開發(fā)平臺（Low-Code Development Platform， LCDP）。低代碼開發(fā)模式的開發(fā)者，通常不需要具備非常專業(yè)的編碼技能，或者不需要某一專門領(lǐng)域的編碼技能，而是可以通過平臺的功能和約束來實現(xiàn)專業(yè)代碼的產(chǎn)出。

從定義中我們可以看到，低代碼開發(fā)的工作方式主要依賴操作圖形化的用戶界面，包括拖拽控件，以及修改其中可被編輯區(qū)域的配置。這種可視化的開發(fā)方式，可以追溯到更早的 Dreamwaver 時期。而隨著前端項目的日趨復(fù)雜，這種方式已不再適應(yīng)現(xiàn)代項目的需求，于是漸漸被更專業(yè)的工程化的開發(fā)模式所取代。

但是，快速生成項目代碼的訴求從未消失。人們也慢慢找到了實現(xiàn)這個目的的兩種路徑：

一種是在高度定制化的場景中，基于經(jīng)驗總結(jié)，找到那些相對固定的產(chǎn)品形態(tài)，例如公司介紹、產(chǎn)品列表、活動頁面等，開放少量的編輯入口，讓非專業(yè)開發(fā)者也能使用，這其實就是無代碼方式了。

另一類則相反，順著早期可視化開發(fā)的思路，嘗試以組件化和數(shù)據(jù)綁定為基礎(chǔ)，通過抽象語法或 IDE 來實現(xiàn)自由度更高、交互復(fù)雜度上限更高的頁面搭建流程。這種項目開發(fā)方式通常需要一定的開發(fā)經(jīng)驗與編碼能力，只是和普通編碼開發(fā)方式相比，更多通過操作可視化工具的方式來達到整體效率的提升，因此被稱為低代碼開發(fā)。

在實際場景中，尤其是商用的低代碼平臺產(chǎn)品，往往提供的是上面兩種開發(fā)方式的結(jié)合。

低代碼開發(fā)的典型應(yīng)用場景

低代碼開發(fā)的一類典型應(yīng)用場景是在 PC 端中后臺系統(tǒng)的開發(fā)流程中，原因如下：

1：盡管中后臺系統(tǒng)的具體頁面布局并不固定，但整體 UI 風(fēng)格較統(tǒng)一，可以基于統(tǒng)一的 UI 組件庫來實現(xiàn)搭建，通過組件拖拽組合即可靈活組織成不同形態(tài)功能的頁面，因此適用于低代碼類型的開發(fā)模式。

2：中后臺系統(tǒng)涉及數(shù)據(jù)的增刪改查，需要有一定的編碼調(diào)試能力，無法直接通過 UI 交互完成，因此不適用無代碼開發(fā)模式。

以中后臺系統(tǒng)的開發(fā)為目標，低代碼開發(fā)的方式還可以細分為以下兩種：基于編寫 JSON 的開發(fā)方式，和基于可視化操作平臺的開發(fā)方式，下面我們來依次介紹一下。

基于編寫 JSON 的低代碼開發(fā)

當我們?nèi)徱曇粋€項目前端部分的最終呈現(xiàn)時，可以發(fā)現(xiàn)：

1：一個項目的前端部分本質(zhì)上呈現(xiàn)的是通過路由連接的不同頁面。而前端開發(fā)的目標就是最終輸出頁面的展示與交互功能。

2：如果學(xué)過瀏覽器基本原理，你會知道：每一個頁面的內(nèi)容在瀏覽器中，最終都歸結(jié)為 DOM 語法樹（DOM Tree） 樣式（Style） 動態(tài)交互邏輯（Dynamic Logic）。

3：在組件化開發(fā)的今天，一個規(guī)范定義的組件包含了特定功能的 DOM 子樹和樣式風(fēng)格。因此頁面的內(nèi)容又可以定義為：組件樹（Component Tree） 動態(tài)交互邏輯（Dynamic Logic）。

而基于 JSON-Schema 的低代碼開發(fā)的切入邏輯是：

在特定場景下，例如開發(fā)中后臺增刪改查頁面時，大部分前端手動編寫的代碼是模式化的。

頁面組件結(jié)構(gòu)模板和相應(yīng)數(shù)據(jù)模型的代碼組織，可以替換為更高效的 JSON 語法樹描述。

通過制定用于編寫的 JSON 語法圖式（JSON Schema），以及封裝能夠渲染對應(yīng) JSON 語法樹的運行時工具集，就可以提升開發(fā)效率，降低開發(fā)技術(shù)要求。

下圖中的代碼就是組件語法樹示例，我們通過編寫一個簡單的 JSON 語法樹以及對應(yīng)的編譯器，來展示低代碼開發(fā)的模式。

編寫 JSON 開發(fā)的缺點

但另一方面，這種方式也存在著一些不足：

輸入效率：單從組件結(jié)構(gòu)的描述而言，使用 JSON 描述的代碼量要多于同等結(jié)構(gòu)的 JSX 語法，對于有經(jīng)驗的前端開發(fā)者而言，通常無法第一時間感受到效率的提升。

學(xué)習(xí)記憶成本：由于引入了新的 JSON 語法圖式，無論對于前端開發(fā)者、后端開發(fā)者還是非專業(yè)的人員來說，上手的學(xué)習(xí)成本都不可避免。此外，不同組件存在不同屬性，要在實際編寫過程中靈活運用，對記憶量也是一個考驗。而反復(fù)查閱文檔又會造成效率的下降（對于這個問題，有個優(yōu)化方案是利用 IDE Snippets 的選項功能生成對應(yīng)的語法提示）。

復(fù)用性和可維護性：對于多頁面存在可復(fù)用業(yè)務(wù)組件的情況，在 JSON 編寫的模式下往往需要手動復(fù)制到各頁面 JSON 中，犧牲了復(fù)用組件的可維護性。此外，對于功能復(fù)雜的頁面，對應(yīng)的 JSON 長度也會讓維護體驗變得不太美好。

問題排查難度增加：這個問題涉及面向人群，如果是非專業(yè)的人員從事 JSON 的開發(fā)過程，當遇到問題時，在如何排查上可能造成阻礙，因此通常需要配備額外的專業(yè)人員來提供技術(shù)支持。

針對編寫 JSON 過程中的輸入效率、記憶成本和可維護性等問題，許多低代碼工具進一步提供了可視化操作平臺的工作方式。下面再讓我們來了解下，這種方式是怎么解決上述問題的。

可視化操作平臺的低代碼開發(fā)

可視化的低代碼操作平臺把編寫 JSON 的過程變成了拖拽組件和調(diào)試屬性配置，如下圖所示，這樣的交互方式對用戶來說更直觀友好，開發(fā)效率也會更高。

絕大部分的可視化操作平臺都將界面布局分為三個區(qū)域：左側(cè)的組件選擇區(qū)，中部的預(yù)覽交互區(qū)以及右側(cè)的屬性編輯區(qū)。這三個區(qū)域的排布所對應(yīng)的，也是用戶生成頁面的操作流程：

首先，在左側(cè)面板中選擇組件。

然后，拖入中間預(yù)覽區(qū)域，并放置到合適的容器塊內(nèi)。

最后，調(diào)試右側(cè)面板中新移入的組件屬性。

調(diào)試完成后，進行下一個組件的循環(huán)操作直到整個頁面搭建完成。

低代碼開發(fā)的產(chǎn)品有很多，其中既包括商用的產(chǎn)品，例如 Kony、OutSystems、Mendix、Appian、iVX（國內(nèi)）等，也包括開源類的產(chǎn)品，例如阿里飛冰、百度 Amis、貝殼河圖、Vvvebjs、react-visual-editor 等。這里就不一一介紹了，感興趣的話，你可以進一步搜索了解。

最后，低代碼真的不是行業(yè)毒瘤，這些年也一直都在不斷演進，很多人擔(dān)心低代碼會讓程序員丟掉飯碗，從而抨擊它，我嚴重懷疑這樣的人只能搞外包做企業(yè)官網(wǎng)，因為低代碼確實讓你不能行騙而丟了飯碗，再者說，后端運維都有 Serverless 了，為什么前端不能有低代碼，不去提升技術(shù)能力，杞人憂天的胡謅八扯，說白了，程序員這個行業(yè)，本身就是一個技術(shù)工種，就像早年間木匠鐵匠一樣，必然會被成熟的工業(yè)化替代，如果編程行業(yè)幾十年如一日的需要大量勞動力加入，那就是真正的停止不前了，就像現(xiàn)在也一樣，十年前你會寫點 HTML CSS 應(yīng)聘個前端開發(fā)完全沒問題，現(xiàn)在你如果還只會這些，早餓死了，哪些腳手架工具，框架代碼難道不是低代碼的一種體現(xiàn)嗎？

就現(xiàn)在來說，擁抱變化和發(fā)展，提升技術(shù)能力才是正道，做那個消滅程序員的程序員，直到有一天這個世界沒有程序員了，才是程序員最大的勝利；

晚安，42……