什么是低代碼

低代碼是指通過少量代碼就可以快速生成應(yīng)用程序的開發(fā)平臺，通過可視化進(jìn)行應(yīng)用程序開發(fā)的方法，使具有不同經(jīng)驗(yàn)水平的開發(fā)人員可以通過圖形化的用戶界面，使用拖拽組件和模型驅(qū)動(dòng)的邏輯來創(chuàng)建網(wǎng)頁和移動(dòng)應(yīng)用程序。

可視化 是低代碼唯一不可缺少的功能。

可視化編輯

對于實(shí)現(xiàn)可視化編輯來說，必要條件是聲明式。與聲明式相對的，還有一種編碼模式叫命令式。

比如要實(shí)現(xiàn)一個(gè)藍(lán)色的方塊，HTML、CSS 就是聲明式，來實(shí)現(xiàn)它，只需要這么寫：

而如果換成使用命令式的 javascript 來實(shí)現(xiàn)，則可能會(huì)這么寫：

兩種方式最終展現(xiàn)效果是一樣的，但這兩種代碼在實(shí)現(xiàn)思路上有本質(zhì)區(qū)別：

聲明式直接描述最終效果，不關(guān)心如何實(shí)現(xiàn)。而命令式則關(guān)注如何實(shí)現(xiàn)，明確怎么一步步達(dá)到這個(gè)效果。

回到可視化編輯器的角度看，它們的最大區(qū)別是：聲明式可以直接從展現(xiàn)結(jié)果反向推導(dǎo)回源碼，命令式則無法做到反向推導(dǎo)。

反向推導(dǎo)是編輯器必備功能，比如編輯器里的常見操作是點(diǎn)選這個(gè)區(qū)塊，然后修改它的顏色，在這兩種代碼中如何實(shí)現(xiàn)？

如果是聲明式的 HTML CSS，可以直接改 style 的 background 值，而基于 Canvas 的命令式代碼則無法實(shí)現(xiàn)這個(gè)功能，因?yàn)闊o法從展現(xiàn)找到實(shí)現(xiàn)它的代碼，因?yàn)槊钍酱a實(shí)現(xiàn)同樣效果的可能方式是無數(shù)的，除了前面的示例，下面這段代碼也可以實(shí)現(xiàn)一樣的效果：畫一條長 100，粗 100 的線段，在最終視覺呈現(xiàn)上也可以看做是一個(gè)矩形。

因此可以簡單得到一個(gè)結(jié)論：命令式代碼無法實(shí)現(xiàn)可視化編輯，而可視化編輯是低代碼唯一不可少的功能，所以所有低代碼平臺必然只能采用聲明式代碼，這也是為什么所有低代碼平臺都會(huì)有內(nèi)置的 DSL。

聲明式語言的優(yōu)缺點(diǎn)

這些聲明式語言有以下優(yōu)點(diǎn)：

（1）容易上手，因?yàn)槊枋龅氖墙Y(jié)果，語法可以做得簡單，非研發(fā)也能快速上手 HTML 及 SQL。

（2）支持可視化編輯，微軟的 HTML 可視化編輯 FrontPage 在 1995 年就有了，現(xiàn)在各種 BI 軟件可以認(rèn)為是 SQL 的可視化編輯。

（3）容易優(yōu)化性能，無論是瀏覽器還是數(shù)據(jù)庫都在不斷優(yōu)化，比如可以自動(dòng)改成并行執(zhí)行，這是命令式語言無法自動(dòng)實(shí)現(xiàn)的。

（4）容易移植，容易向下兼容，現(xiàn)在的瀏覽器能輕松渲染 30 年前的 HTML，而現(xiàn)在的編譯器沒法編譯 30 年前的瀏覽器引擎代碼。

而這些語言的缺點(diǎn)是：

（1）只適合特定領(lǐng)域，命令式的語言比如 JavaScript 可以用在各種領(lǐng)域，但 HTML CSS 只適合渲染文檔及界面，SQL 只適合做查詢。

（2）靈活性差，比如 SQL 雖然內(nèi)置了很多函數(shù)，但想只靠它實(shí)現(xiàn)業(yè)務(wù)是遠(yuǎn)遠(yuǎn)不夠的。

（3）調(diào)試?yán)щy，遇到問題時(shí)如缺乏工具會(huì)難以排查，如果你在 Firefox 出現(xiàn)前開發(fā)過頁面就會(huì)知道，由于 IE6 沒有開發(fā)工具，編寫復(fù)雜頁面體驗(yàn)很差，遇到問題要看很久代碼才發(fā)現(xiàn)是某個(gè)標(biāo)簽沒閉合或者 CSS 類名寫錯(cuò)了。

（4）強(qiáng)依賴運(yùn)行環(huán)境，因?yàn)槁暶魇街幻枋鼋Y(jié)果而不關(guān)注實(shí)現(xiàn)，因此強(qiáng)依賴運(yùn)行環(huán)境，但這也帶來了以下問題：

