低代碼，要怎麼低？和低代碼有關的 10 個問題

或許是由於 Mendix 和 Outsystems 的收購及融資，還有 Gartner/Forrester 的鼓吹（Gartner 甚至預測 4 年後低代碼開發會佔應用開發的 65% 以上，你敢信？），這兩年低代碼突然開始受到關注，很多公司在開發這方面的產品，咱們也將 amis 開源項目的介紹改爲了「前端低代碼框架」，並推出了包含先後端的低代碼平臺「愛速搭」，本文將談談我對低代碼的理解，嘗試回答這個 10 問題：css

低代碼是什麼？html
以前是否有低代碼平臺？它們是怎麼作的？前端
低代碼究竟能解決什麼問題？git
低代碼平臺適合用在什麼地方？程序員
低代碼平臺會帶來什麼新問題？github
低代碼平臺的難點在哪？web
前端如何低代碼？算法
後端如何低代碼？數據庫
低代碼平臺是否會大量取代研發？django
將來會怎樣？

低代碼是什麼？

按維基百科的說法，低代碼這個稱呼是 Forrester 在 2014 年提出的，指那些用可視化方式建立應用的平臺，特色是代碼量比傳統開發少得多，甚至無代碼，因此能顯著提高開發效率。

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

在線 IDE 和編輯器，界面方面雖然有可視化設計，但須要二次開發才能用。
提供一站式開發平臺，提供了持續集成、部署和運維等功能，包含開發全流程。
簡化前端開發，界面方面能夠作到不用寫 JavaScript。
簡化後端開發，能夠在線設計數據結構，並實現增刪改查功能。
完全簡化先後端開發，甚至變成無代碼平臺，什麼均可視化編輯，易用性好，但犧牲了靈活性，這裏面有不少子分類，好比 BPM、OA 系統、APP 開發等。
圍繞某個成熟產品擴展功能，好比 CRM、ERP 之類的產品，爲了知足定製需求，提供定製開發功能。

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

"設計系統的架構受制於產生這些設計的組織的溝通結構。" ——M. Conway

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

若是是前端團隊，通常會選第 1 種形式，不多考慮第 3 種，由於團隊成員都會 JavaScript，不必弄個不用寫 JavaScript 的產品，更不會考慮第 4 種，由於不負責後端開發。

若是後端的團隊，就會選擇第 4 種，由於只負責後端開發。

若是是大公司內的工程團隊，由於職責是負責開發環境，因此會選擇第 2 種形式，但這種形式通常有不少定製功能，而且依賴公司內部基礎設施，致使只能在內部使用。

若是是創業公司，每每會選擇第 5 種形式，面向外部固然是先後端都封裝起來更簡單，但可能過於追求「無代碼」，致使雖然用起來簡單，卻失去了靈活性，只適合簡單應用。

若是公司自己有成熟產品了，天然是選擇第 6 種方式，圍繞這個產品來擴展更有優點。

所以下次在瞭解一款低代碼產品前，先了解它背後是什麼團隊，擅長作什麼，團隊背景將在很大程度上決定這款產品的側重點。

以前是否有低代碼平臺？它們是怎麼作的？

在低代碼這個名詞出現前早就有各類提高開發應用效率的產品了，好比我知道最先的是 FileMaker，它在 1985 年就出現了，發展歷史幾乎和這幾十年的計算機技術同步，最先是 DOS 下的程序，蘋果推出 GUI 操做系統 Macintosh 以後改爲了 GUI 程序，在 2010 年移動時代推出了手機版的 FileMaker Go，而後在 2016 年推出了雲上版本 FileMaker Cloud，最新版本又加入了人工智能。。。

FileMaker 最初定位是個數據庫，但它在數據庫的基礎上擴展了應用開發功能，使得能夠基於它開發應用，好比下圖是用它編輯應用界面的例子：

FileMaker

相似的還有 Microsoft Access，也是很是古老的軟件，1992 年就發佈了：

Access

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

Oracle APEX

另外就是本文的配圖，來自 Visual Basic 6.0，1998 年發佈的，功能比如今的許多低代碼平臺都強。

29 年前的 Visual Basic 6.0

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

Salesforce

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

