或許是因為 Mendix 和 Outsystems 的收購及融資，還有 Gartner/Forrester 的鼓吹（Gartner 甚至預測 4 年后低代碼開發(fā)會占應用開發(fā)的 65% 以上，你敢信？），這兩年低代碼忽然開始受到關注，不少公司在開發(fā)這方面的產品，jabdp平臺就是這樣的一種低代碼開發(fā)平臺。本文將談談我對低代碼的理解，嘗試回答這個 10 問題：

1. 低代碼是什么？
2. 之前是否有低代碼平臺？它們是怎么做的？
3. 低代碼究竟能解決什么問題？
4. 低代碼平臺適合用在什么地方？
5. 低代碼平臺會帶來什么新問題？
6. 低代碼平臺的難點在哪？
7. 前端如何低代碼？
8. 后端如何低代碼？
9. 低代碼平臺是否會大量取代研發(fā)？
10. 未來會怎樣？

低代碼是什么？

按維基百科的說法，低代碼這個稱呼是 Forrester 在 2014 年提出的，指那些用可視化方式創(chuàng)建應用的平臺，特點是代碼量比傳統(tǒng)開發(fā)少得多，甚至無代碼，所以能顯著提升開發(fā)效率。

這個定義比較模糊，使得低代碼平臺有各種各樣的形式，我見到的就有以下幾種：

1. 在線 IDE 和編輯器，界面方面雖然有可視化設計，但需要二次開發(fā)才能用。
2. 提供一站式開發(fā)平臺，提供了持續(xù)集成、部署和運維等功能，包含開發(fā)全流程。
3. 簡化前端開發(fā)，界面方面可以做到不用寫 JavaScript。
4. 簡化后端開發(fā)，可以在線設計數據結構，并實現增刪改查功能。
5. 徹底簡化前后端開發(fā)，甚至變成無代碼平臺，什么都可視化編輯，易用性好，但犧牲了靈活性，這里面有很多子分類，比如 BPM、OA 系統(tǒng)、APP 開發(fā)等。
6. 圍繞某個成熟產品擴展功能，比如 CRM、ERP 之類的產品，為了滿足定制需求，提供定制開發(fā)功能。

為什么會有那么多種形式？在我看來主要和團隊定位有關，有個「康威定律」是這么說的：

"設計系統(tǒng)的架構受制于產生這些設計的組織的溝通結構。" ——M. Conway

比如公司內有兩個獨立的小組，那整個系統(tǒng)設計肯定會劃分出兩個獨立的模塊，相互之間有明確的界限，這也影響了對于低代碼平臺實現方式的選擇。

如果是前端團隊，一般會選第 1 種形式，很少考慮第 3 種，因為團隊成員都會 JavaScript，沒必要弄個不用寫 JavaScript 的產品，更不會考慮第 4 種，因為不負責后端開發(fā)。

如果后端的團隊，就會選擇第 4 種，因為只負責后端開發(fā)。

如果是大公司內的工程團隊，因為職責是負責開發(fā)環(huán)境，所以會選擇第 2 種形式，但這種形式一般有很多定制功能，并且依賴公司內部基礎設施，導致只能在內部使用。

如果是創(chuàng)業(yè)公司，往往會選擇第 5 種形式，面向外部當然是前后端都封裝起來更簡單，但可能過于追求「無代碼」，導致雖然用起來簡單，卻失去了靈活性，只適合簡單應用。

如果公司本身有成熟產品了，自然是選擇第 6 種方式，圍繞這個產品來擴展更有優(yōu)勢。

因此下次在了解一款低代碼產品前，先了解它背后是什么團隊，擅長做什么，團隊背景將在很大程度上決定這款產品的側重點。

之前是否有低代碼平臺？它們是怎么做的？

在低代碼這個名詞出現前早就有各種提升開發(fā)應用效率的產品了，比如我知道最早的是 FileMaker，它在 1985 年就出現了，發(fā)展歷史幾乎和這幾十年的計算機技術同步，最早是 DOS 下的程序，蘋果推出 GUI 操作系統(tǒng) Macintosh 之后改成了 GUI 程序，在 2010 年移動時代推出了手機版的 FileMaker Go，然后在 2016 年推出了云上版本 FileMaker Cloud，最新版本又加入了人工智能。

FileMaker 最初定位是個數據庫，但它在數據庫的基礎上擴展了應用開發(fā)功能，使得可以基于它開發(fā)應用，比如下圖是用它編輯應用界面的例子：

