或許是因?yàn)?Mendix 和 Outsystems 的收購及融資，還有 Gartner/Forrester 的鼓吹（Gartner 甚至預(yù)測 4 年后低代碼開發(fā)會(huì)占應(yīng)用開發(fā)的 65% 以上，你敢信？），這兩年低代碼忽然開始受到關(guān)注，不少公司在開發(fā)這方面的產(chǎn)品，jabdp平臺(tái)就是這樣的一種低代碼開發(fā)平臺(tái)。本文將談?wù)勎覍?duì)低代碼的理解，嘗試回答這個(gè) 10 問題：

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

低代碼是什么？

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

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

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

為什么會(huì)有那么多種形式？在我看來主要和團(tuán)隊(duì)定位有關(guān)，有個(gè)「康威定律」是這么說的：

"設(shè)計(jì)系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)。" ——M. Conway

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

如果是前端團(tuán)隊(duì)，一般會(huì)選第 1 種形式，很少考慮第 3 種，因?yàn)閳F(tuán)隊(duì)成員都會(huì) JavaScript，沒必要弄個(gè)不用寫 JavaScript 的產(chǎn)品，更不會(huì)考慮第 4 種，因?yàn)椴回?fù)責(zé)后端開發(fā)。

如果后端的團(tuán)隊(duì)，就會(huì)選擇第 4 種，因?yàn)橹回?fù)責(zé)后端開發(fā)。

如果是大公司內(nèi)的工程團(tuán)隊(duì)，因?yàn)槁氊?zé)是負(fù)責(zé)開發(fā)環(huán)境，所以會(huì)選擇第 2 種形式，但這種形式一般有很多定制功能，并且依賴公司內(nèi)部基礎(chǔ)設(shè)施，導(dǎo)致只能在內(nèi)部使用。

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

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

因此下次在了解一款低代碼產(chǎn)品前，先了解它背后是什么團(tuán)隊(duì)，擅長做什么，團(tuán)隊(duì)背景將在很大程度上決定這款產(chǎn)品的側(cè)重點(diǎn)。

之前是否有低代碼平臺(tái)？它們是怎么做的？

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

FileMaker 最初定位是個(gè)數(shù)據(jù)庫，但它在數(shù)據(jù)庫的基礎(chǔ)上擴(kuò)展了應(yīng)用開發(fā)功能，使得可以基于它開發(fā)應(yīng)用，比如下圖是用它編輯應(yīng)用界面的例子：

FileMaker

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

Access

Oracle 在 2004 年也搞過一個(gè)叫 APEX 的東西，基于向?qū)У姆绞缴蓭追N固定模板頁面，雖然靈活性差但用起來簡單，最近也改叫低代碼了。

Oracle APEX

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

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

Salesforce

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

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

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

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

所有軟件活動(dòng)包括：

根本任務(wù)–打造構(gòu)成抽象軟件實(shí)體的復(fù)雜概念結(jié)構(gòu)。

次要任務(wù)–使用編程語言表達(dá)這些抽象實(shí)體，在空間和時(shí)間限制內(nèi)將它們映射成機(jī)器語言。

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

「根本任務(wù)」無法解決，因?yàn)樗褪切枨蟊旧?，唯一解決辦法是砍需求。

低代碼平臺(tái)主要解決的是「次要任務(wù)」，用更簡化的方式來實(shí)現(xiàn)同樣的功能，比如前面那個(gè)問題，在低代碼平臺(tái)中常見有這幾種做法：

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

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

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

根據(jù) Epic 國內(nèi)社區(qū)經(jīng)理的說法，藍(lán)圖在實(shí)際開發(fā)中用得更多，我的個(gè)人體會(huì)是這種編輯器有以下幾個(gè)好處：

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

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

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

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

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

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

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

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

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

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

低代碼平臺(tái)適合用在什么地方？

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

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

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

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

低代碼平臺(tái)會(huì)帶來什么新問題？

盡管低代碼平臺(tái)能明顯提升效率，但它也會(huì)帶來新的問題，比如擴(kuò)展性、難以支持復(fù)雜場景、性能等問題，但在我看來最大的問題是平臺(tái)鎖定，許多問題都是這點(diǎn)帶來的：

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

低代碼平臺(tái)為什么做不到開放？在我看來主要是兩個(gè)原因：

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

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

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

在這個(gè)問題上，jabdp低代碼平臺(tái)已經(jīng)實(shí)現(xiàn)了全部開源，https://gitee.com/jabdp/jabdp。

低代碼平臺(tái)的難點(diǎn)在哪？

在我看來低代碼平臺(tái)的難點(diǎn)是如何同時(shí)滿足易用性和靈活性，因?yàn)樗鼈兘?jīng)常是沖突的，以低代碼平臺(tái)中必備的可視化頁面編輯器為例，要怎么實(shí)現(xiàn)頁面布局？主要有三種做法：

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

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

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

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

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

同行知道這些事情以后不相信，認(rèn)為這是天下奇聞。一個(gè)一年生產(chǎn)幾千萬臺(tái)手機(jī)的公司，管理流程竟然是這樣的，這種流程出問題也是很自然的。

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

前端如何低代碼？

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

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

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

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

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

后端如何低代碼？

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

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

• 登錄、帳號(hào)/角色、權(quán)限管理
• 頁面路由和導(dǎo)航
• 外部系統(tǒng)對(duì)接，有的還提供一種通用協(xié)議來連各種數(shù)據(jù)源

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

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

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

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

不會(huì)，原因如下：

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

未來會(huì)怎樣？

我的個(gè)人判斷是：

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

好了，今天的文章分享到這就結(jié)束了，要是喜歡的朋友，請(qǐng)點(diǎn)個(gè)關(guān)注哦！–我是簡搭(jabdp)，我為自己“帶鹽”，感謝大家關(guān)注。