而相似 amis 這種經過配置生成後臺頁面的方式，我最先是在 Django 框架裏看到的，它從 2005 年開始開發，下面是一個例子，用於定義數據模型字段：

from django.db import models

class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

有了這個定義，Django admin 插件就會自動生成管理後臺頁面，好比下面是新增一個問題的表單：

Django Admin

但 Django 這種實現方法有不少限制，加上先後端沒分離，因此十幾年過去了沒什麼改進。

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

對於這個問題，有兩種極端，專業開發者會認爲低代碼平臺是個玩具，沒什麼用，而小白又覺得有了這個徹底不懂寫代碼也能開發應用，但這兩種想法都不太正確。

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

全部軟件活動包括：
根本任務--打造構成抽象軟件實體的複雜概念結構。
次要任務--使用編程語言表達這些抽象實體，在空間和時間限制內將它們映射成機器語言。

這個分類最先出如今 1986 年做者的論文裏，年代久遠可能看過的人很少，這裏多說兩句，「根本任務」指什麼？舉個例子，好比要實現一款發工資的軟件，裏面涉及到如何計算所得稅，那就得實現我的所得稅的計算方法，用什麼語言實現這個算法屬於「次要任務」，而這個算法自己屬於「根本任務」，不管用什麼方式實現，你都不可能下降這個算法複雜度，好比我的所得稅有 7 個層級，那就必定在某個地方有 7 個 if 語句。

「根本任務」沒法解決，由於它就是需求自己，惟一解決辦法是砍需求。

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

提供一種簡化的 DSL，相似 Excel 裏的公式。
提供圖形化代碼編輯器，相似 Unreal Engine 裏的「藍圖」，或者相似 Blockly/Scratch 那種拼圖的方式。
支持寫代碼或外部 api 來擴展。
平臺內置實現，好比前面提到的我的所得稅，平臺能夠內置一個專門算這個的函數。

其中 DSL 的方式只適合簡單場景，由於 DSL 通常不具有複雜的邏輯控制、定義函數等功能，DSL 中要加入這些功能還不如直接用成熟的語言，好比 JavaScript/Lua。

不少低代碼平臺使用的是第 2 種方式，這種方式看起來最符合低代碼平臺的定義，也看起來最高大上，以 UE4 裏的藍圖爲例，這是我見過最複雜的可視化代碼編輯器，能夠用它來編寫着色器和控制遊戲流程：

UE4 的藍圖編輯器

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

方便預覽，尤爲是寫着色器時能夠立刻看到每一個節點的輸出，這點比代碼有明顯優點。
解決了編程環境問題，不須要花時間配置環境。
節點會列出參數和屬性，這樣就不須要像寫代碼那樣查手冊了，直接點選就能夠修改。
調試能實時生效，好比拖動某個數值立刻能看效果。
不容易犯錯，好比須要符合類型才能連線，由於整個環境是可控的，在不少細節上能夠比代碼報錯跟友好。
最重要的是：藍圖比 C++ 簡單得多，也不像 C++ 那樣須要多年經驗，所以對人員的要求更低，跟容易招到人。

圖形化編程在三維設計領域取得了很多成績，好比 Blender、Grasshopper、Houdini、NUKE、Substance Designer 等，經過節點編程的方式極大提高了靈活度，但這些都是針對特定領域優化，並非通用編程方式。

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

流程圖是一種很是差勁的軟件結構表達方式。實際上，它最好被視爲是 Burks, von Neumann 和 Gold stine 試圖爲他們說設計的計算機提供一種當時迫切須要的高級控制語言。現在的流程圖已經變得複雜了，一張圖有若干頁，有不少鏈接點，這種表現形式實在使人同情。流程圖已經被證實是徹底沒必要要的設計工具--程序員是在開發以後，而不是以前繪製描述程序的流程圖。
更加基本的是，如咱們上面所討論的，軟件很是難以可視化。即便用圖形表達出了流程圖、變量範圍嵌套狀況、變量交叉引用、數據量和層次化數據結構等等，也只是表達了某個方面，就像盲人摸象同樣。