FileMaker

類似的還有 Microsoft Access，也是非常古老的軟件，1992 年就發(fā)布了：

Access

Oracle 在 2004 年也搞過一個叫 APEX 的東西，基于向導的方式生成幾種固定模板頁面，雖然靈活性差但用起來簡單，最近也改叫低代碼了。

Oracle APEX

另外就是Visual Basic 6.0，1998 年發(fā)布的，功能比現在的許多低代碼平臺都強。

還有著名的 SaaS 軟件 Salesforce，十幾年前就可以擴展字段來擴展功能，可以看到界面還是 web 1.0 時代的風格：

Salesforce

另外還有很多商業(yè)產品，它們幾乎都有十年以上的歷史，最近才改叫低代碼平臺。

低代碼究竟能解決什么問題？

對于這個問題，有兩種極端，專業(yè)開發(fā)者會認為低代碼平臺是個玩具，沒什么用，而小白又以為有了這個完全不懂寫代碼也能開發(fā)應用，但這兩種想法都不太正確。

要回答這個問題，首先按《人月神話》里的說法將軟件開發(fā)進行分類：

所有軟件活動包括：

根本任務–打造構成抽象軟件實體的復雜概念結構。

次要任務–使用編程語言表達這些抽象實體，在空間和時間限制內將它們映射成機器語言。

這個分類最早出現在 1986 年作者的論文里，年代久遠可能看過的人不多，這里多說兩句，「根本任務」指什么？舉個例子，比如要實現一款發(fā)工資的軟件，里面涉及到如何計算所得稅，那就得實現個人所得稅的計算方法，用什么語言實現這個算法屬于「次要任務」，而這個算法本身屬于「根本任務」，無論用什么方式實現，你都不可能降低這個算法復雜度，比如個人所得稅有 7 個層級，那就一定在某個地方有 7 個 if 語句。

「根本任務」無法解決，因為它就是需求本身，唯一解決辦法是砍需求。

低代碼平臺主要解決的是「次要任務」，用更簡化的方式來實現同樣的功能，比如前面那個問題，在低代碼平臺中常見有這幾種做法：

1. 提供一種簡化的 DSL，類似 Excel 里的公式。
2. 提供圖形化代碼編輯器，類似 Unreal Engine 里的「藍圖」，或者類似 Blockly/Scratch 那種拼圖的方式。
3. 支持寫代碼或外部 api 來擴展。
4. 平臺內置實現，比如前面提到的個人所得稅，平臺可以內置一個專門算這個的函數。

其中 DSL 的方式只適合簡單場景，因為 DSL 一般不具備復雜的邏輯控制、定義函數等功能，DSL 中要加入這些功能還不如直接用成熟的語言，比如 JavaScript/Lua。

很多低代碼平臺使用的是第 2 種方式，這種方式看起來最符合低代碼平臺的定義，也看起來最高大上，以 UE4 里的藍圖為例，這是我見過最復雜的可視化代碼編輯器，可以用它來編寫著色器和控制游戲流程：

根據 Epic 國內社區(qū)經理的說法，藍圖在實際開發(fā)中用得更多，我的個人體會是這種編輯器有以下幾個好處：

1. 方便預覽，尤其是寫著色器時可以馬上看到每個節(jié)點的輸出，這點比代碼有明顯優(yōu)勢。
2. 解決了編程環(huán)境問題，不需要花時間配置環(huán)境。
3. 節(jié)點會列出參數和屬性，這樣就不需要像寫代碼那樣查手冊了，直接點選就可以修改。
4. 調試能實時生效，比如拖動某個數值馬上能看效果。
5. 不容易犯錯，比如需要符合類型才能連線，因為整個環(huán)境是可控的，在很多細節(jié)上可以比代碼報錯跟友好。
6. 最重要的是：藍圖比 C 簡單得多，也不像 C 那樣需要多年經驗，因此對人員的要求更低，更容易招到人。

圖形化編程在三維設計領域取得了不少成績，比如 Blender、Grasshopper、Houdini、NUKE、Substance Designer 等，通過節(jié)點編程的方式極大提升了靈活度，但這些都是針對特定領域優(yōu)化，并不是通用編程方式。

對于通用編程領域使用節(jié)點編輯器是否可行？《人月神話》里也提到過圖形化編程，原文是這樣說的：