1）功能取決于運(yùn)行環(huán)境，比如瀏覽器對 CSS 的支持程度決定某個(gè)屬性是否有人用，雖然出現(xiàn)了新的 CSS 提案，但 Firefox 和 Safari 都不支持，而且上手成本太高，預(yù)計(jì)以后也不會(huì)流行。

2）性能取決于運(yùn)行環(huán)境，比如同一個(gè) SQL 在不同數(shù)據(jù)庫下性能有很大區(qū)別。

3）對使用者是黑盒，使用者難以知道最終實(shí)現(xiàn)，就像很少人知道數(shù)據(jù)庫及瀏覽器的實(shí)現(xiàn)細(xì)節(jié)，完全當(dāng)成黑盒來使用，一旦遇到性能問題可能就不知所了。

4）技術(shù)鎖定，因?yàn)榧幢闶亲铋_放的 HTML 也無法解決，很多年前許多網(wǎng)站只支持 IE，現(xiàn)在又變成了只支持 Chrome，微軟和 Opera 在掙扎了很多年后也干脆直接轉(zhuǎn)向用 Chromium。同樣的即便有 SQL 標(biāo)準(zhǔn)，現(xiàn)在用的 Oracle/SQL Server 應(yīng)用也沒法輕松遷移到 Postgres/MySQL上。低代碼行業(yè)未來也一樣，即便出了標(biāo)準(zhǔn)也解決不了鎖定問題，更有可能是像小程序標(biāo)準(zhǔn)那樣發(fā)展緩慢，功能遠(yuǎn)落后于微信。

因?yàn)榈痛a就是一種聲明式編程，所以這些聲明式優(yōu)缺點(diǎn)，就是低代碼的優(yōu)缺點(diǎn)。

低代碼的實(shí)現(xiàn)方案

以前端的實(shí)現(xiàn)來說，其核心是界面渲染。前面提到前端 HTML CSS 可以看成一種描述界面的低代碼 DSL，因此前端界面實(shí)現(xiàn)低代碼會(huì)比較容易，只需要對 HTML CSS 進(jìn)行更進(jìn)一步封裝，定義 JSON schema。比如用類似如下的方式來描述頁面：

這里大家?guī)缀跞际褂?JSON 主要是兩方面原因：

低代碼平臺編輯器幾乎都是基于 Web 實(shí)現(xiàn)，JavaScript 可以方便操作 JSON。JSON 可以支持雙向編輯，它的讀取和寫入是一一對應(yīng)的。因此界面呈現(xiàn)上的低代碼實(shí)現(xiàn)起來，我們只需要豐富物料庫，通過拖拽這些物料拼出想要的東西后生成 json 描述即可。

再來說說交互邏輯的實(shí)現(xiàn)。

前面說到前端界面低代碼是比較容易，但交互及邏輯處理卻很難低代碼化，目前常見實(shí)現(xiàn)有三種方案：

1、使用圖形化編程；

2、固化交互行為；

3、使用 JavaScript；

先說第一種圖形化編程，這是非常自然的想法，既然低代碼的關(guān)鍵是可視化，那直接使用圖形化的方式編程是否可行？

但這么做局限性很大，本質(zhì)的原因是命令式的代碼無法可視化。即便將循環(huán)、分支判斷、或操作符等等這些抽象為一塊塊的積木，也難以像拼接積木一樣得到想要的東西，因?yàn)榉e木拼接這種方式只適合用來實(shí)現(xiàn)簡單的邏輯，對于復(fù)雜的交互邏輯非常難以實(shí)現(xiàn)。

再來說固化交互行為，如果是面向特定領(lǐng)域，低代碼平臺可以先將這個(gè)領(lǐng)域難以圖形化的邏輯預(yù)置好，讓使用者只需做簡單的處理，使用的時(shí)候只需要調(diào)整參數(shù)就行。當(dāng)然這個(gè)方案最大的缺點(diǎn)是靈活性很低。

因此要實(shí)現(xiàn)更靈活的控制，還是得支持第三個(gè)方案：JavaScript，目前很多低代碼平臺只在界面編輯提供可視化編輯，一旦涉及到交互就得寫 JavaScript，但該方案脫離了低代碼范疇、不是低代碼。

下面來看個(gè)實(shí)例，以阿里的 datav 中的藍(lán)圖編輯器為例，它就是同時(shí)支持了 3 種方案進(jìn)行互補(bǔ)：

一些簡單邏輯用戶可以自己通過藍(lán)圖編輯器去添加然后串并聯(lián)這些節(jié)點(diǎn)來實(shí)現(xiàn)。對于使用場景較多的一些較復(fù)雜的行為可以內(nèi)置固話。而對于較復(fù)雜的邏輯用戶可以自己通過 js 處理。

總結(jié)：

通過以上分析，可以看出在定制化較強(qiáng)的業(yè)務(wù)中，低代碼幾乎沒有用武之地，但基于特定領(lǐng)域或方向的低代碼平臺還是很有意義的。將其作為一類工具，趁手時(shí)即可使用。