這本書裏預言的是 10 年內不會有突破性進步，然而過了 34 年的今天也沒見明顯進步，1985 年 Raeder 在他的文章裏告訴咱們流程圖最先是給彙編語言用的，由於彙編代碼裏都是跳來跳去的，看着容易暈，有這樣的圖能夠看起來更清晰：

但在高級語言下就不須要這個了，由於高級語言下的代碼可讀性和這張圖是同樣的，但在複雜業務邏輯下用圖形連線會很亂，對於熟悉看代碼的開發者來講效率反而下降了，後來在《人月神話》20 週年記念版裏增長了這樣一句話：

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

因此這幾種方法裏我最傾向的是第 3 種，直接經過代碼擴展功能，目前排名靠前的低代碼平臺都支持代碼擴展，好比 Salesforce 和 ServiceNow，尤爲是 ServiceNow 在先後端都使用 JavaScript，後端用到了 Rhino 引擎。

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

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

什麼樣的應用適合使用低代碼平臺？目前看來最適合的場景是面向企業內部員工（B2E）的應用，也就是企業內部的各類系統及平臺。

雖然也有面向對外應用的低代碼平臺，好比建立移動 APP，但這種只有小公司纔會用，由於對外應用通常是公司主營業務，須要很高的自主可控性，並且定製需求多，對展示的要求也很高，無法複用低代碼平臺中的組件，只能經過自定義代碼擴展，但若是大量使用代碼擴展就還不如徹底本身開發了。

以 amis 爲例，它誕生的背景是有個產品線通過多年發展，內部有超過 100 個後臺系統，幾乎每加個大功能都須要對應的管理後臺來配置參數或管理內容，但開發和維護那麼多系統成本很高，之前端爲例，在這 100 個系統裏使用了 jQuery、Angular、Avalon、React、Vue 等各類框架的不一樣版本，新人接手後發現要改個東西還得先去學某個框架的舊版，有的文檔連接都失效了。

爲了完全下降這些頁面的開發維護成本，amis 使用了配置化的方式來生成，只須要 JSON 配置就能完成全部頁面功能開發，不須要再依賴各類框架了，和以前比有明顯改進，後來推廣到了百度其餘產品線，一共製做了 3.3w 頁面，使用人數近 10w。

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

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

平臺使用本身內部獨立的框架，須要額外的學習成本。
平臺是個黑盒，不清楚內部如何實現，遇到 bug、性能等問題只能求助官方。
若是有的需求不能知足，須要等平臺的排期升級。
信息分佈在各處，不像本地代碼那樣方便全局搜索，對於不熟悉的新人每每得在各個界面裏找半天，並且是功能越強大的平臺越難找。
不方便多人協做，有的平臺只提供少許環境，難以作複雜的分支管理。
平臺後續發展是個未知數，哪天倒閉了怎麼辦？Google 4 年前發佈了一款低代碼建立 APP 的產品 Google App Maker，既能可視化建立界面，又能寫 JavaScript 擴展功能，但它在今年 2 月份的時候宣佈關閉，沒法導出，用戶只能本身重寫一個，連 Google 的低代碼平臺都會關閉，其它小公司就更別說了。

低代碼平臺爲何作不到開放？在我看來主要是兩個緣由：

技術上的矛盾，爲了實現低代碼就得隱藏不少沒必要要的細節，而這些細節有的依賴平臺底層框架，有的依賴平臺編輯器，這些都是低代碼平臺最核心的技術，無法開源。
商業上的矛盾，若是能方便導出，讓使用者能夠二次修改並部署到任意地方，低代碼平臺就變成離線開發工具了，只要一個賬號就能開發無數應用，不利於商業化，所以甚至有的低代碼平臺只提供 SaaS 版本，只能在線使用。

平臺鎖定這個問題在國內更嚴重，有種說法是古代中國屬於大陸農業文明，農業文明的特色是強調自給自足，能不求人就不求人，這個長期影響很難改變，因此國內公司一變大就但願什麼都本身掌握，信不過別人。

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

在這個問題上，咱們雖然也無法將愛速搭的後端開源，但將前端最核心的配置渲染器開源了：

https://github.com/baidu/amisgithub.com

低代碼平臺的難點在哪？

