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

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

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

低代碼是什么？之前是否有低代碼平臺？它們是怎么做的？低代碼究竟能解決什么問題？低代碼平臺適合用在什么地方？低代碼平臺會帶來什么新問題？低代碼平臺的難點在哪？前端如何低代碼？后端如何低代碼？低代碼平臺是否會大量取代研發？未來會怎樣？

低代碼是什么？

按維基百科的說法，低代碼這個稱呼是 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 最初定位是個數據庫，但它在數據庫的基礎上擴展了應用開發功能，使得可以基于它開發應用，比如下圖是用它編輯應用界面的例子：

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

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

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

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

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

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

from django.db import modelsclass Question(models.Model): question_text = models.CharField(max_length=200) pub_date = models.DateTimeField('date published')

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

但 Django 這種實現方法有很多限制，加上前后端沒分離，所以十幾年過去了沒什么改進。

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

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

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

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

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

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

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

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

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

很多低代碼平臺使用的是第 2 種方式，這種方式看起來最符合低代碼平臺的定義，也看起來最高大上，以 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 版本，只能在線使用。

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

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

低代碼平臺的難點在哪？

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

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

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

然而繼續調研卻發現，在幾個建站產品里 webflow 恐怕是商業方面最差的，雖然從 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 這個文檔工具都內置一個小數據庫，這類產品在易用性上遠好于各種零代碼平臺。

對于易用性和靈活性間的取舍，我們也在探索中，amis 一方面通過配置的方式低成本，另一方面又希望能支持更多場景，因此支持復雜的表單嵌套、交互，以及自定義組件等功能，整體來說更傾向靈活性：

前端如何低代碼？

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

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

但在企業應用中情況就不一樣了，這些應用頁面相似度更高，大部分是表格表單，而且更重視功能而不是個性化展現，因此跟容易實現復用，比如類似下面的聊天窗口：

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

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

突破前端圈的易用性。

很多 UI 組件庫都會號稱易用，但這個易用是有前提的，至少你得會 JavaScript，而 amis 因為只是寫 JSON 配置，加上有可視化編輯器，它做到了可以不需要了解前端就能使用，在百度內部 amis 平臺的使用者絕大部分都不是前端，這是一般 UI 組件庫都做不到的。

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

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

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

后端如何低代碼？

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

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

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

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

以我們自己為例，「愛速搭」使用了數據模型方式，數據模型其實是在數據庫表的基礎上的封裝，所有修改操作會轉成表結構的變更，所以用戶最好能有點數據庫基礎知識，犧牲了易用性，為什么要這樣做？我們的主要考慮是 ：

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

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

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

不會，原因如下：

前面提到過低代碼不適合開發面向客戶（toC）的應用，在許多公司這部分才是最占人力的。對于企業內部應用，低代碼可以顯著提升效率，但效率提升帶來的不是人員減少，而是需求增多，很多之前中低優的項目終于排上了，前面提到百度內部的 amis 創建了 3.3w 個頁面，這里面肯定不少是效率提升后多出來的，因為百度沒那么多做后臺頁面的前端人力。低代碼平臺解決不了「根本任務」，圖形化編程只適合特定場景，用它來做控制流還不如寫代碼，因此依然需要研發。

未來會怎樣？

我的個人判斷是：

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

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。