流程圖是一種非常差勁的軟件結構表達方式。實際上，它最好被視為是 Burks, von Neumann 和 Gold stine 試圖為他們說設計的計算機提供一種當時迫切需要的高級控制語言。如今的流程圖已經變得復雜了，一張圖有若干頁，有很多連接點，這種表現形式實在令人同情。流程圖已經被證明是完全不必要的設計工具–程序員是在開發(fā)之后，而不是之前繪制描述程序的流程圖。

更加基本的是，如我們上面所討論的，軟件非常難以可視化。即使用圖形表達出了流程圖、變量范圍嵌套情況、變量交叉引用、數據量和層次化數據結構等等，也只是表達了某個方面，就像盲人摸象一樣。

這本書里預言的是 10 年內不會有突破性進步，然而過了 34 年的今天也沒見明顯進步，1985 年 Raeder 在他的文章里告訴我們流程圖最早是給匯編語言用的，因為匯編代碼里都是跳來跳去的，看著容易暈，有這樣的圖可以看起來更清晰：

但在高級語言下就不需要這個了，因為高級語言下的代碼可讀性和這張圖是一樣的，但在復雜業(yè)務邏輯下用圖形連線會很亂，對于熟悉看代碼的開發(fā)者來說效率反而降低了，后來在《人月神話》20 周年紀念版里增加了這樣一句話：

流程圖是被吹捧得最過分的一種程序文檔。詳細逐一記錄的流程圖是一件令人生厭的事情，而且高級語言的出現使它顯得陳舊過時。

所以這幾種方法里我最傾向的是第 3 種，直接通過代碼擴展功能，目前排名靠前的低代碼平臺都支持代碼擴展，比如 Salesforce 和 ServiceNow，尤其是 ServiceNow 在前后端都使用 JavaScript，后端用到了 Rhino 引擎。

如果需求很常見，可以選擇第 4 種方法，有些低代碼平臺針對某個垂直領域做了優(yōu)化，集成了許多這個行業(yè)常見的功能，在同一個行業(yè)中，一家公司要解決的「根本任務」，在另一家公司大概率也會遇到，因此使用這種低代碼平臺可以明顯降低成本。比如淘寶可以算是電商行業(yè)的「低代碼」平臺，它把各種電商相關的功能都集成進去了，同時還提供了店鋪裝修功能實現個性化設計。

低代碼平臺適合用在什么地方？

什么樣的應用適合使用低代碼平臺？目前看來最適合的場景是面向企業(yè)內部員工（B2E）的應用，也就是企業(yè)內部的各種系統(tǒng)及平臺。

雖然也有面向對外應用的低代碼平臺，比如創(chuàng)建移動 APP，但這種只有小公司才會用，因為對外應用一般是公司主營業(yè)務，需要很高的自主可控性，而且定制需求多，對展現的要求也很高，沒法復用低代碼平臺中的組件，只能通過自定義代碼擴展，但如果大量使用代碼擴展就還不如完全自己開發(fā)了。

以 jabdp為例，常用的功能，例如表單列表的增刪改查，只需簡單的自定義和配置就能自動生成。復雜的業(yè)務功能，只需要會基本的sql語句和javascript語法，就能進行快速開發(fā)，滿足其個性化的業(yè)務需求，設計出各種復雜的企業(yè)web應用。既能快速提高開發(fā)效率，幫助公司節(jié)省人力成本，同時又有效解決企業(yè)級項目中常遇到的改需求的問題，不失靈活性。

jabdp開發(fā)平臺適合用于大部分的企業(yè)級web應用的開發(fā)，尤其適合企業(yè)信息管理系統(tǒng)（MIS）、企業(yè)資源計劃系統(tǒng)（ERP）、客戶關系管理系統(tǒng)（CRM），業(yè)務支撐系統(tǒng)（BSS）等。并且就一些經典的項目案例提取整合出各種類型的項目模板，共享給開發(fā)者參考，開發(fā)者可以在原有的項目基礎上進行修改定制，以打造其個性化的企業(yè)信息化平臺。

低代碼平臺會帶來什么新問題？

盡管低代碼平臺能明顯提升效率，但它也會帶來新的問題，比如擴展性、難以支持復雜場景、性能等問題，但在我看來最大的問題是平臺鎖定，許多問題都是這點帶來的：