在我看來低代碼平臺的難點是如何同時知足易用性和靈活性，由於它們常常是衝突的，以低代碼平臺中必備的可視化頁面編輯器爲例，要怎麼實現頁面佈局？主要有三種作法：

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

除了佈局，還有另外一個問題是要不要支持自定義 class？不支持的話靈活性差，改個字體全部地方都要配一遍，而支持又致使易用性差，不瞭解 css 的用戶會發現改了一個地方影響到別的了，要想不同還得新建一個 class，有理解上的成本。

咱們有一款製做站點和小程序的 SaaS 產品 AIPage，在開發前曾經調研過各類同類產品，從技術角度上看，前端工程師應該更喜歡 webflow，它幾乎將全部 css 開發都作成了可視化編輯，至關於在線版的 Dreamweaver：

webflow 的 css 編輯

然而繼續調研卻發現，在幾個建站產品裏 webflow 恐怕是商業方面最差的，雖然從 google trends 看和其它競品有數量級的差距。

Google Trends

而這個領域最成功的是連可視化編輯器都沒有的 shopify，它須要使用 Liquid 模板來自定義頁面，這個模板語法和十年前的 PHP Smarty 差很少，功能上還更弱點，從技術角度看徹底不如 Webflow 的編輯器強大，但 Webflow 去年估值 3-4 億，我兩年多前調研 shopify 的時候市值就有 100 多億了，當時以爲太虛高，然而如今市值是 1146 億（2020-9-23）。

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

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

雷軍很吃驚地發現，小米的整個管理系統，就是採購部門也就是供應鏈部門抱着一臺電腦，生產部門抱着一臺電腦，銷售部門抱着一臺電腦，電腦裏都是Excel，三個部門打開以電腦後就對數字，這就是小米的流程管理。
同行知道這些事情之後不相信，認爲這是天下奇聞。一個一年生產幾千萬臺手機的公司，管理流程居然是這樣的，這種流程出問題也是很天然的。

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

Notion 的數據管理

對於易用性和靈活性間的取捨，咱們也在探索中，amis 一方面經過配置的方式低成本，另外一方面又但願能支持更多場景，所以支持複雜的表單嵌套、交互，以及自定義組件等功能，總體來講更傾向靈活性：

前端如何低代碼？

前端開發的主要工做是界面、交互和業務邏輯，20 年前的 FrontPage 和 Dreamweaver 就實現了可視化編輯頁面，但它們生成的代碼遠不如手寫，後來隨着前端重構的流行，開發者又迴歸到經過寫代碼來製做頁面。

如今可視化頁面編輯器主要用於製做靜態原型，或者官網及落地頁，不多用在先後端交互比較多的頁面中，由於動態數據難以在可視化編輯器裏展現，好比 if xxx 的時候顯示 yyy 要怎麼顯示呢？因此界面開發效率提高主要靠 UI 組件庫。

前端 UI 組件庫十幾年前就有了，好比 YUI 是在 2006 年發佈，jQuery UI、Ext JS 也緊跟着在 2007 年發佈了，咱們 10 年前也曾經作過 Tangram component，但這些組件庫在產品線中用得很少，你想一想百度搜索、貼吧、知道、百科的各個頁面中，有哪些東西是通用的？能想到的恐怕只有輪播圖、彈出層、下拉菜單這幾個，這些在總體開發中佔比不高，即使都用上對總體效率提高也不明顯，因此前面也提到低代碼平臺不適合用在面向用戶的產品中。

但在企業應用中狀況就不同了，這些應用頁面類似度更高，大部分是表格表單，並且更重視功能而不是個性化展示，所以跟容易實現複用，好比相似下面的聊天窗口：

在企業應用裏甚至能夠簡化成表格展示，第一列是時間，第二列是用戶名，第三列是文本，雖然展示差了不少，功能倒是同樣的。

然而 UI 組件庫強依賴開發，並不能算低代碼，要想低代碼必須進一步下降成本，好比相似 amis 那種用配置化的方式，它和 UI 組件庫有什麼不一樣？在我看來主要是這兩點明顯區不一樣：

1. 突破前端圈的易用性。

不少 UI 組件庫都會號稱易用，但這個易用是有前提的，至少你得會 JavaScript，而 amis 由於只是寫 JSON 配置，加上有可視化編輯器，它作到了能夠不須要了解前端就能使用，在百度內部 amis 平臺的使用者絕大部分都不是前端，這是通常 UI 組件庫都作不到的。

是否能夠給 UI 組件庫加個可視化編輯器？以前也有不少人嘗試過，但行不通，由於 UI 庫必須用代碼來鏈接各個功能，好比數據的加載和綁定、事件的處理等，這些功能難以使用可視化編輯器來實現。

2. 完整的界面解決方案。

UI 組件庫通常只做爲頁面中的一部分，而 amis 實現的是完整頁面的配置化，能夠經過配置實現交互功能，還包括富文本編輯器、條件組合等組件。

後端如何低代碼？

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

系統開發通用性問題，好比
1. 登陸、賬號/角色、權限管理
2. 頁面路由和導航
3. 外部系統對接，有的還提供一種通用協議來連各類數據源
數據管理，增刪改查
流程管理
開發及運行環境

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

基於表單，優勢是用起來簡單，只須要設計好表單就能夠用了，但缺點是靈活性要弱，難以支持複雜的關係。
基於數據模型，須要先定義數據模型，優勢是靈活性強，但易用性又差了，非開發人員使用會有成本。
提供 BaaS 服務，好比開源的 Parse，經過提供友好的 API 來實現用戶管理、數據存取等功能，這種方式須要寫後端代碼，但靈活性高。

以咱們本身爲例，「愛速搭」使用了數據模型方式，數據模型實際上是在數據庫表的基礎上的封裝，全部修改操做會轉成表結構的變動，因此用戶最好能有點數據庫基礎知識，犧牲了易用性，爲何要這樣作？咱們的主要考慮是：

在靈活性方面和傳統數據庫開發是同樣的，性能也同樣，咱們但願能支持各類類型的應用開發，而不僅是簡單的辦公場景。
開發者更熟悉關係數據庫，有些低代碼平臺基於 MongoDB 來方便擴展字段，但主流項目開發中仍是使用關係數據庫。
可使用 SQL 對數據進行修改和查詢，不只瞭解的人多，還能很方便對接外部 BI 平臺作數據分析。
方便接入現有數據庫，愛速搭支持直連已有數據庫，基於已有數據開發應用，無需先將數據導入到平臺中。
減小平臺鎖定風險，使用傳統數據庫更容易將現有數據遷移出來，改爲轉成傳統的開發方式，加上前端使用開源 amis 渲染，下降了平臺鎖定的風險。

「愛速搭」中的數據模型

流程也是低代碼平臺中的經常使用功能，好比用可視化方式設計審批流：

「愛速搭」中的流程設計

低代碼是否會大量取代研發？

不會，緣由以下：

前面提到太低代碼不適合開發面向客戶（toC）的應用，在許多公司這部分纔是最占人力的。
對於企業內部應用，低代碼能夠顯著提高效率，但效率提高帶來的不是人員減小，而是需求增多，不少以前中低優的項目終於排上了，前面提到百度內部的 amis 建立了 3.3w 個頁面，這裏面確定很多是效率提高後多出來的，由於百度沒那麼多作後臺頁面的前端人力。
低代碼平臺解決不了「根本任務」，圖形化編程只適合特定場景，用它來作控制流還不如寫代碼，所以依然須要研發。

將來會怎樣？

個人我的判斷是：

圖形化編程只能在特定領域成功，目前看來主要是和音樂及圖形相關的軟件。
面向普通用戶的無代碼平臺發展會受限，不少時候還不如用「Excel」。
對於成熟的垂直領域，購買軟件是成本最低且效果最好的選擇，好比數據可視化，咱們的 Sugar 開發了好多年，而購買只需幾萬就能馬上用上。
低代碼在國內和國外會有明顯區別，國內更喜歡私有部署而不是 SaaS 版本，技術鎖定將會是在國內推廣時的最大障礙。
低代碼平臺不適合用來開發面向客戶的應用，之後也同樣。
對於企業內部應用，低代碼平臺將會發揮重要做用，它已經被實踐證實能夠極大提高效率，很值得嘗試。