1. 平臺使用自己內部獨立的框架，需要額外的學習成本。
2. 平臺是個黑盒，不清楚內部如何實現，遇到 bug、性能等問題只能求助官方。
3. 如果有的需求不能滿足，需要等平臺的排期升級。
4. 信息分布在各處，不像本地代碼那樣方便全局搜索，對于不熟悉的新人往往得在各個界面里找半天，而且是功能越強大的平臺越難找。
5. 不方便多人協(xié)作，有的平臺只提供少量環(huán)境，難以做復雜的分支管理。
6. 平臺后續(xù)發(fā)展是個未知數，哪天倒閉了怎么辦？Google 4 年前發(fā)布了一款低代碼創(chuàng)建 APP 的產品 Google App Maker，既能可視化創(chuàng)建界面，又能寫 JavaScript 擴展功能，但它在今年 2 月份的時候宣布關閉，無法導出，用戶只能自己重寫一個，連 Google 的低代碼平臺都會關閉，其它小公司就更別說了。

低代碼平臺為什么做不到開放？在我看來主要是兩個原因：

1. 技術上的矛盾，為了實現低代碼就得隱藏很多不必要的細節(jié)，而這些細節(jié)有的依賴平臺底層框架，有的依賴平臺編輯器，這些都是低代碼平臺最核心的技術，沒法開源。
2. 商業(yè)上的矛盾，如果能方便導出，讓使用者可以二次修改并部署到任意地方，低代碼平臺就變成離線開發(fā)工具了，只要一個帳號就能開發(fā)無數應用，不利于商業(yè)化，因此甚至有的低代碼平臺只提供 SaaS 版本，只能在線使用。

平臺鎖定這個問題在國內更嚴重，有種說法是古代中國屬于大陸農業(yè)文明，農業(yè)文明的特點是強調自給自足，能不求人就不求人，這個長期影響很難改變，所以國內公司一變大就希望什么都自己掌握，信不過別人。

目前國內只有一個封閉的開發(fā)平臺取得了巨大成功，這個平臺是微信小程序，相比原生 APP 開發(fā)，微信小程序的開發(fā)成本更低，而且還跨平臺，所以其實也能算是低代碼，微信小程序就是很封閉，只能運行在微信上，還得使用專門的框架和工具，連注冊賬號和發(fā)布應用都要人工審核，但依靠微信的影響力和用戶量，這些都不是主要問題。

在這個問題上，jabdp低代碼平臺已經實現了全部開源，https://gitee.com/jabdp/jabdp。

低代碼平臺的難點在哪？

在我看來低代碼平臺的難點是如何同時滿足易用性和靈活性，因為它們經常是沖突的，以低代碼平臺中必備的可視化頁面編輯器為例，要怎么實現頁面布局？主要有三種做法：

1. 基于 flexbox/float 方式來布局，這種方式靈活性強，但犧牲了易用性，需要使用者至少懂點 css，不然弄不明白。
2. 基于絕對定位來布局，這種方式易用性強，想拖哪就拖哪，但又失去了靈活性，要支持多分辨率就得手機和 PC 單獨編輯，而且不好實現根據內容自動撐開高度。
3. 提供水平/垂直分欄的容器，通過它們組合來實現各種布局，這種方式處于上面兩者之間，靈活性和易用性都不突出，只適合用在移動端或后臺類的頁面。

除了布局，還有另一個問題是要不要支持自定義 class？不支持的話靈活性差，改個字體所有地方都要配一遍，而支持又導致易用性差，不了解 css 的用戶會發(fā)現改了一個地方影響到別的了，要想不一樣還得新建一個 class，有理解上的成本。

所以復雜靈活的可視化編輯器有可能吃力不討好，那偏向易用性呢？有些低代碼平臺追求「零代碼」，讓普通人都能用起來，但這樣會面臨另一個意想不到的強大競品：「Excel」，對于普通人來說 Excel 就是一個好用的數據庫，可以添加數據、修改數據、查找數據、排序過濾等，還能做圖表，無需開發(fā)應用就能管理數據。

前段時間在吳伯凡的課程里聽到一個故事，原文是這樣的：

雷軍很吃驚地發(fā)現，小米的整個管理系統(tǒng)，就是采購部門也就是供應鏈部門抱著一臺電腦，生產部門抱著一臺電腦，銷售部門抱著一臺電腦，電腦里都是Excel，三個部門打開以電腦后就對數字，這就是小米的流程管理。

同行知道這些事情以后不相信，認為這是天下奇聞。一個一年生產幾千萬臺手機的公司，管理流程竟然是這樣的，這種流程出問題也是很自然的。

但從另一個角度看，這個故事卻告訴我們，小米剛開始幾年僅靠 Excel 就能生產幾百萬臺手機，創(chuàng)造幾百億流水了，因此很多時候 Excel 就足夠了，目前有些在線編輯的 Excel 平臺，還出現了類似 Airtable 那樣的新型 Excel，還有專門做漂亮表單的 Typeform 等，甚至連 Notion 這個文檔工具都內置一個小數據庫，這類產品在易用性上遠好于各種零代碼平臺。

前端如何低代碼？

前端開發(fā)的主要工作是界面、交互和業(yè)務邏輯，20 年前的 FrontPage 和 Dreamweaver 就實現了可視化編輯頁面，但它們生成的代碼遠不如手寫，后來隨著前端重構的流行，開發(fā)者又回歸到通過寫代碼來制作頁面。

現在可視化頁面編輯器主要用于制作靜態(tài)原型，或者官網及落地頁，很少用在前后端交互比較多的頁面中，因為動態(tài)數據難以在可視化編輯器里展示，比如 if xxx 的時候顯示 yyy 要怎么顯示呢？所以界面開發(fā)效率提升主要靠 UI 組件庫。

前端 UI 組件庫十幾年前就有了，比如 YUI 是在 2006 年發(fā)布，jQuery UI、Ext JS 也緊跟著在 2007 年發(fā)布了，但這些組件庫在產品線中用得不多，你想想百度搜索、貼吧、知道、百科的各個頁面中，有哪些東西是通用的？能想到的恐怕只有輪播圖、彈出層、下拉菜單這幾個，這些在整體開發(fā)中占比不高，即便都用上對整體效率提升也不明顯，所以前面也提到低代碼平臺不適合用在面向用戶的產品中。

但在企業(yè)應用中情況就不一樣了，這些應用頁面相似度更高，大部分是表格表單，而且更重視功能而不是個性化展現，因此更容易實現復用。

在企業(yè)應用里甚至可以簡化成表格展現，第一列是時間，第二列是用戶名，第三列是文本，雖然展現差了很多，功能卻是一樣的。

后端如何低代碼？

在后端方面，低代碼平臺主要能解決這幾類問題：

1. 系統(tǒng)開發(fā)通用性問題，比如

• 登錄、帳號/角色、權限管理
• 頁面路由和導航
• 外部系統(tǒng)對接，有的還提供一種通用協(xié)議來連各種數據源

2. 數據管理，增刪改查
3. 流程管理
4. 開發(fā)及運行環(huán)境

其中最常用的是增刪改查，要如何實現？目前見到有這 3 種方式：

1. 基于表單，優(yōu)點是用起來簡單，只需要設計好表單就可以用了，但缺點是靈活性要弱，難以支持復雜的關系。
2. 基于數據模型，需要先定義數據模型，優(yōu)點是靈活性強，但易用性又差了，非開發(fā)人員使用會有成本。
3. 提供 BaaS 服務，比如開源的 Parse，通過提供友好的 API 來實現用戶管理、數據存取等功能，這種方式需要寫后端代碼，但靈活性高。

低代碼是否會大量取代研發(fā)？

不會，原因如下：

1. 前面提到過低代碼不適合開發(fā)面向客戶（toC）的應用，在許多公司這部分才是最占人力的。
2. 對于企業(yè)內部應用，低代碼可以顯著提升效率，但效率提升帶來的不是人員減少，而是需求增多，很多之前中低優(yōu)的項目終于排上了。
3. 低代碼平臺解決不了「根本任務」，圖形化編程只適合特定場景，用它來做控制流還不如寫代碼，因此依然需要研發(fā)。

未來會怎樣？

我的個人判斷是：

• 圖形化編程只能在特定領域成功，目前看來主要是和音樂及圖形相關的軟件。
• 面向普通用戶的無代碼平臺發(fā)展會受限，很多時候還不如用「Excel」。
• 對于成熟的垂直領域，購買軟件是成本最低且效果最好的選擇。
• 低代碼在國內和國外會有明顯區(qū)別，國內更喜歡私有部署而不是 SaaS 版本，技術鎖定將會是在國內推廣時的最大障礙。
• 低代碼平臺不適合用來開發(fā)面向客戶的應用，以后也一樣。

好了，今天的文章分享到這就結束了，要是喜歡的朋友，請點個關注哦！–我是簡搭(jabdp)，我為自己“帶鹽”，感謝大家關注。