傅一平鑒語：

作為外行，只摘抄文中核心觀點，不作評價，文章寫得淺顯易懂，讀起來很舒服：

1、低代碼平臺在行業(yè)有共識，比如要支持通用場景（如UI、邏輯和數(shù)據(jù)三層都要有），隨著行業(yè)發(fā)展標準化程度肯定會進一步提高，但無代碼平臺沒有行業(yè)共識，低代碼和無代碼的關系類似關系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫的關系，無代碼定義的過于寬泛，將會慢慢淡出

2、低代碼平臺主要面向專業(yè)開發(fā)，這點已經(jīng)是頭部分析機構的共識，低代碼不是一個想吸引業(yè)務用戶的用語，業(yè)務人員見了“代碼”兩個字就嚇跑了，再低也沒用，如果業(yè)務人員寫不了100行代碼的話，那10行也一樣寫不了

3、無代碼和低代碼完全不同，無代碼面向業(yè)務人員，低代碼面向開發(fā)人員；無代碼泛指多種開發(fā)細分領域應用的工具，低代碼特指一種通用開發(fā)工具；無代碼不被國際頭部分析機構認可，低代碼被廣泛認可

4、要判斷一個低代碼平臺是否專業(yè)，可以重點看模型驅動、可視化開發(fā)、表達式語言、軟件工程、開放集成和腳本語言等六個方面。對照這些標準，不難看出迄今為止應該說國內(nèi)還很少有專業(yè)的低代碼平臺，雖然輿論甚是喧囂

5、業(yè)界關于低代碼適用場景的觀點大多數(shù)都是錯的。比如業(yè)界很多人講低代碼搞不定復雜的企業(yè)級應用，但都毫無根據(jù)。從技術原理出發(fā)，低代碼其實最適合做的就是企業(yè)應用，即便是CRM、ERP這樣復雜的應用；業(yè)界認為低代碼適合做“簡單的工作流和表單流轉的應用”、“生命周期短的應用”、“創(chuàng)新型應用”等觀點也都是錯的，這些應用很多恰恰不適合低代碼

6、低代碼不適合做的應用是對算法、界面、性能、分析和智能化等專業(yè)性要求高的應用

7、低代碼對企業(yè)應用開發(fā)價值明顯，但也不是銀彈，不要過度神化

正文開始

按規(guī)則這篇應該叫做“數(shù)字技術名詞解釋—低代碼”，但之前的名詞解釋篇都是一兩天草就，這篇磨蹭了半個多月，七七八八寫了過萬字，于是做一把標題黨。

低代碼這個概念今年極火，爭議也極大。有些人力捧，覺得以后“人人都是程序員”，， 又有不少人嗤之以鼻，如有ERP老兵譏諷《低代碼，不要以比“中臺”還快的速度臭大街》，有ThoughtWorks中國某徐姓CTO怒斥《“行業(yè)毒瘤”低代碼》，還有很多認為低代碼是新瓶裝舊酒，早已有之，或者無非就是個高級外包?？上У氖?，無論支持還是鄙夷，各路專家寫文都是“草就”，至今也沒一篇三觀正且詳實的。阿朱的幾篇三觀是正，但行文也過于簡明，可能懂的自然懂，不懂的還是不懂。

本文希望對這個當前動蕩不安的領域做一點“不草就”的綜合說明，想說清楚七大問題：低代碼和無代碼（也稱零代碼）是什么關系、怎么判斷一個低代碼平臺是否專業(yè)、國內(nèi)是否有專業(yè)的低代碼平臺、低代碼是不是新瓶裝舊酒、低代碼真的搞不定專業(yè)的企業(yè)應用嗎、低代碼不適合開發(fā)哪些應用、低代碼并非銀彈。

鑒于這個領域現(xiàn)在實在太亂，希望大家能多轉發(fā)一下，讓更多的人正確理解低代碼。

第一步得把低代碼和無代碼分清楚，因為這倆差異巨大，但現(xiàn)在業(yè)界經(jīng)?；鞛橐徽劊瑢е潞芏嗪芏鄦栴}，比如雙方爭論但指的不是同一個事情，廠商的口徑亂，行業(yè)報告的結果不能看。

低代碼專指低代碼應用開發(fā)平臺（LCAP），是一個被業(yè)界廣泛認可的概念，頭部的分析機構如Forrester和Gartner都已經(jīng)發(fā)布了多年低代碼開發(fā)平臺的報告。如下圖所示，大家可以看到這兩家的報告入選的產(chǎn)品都很接近，特別是頭部的六家簡直是一模一樣。這說明低代碼應用開發(fā)平臺已經(jīng)是一個比較成熟的市場。

相反，分析機構對無代碼的態(tài)度就很微妙了。雖然也有一些分析機構也提無代碼開發(fā)平臺的概念，如G2（當然更不用說目前混亂的國內(nèi)分析機構），但Forrester和Gartner從未發(fā)布過無代碼開發(fā)平臺的報告。Forrester和Gartner倒也不是說無代碼是個偽概念，他們的共識是無代碼這個詞只是一個營銷用語，主要用來突出一個工具無需編程基礎，消除業(yè)務用戶的恐懼。

'No-code’ is a marketing term, implying the tool is for non-professional developers. — By Gartner

(https:///resources/resource-center/analyst-reports/gartner-quick-answer-low-code-vs-no-code-dev-tools.html)

Businesspeople hankering to deliver their own apps love the “no-code” message. Thus, “no-code” has become a marker for products aimed at empowering business users. However, customers report that even powerful low-code platforms in some cases can’t produce apps without any coding. So what does this mean for the “no-code” promise? — By Forrester

(https://go./blogs/watch-your-language-low-code-and-no-code-are-not-the-same/)

無代碼這個詞通常用來形容一些細分領域的開發(fā)工具，最常見的是應用搭建平臺（國外一般叫App Builder之類），如國外的Appy Pie、國內(nèi)的宜搭、簡道云等，還可以用來形容Airtable / AppSheet / Treelab這類在線表單工具或輕流這類的工作流工具。這幾類工具差別巨大，如下圖所示，還有人將無代碼和低代碼的江湖分成十二個“門派”，由此可見無代碼是一個相當寬泛的概念。

但無代碼的“通用”開發(fā)平臺，目前看并不存在，據(jù)我看將來也不會存在。因為開發(fā)軟件必然要編寫邏輯，就必然要寫代碼，除非哪一天人工智能能做到自動寫代碼。

我覺得低代碼和無代碼的關系有點類似于關系數(shù)據(jù)庫和NoSQL。關系數(shù)據(jù)庫專指一種特定的數(shù)據(jù)庫，即便多家廠商的產(chǎn)品實現(xiàn)可能千差萬別，但至少提供的功能很相似，都高度遵循SQL標準。低代碼開發(fā)平臺雖然今天的標準化程度還沒關系數(shù)據(jù)庫這么高，但無論是Gartner還是Forrester都已經(jīng)開始給出比較清晰的篩選標準，如要支持通用場景（如UI、邏輯和數(shù)據(jù)三層都要有）、要滿足專業(yè)開發(fā)需求等，隨著行業(yè)發(fā)展標準化程度肯定會進一步提高。NoSQL則只要不是SQL都算，不管你是KV、wide-column、文檔還是圖，都可以叫NoSQL。NoSQL這個詞熱了有幾年，但現(xiàn)在不太講了，因為市場格局開始清晰之后，大家就不會關注過于寬泛的NoSQL，而是根據(jù)需要關注具體的類型。我個人認為無代碼這個詞將來也一樣會慢慢淡出，雖然現(xiàn)在十二個門派很是熱鬧，但不出幾年真正有影響力的門派肯定也不多，這時大家也就不關注無代碼而是直接找具體的產(chǎn)品了。

本文后續(xù)只專注討論面向通用應用開發(fā)的低代碼。低代碼不是一個想吸引業(yè)務用戶的用語，業(yè)務人員見了“代碼”兩個字就嚇跑了，再低也沒用，如果業(yè)務人員寫不了100行代碼的話，那10行也一樣寫不了。低代碼平臺主要面向專業(yè)開發(fā)，這點已經(jīng)是頭部分析機構的共識，雖然Forrester之前走過彎路，曾經(jīng)也發(fā)布過面向業(yè)務人員的低代碼開發(fā)平臺報告，但近兩年已經(jīng)不再發(fā)布了，只保留面向專業(yè)開發(fā)者的低代碼報告。用戶數(shù)據(jù)也說明這一點，21CTO在《低代碼開發(fā)可不低，用戶仍需要與IT技術部門聯(lián)手》一文中提到據(jù)某統(tǒng)計“只有6%的低代碼開發(fā)是由業(yè)務人員完成的”，OutSystems的數(shù)據(jù)是69%的用戶是專業(yè)開發(fā)，宜創(chuàng)科技CEO宜博也曾說低代碼面臨“懂技術的看不上，懂業(yè)務的學不會”的尷尬。

所以無代碼和低代碼完全不同，無代碼面向業(yè)務人員，低代碼面向開發(fā)人員；無代碼泛指多種開發(fā)細分領域應用的工具，低代碼特指一種通用開發(fā)工具；無代碼不被國際頭部分析機構認可，低代碼被廣泛認可。

現(xiàn)在國內(nèi)很多行業(yè)專家和分析機構經(jīng)常把兩者混為一談，這對技術的價值衡量、甲方的技術規(guī)劃和選型都造成很大混亂，我迫切希望大家能夠把低代碼和無代碼區(qū)分開，集中研究具備通用能力的低代碼平臺。

現(xiàn)在市場上魚龍混雜號稱“低代碼”的產(chǎn)品很多，怎么才能快速區(qū)分是不是“專業(yè)”？很簡單，找一個最專業(yè)的產(chǎn)品來對標。

哪個產(chǎn)品才是最專業(yè)的？我們可以先看為什么低代碼這兩三年才熱起來？不是因為Salesforce這樣的SaaS廠商，也不是Appian這類BPMS廠商，這輪低代碼熱其實主要是因為OutSystems。OutSystems雖然也早在2001年就成立，但之前一直“猥瑣發(fā)育”，2018年D融資了$3.6億，才突然引爆市場。無論Forrester還是Gartner都把OutSystems列入領導者象限，阿朱說他最推崇的低代碼平臺就四個，OutSystems也是其中之一。所以，OutSystems就是專業(yè)低代碼平臺的代表。

對比OutSystems和很多國內(nèi)所謂的低代碼平臺，我找出了六項區(qū)分度最高的判斷標準：模型驅動、可視化開發(fā)、表達式語言、軟件工程、開放集成和腳本語言。

（1）模型驅動

“模型驅動”可能是最明顯的區(qū)分標志，因為剛好有一個也很流行的概念叫“表單驅動”。很多人搞不清楚這兩個概念，但其實這兩類產(chǎn)品挺好區(qū)分。

首先可以看用戶手冊，這樣不用安裝試用也能看出差別。使用模型驅動的平臺比如OutSystems、Mendix的手冊會有很大一章講怎么做數(shù)據(jù)建模和處理，包括怎么定義實體、實體間關系、主鍵、唯一性、索引、數(shù)據(jù)怎么訪問、篩選、分組、統(tǒng)計等等，還提供SQL或類似擴展。使用表單驅動的產(chǎn)品則往往手冊第一章就是說明怎么定義各種表單，都是各種和界面相關的控件，比如單選多選下拉框、文本日期數(shù)字等。

其次可以看界面。下圖是分別是模型驅動的OutSystems和某表單驅動產(chǎn)品的相關操作界面，大家看是不是很不一樣。

（模型驅動，OutSystems）

（表單驅動）

（2）可視化開發(fā)

可視化開發(fā)不是拖拉拽做個界面（這只能叫可視化設計），而是有完整的可視化編程語言系統(tǒng)，能夠編寫業(yè)務處理邏輯?？碠utSystems這類產(chǎn)品的文檔，你會發(fā)現(xiàn)很多編程語言的基本構造都有，比如順序 / 分支 / 循環(huán) / continue / break、輸入輸出參數(shù)、局部變量 / 全局變量、struct和list、異常等。雖然這些東西都是拖拉拽完成，看上去沒有密密麻麻的一行行代碼來嚇人，但也足以嚇退業(yè)務人員。一下幾張圖都來自于OutSystems，大家可以感受一下。

（左：邏輯開發(fā)工具箱，注意有If、Switch、For Each流程控制；右：一個比較簡單的邏輯）

（怎么拋出和處理異常）

（3）表達式語言

表達式語言有些類似Excel里的公式，有表達式語言才可以做一些比較復雜的計算。下圖是OutSystems的表達式編輯器，大家可以看到有各種操作符，還有很多內(nèi)置函數(shù)，比如數(shù)學函數(shù)、字符串處理函數(shù)等。

OutSystems這個例子看起來還比較簡單，但表達式語言也可以很復雜。微軟是搞語言的行家，下圖是個微軟Power Fx的例子，這個表達式是要提取一個句子最后一個單詞的表達式，也挺復雜吧（說實話我看了好大一陣子才看懂）。

表達式語言也有更平易近人的設計，比如我們輕舟就是用類似Scratch的積木塊設計。兩種設計功能上是等價的，積木塊設計更容易上手，Power Fx這樣的設計寫復雜表達式更方便。

（4）軟件工程

專業(yè)的低代碼平臺需要提供測試、debug、版本控制等軟件工程支持。開發(fā)軟件都會出bug（低代碼平臺基本消除了語法層面的bug，但對語義層面的bug一樣無能為力），需求也總是會變。所以測試、debug、版本控制這些支持也是必不可少的。OutSystems為什么做的最好，我覺得跟它完善的debug支持是分不開的。下圖是OutSystems的debug界面，看起來和專業(yè)IDE有的一拼。

（5）開放集成

理論上，有了模型驅動等上述四大功能，開發(fā)一個不是太復雜的獨立應用就夠了，但典型的企業(yè)軟件都是相互依賴和集成的，所以平臺還需要具備能夠調(diào)用外部API和開放API給別人的能力。平臺如果沒有這兩方面的功能，開發(fā)出來的應用相互之間都沒法連通和集成，全是技術債。我們看國外關于低代碼的文章，經(jīng)常會看到一個詞叫Shadow IT，說的就是這個問題。大家都胡亂的開發(fā)各種應用，還都集成不起來，將是一場大災難。

（6）腳本語言

腳本語言就是用JavaScripts、Python、Java等做擴展，這些其實就是正兒八經(jīng)的專業(yè)編程語言了，但低代碼平臺會把工程復雜性都封裝好，讓開發(fā)者不需要配置部署環(huán)境，隨手就可以寫代碼，寫完一鍵發(fā)布馬上可以運行。

其實上述標準和Gartner是很一致的。Gartner在魔力象限報告里說：

An LCAP is characterized by its use of model-driven or visual development paradigms supported by expression languages and possibly scripting…

里面模型驅動、可視化開發(fā)、表達式語言、腳本語言都提到了。

小結一下，判斷是不是'專業(yè)”低代碼，可以重點看模型驅動、可視化開發(fā)、表達式語言、軟件工程、開放集成和腳本語言等六個方面。

國內(nèi)看似已經(jīng)有很多低代碼平臺，道一云之前做個一個系列測評，T研究、海比等也都出過分析報告，但只要我們對照上述標準就不難看出，雖然低代碼輿論很是喧囂，但迄今為止應該說國內(nèi)還很少有專業(yè)的低代碼平臺。

比如阿里今年一直鼓吹的宜搭，宣稱是“低代碼”應用搭建平臺，但其實是一個“表單驅動”的“無代碼”平臺。阿里其實是打了個擦邊球，說宜搭是“搭建”平臺，沒說是“開發(fā)”平臺，你要說他過度宣傳也算不上。但“搭建”和“開發(fā)”二字之差，差距可大了，“搭建”的意思是基于一些成熟模塊組裝應用，一旦遇到既有模塊不夠用的時候就歇菜。

國內(nèi)很多分析報告提及的產(chǎn)品大部分我都瞄過，但看一圈下來，個人認為也就ClickPaaS可能還夠得上（我也不確定，因為ClickPaaS不開放用戶手冊，沒深入研究），畢竟它有模型驅動和開放集成，其他的門檻都夠不上。

這么混亂的狀態(tài)讓我們的CIO們可怎么辦呢，這再次說明如果缺乏有效的標準篩選真正專業(yè)的低代碼平臺，勢必低代碼和無代碼一鍋粥，結果大家都被搞得稀里糊涂。

關于低代碼還有一種流行的觀點是新瓶裝舊酒，說二十年多年前的Delphi、PowerBuiler（后稱PB）早就是低代碼，但早就被時代淘汰了，今天的低代碼也沒戲。說這些話的大概率還是前輩。

要講清楚這些問題得稍微digg一點歷史，當年的Delphi和PB可是神一般的存在，因為相比同時代的其他技術（比如詰屈聱牙的MFC）來說易用性好太多，這倆不知道做了不知道多少企業(yè)信息化應用。隨手翻看一本《Delphi開發(fā)典型模塊大全》，里面盡是板材排料、進銷存、文檔管理、批發(fā)零售、房地產(chǎn)信息管理等案例。

這倆后來被時代淘汰，主要是因為時代變了，沒跟上?；ヂ?lián)網(wǎng)時代來了后，軟件架構很快就從桌面端的C / S變成Web端的B / S，再后來是移動App。Web應用和App對前后端的要求比桌面應用都要高很多，因為大家做網(wǎng)頁或App都是要勾引用戶主動來訪問啊，不像桌面端的企業(yè)應用就算不好用你為了工作也得用。互聯(lián)網(wǎng)的這個二十年，技術棧發(fā)展的越來越復雜，新的低代碼技術只能一直慢慢醞釀。

但經(jīng)過OutSystems等廠商經(jīng)過十多年的積累，今天的低代碼技術已經(jīng)遠勝當年的Delphi和PB。今天的低代碼要“低”的多，當年的Delph、PB等如果按今天的標準，連入門的資格都沒有。

我們就以當年最流行的Delphi為例，Delphi雖然號稱“可視化編程語言”，但也就是實現(xiàn)了界面的可視化開發(fā)和數(shù)據(jù)庫的ORM，所有的邏輯都是要用代碼寫的，包括怎么把數(shù)據(jù)顯示在表格也都要寫代碼。我們說的六大標準里，頭兩位的模型驅動、可視化開發(fā)這些都沒有。PB也就比Delphi稍好一點，它核心的DataWindow可以無需代碼做出增刪改查，算是邁入模型驅動的門檻，但它不支持實體關系，模型驅動能力并不完整。同時PowerBuilder也沒有可視化的邏輯開發(fā)，按今天的標準也只能在門檻徘徊。

貼兩張老圖讓大家感受一下當年炸子雞—Delphi。

（Delphi的主界面，實現(xiàn)了用戶界面的可視化設計）

（Delphi的邏輯實現(xiàn)界面，得寫代碼）

士別三日當刮目相看，何況十多年。今天的低代碼并不是新瓶裝舊酒，而是新瓶新酒，里外都是新的。說新瓶是因為低代碼這個概念是新的，說新酒是因為今日的OutSystems等專業(yè)低代碼產(chǎn)品的能力已經(jīng)遠超二十年前PC時代的Delphi和PB。

我想說低代碼是新瓶裝舊酒的人啊，看到特斯拉也會說新瓶裝舊酒，不還是汽車嗎，看到iPhone也會說新瓶裝舊酒，不就是個手機嗎，我就打打電話，發(fā)發(fā)短信。這些人啊，可能也不因為別的，可能就是因為年紀太大了。

關于低代碼從DOS時代至今的發(fā)展脈絡，阿朱在《低代碼都快爛大街了，還有人在為低代碼吵架》一文有詳細介紹，感興趣的可以看看。

目前業(yè)界很多人認為低代碼搞不定復雜的企業(yè)應用。如ERP老兵果總在《低代碼，不要以比“中臺”還快的速度臭大街》一文中認為低代碼只適合用來做“簡單的工作流和表單流轉的應用”或“大型應用軟件的功能延伸的開發(fā)”，認為“不適合開發(fā)復雜邏輯的核心業(yè)務”。然而果總并沒有說為什么?！凹夹g領導力”在《如何用低代碼搞垮一家公司？》一文中認為低代碼只適合“創(chuàng)新探索類”、“生命周期短的”等應用。同樣，也沒有給出依據(jù)。類似的言論還很多，但都有一個共性，就是只說低代碼不行，不解釋，而且很多時候還把話說的那個斬釘截鐵。

很多人還真的把自己當回事啊。

企業(yè)應用聽起來高大上，但其實幾十年東西了，能有多復雜呢？界面不用很時尚，不用扛百萬并發(fā)，也沒智能推薦啥的高級算法，其實從軟件開發(fā)角度看企業(yè)應用是比較簡單的。企業(yè)應用的復雜主要是領域模型和業(yè)務流程比較復雜，但從前文我們可以看到，低代碼平臺在建模和邏輯方面的能力都是比較全面的，再通過腳本語言、開放集成等擴展機制，對于不方便低代碼實現(xiàn)的地方，可以和專業(yè)代碼開發(fā)協(xié)作實現(xiàn)。所以用低代碼開發(fā)復雜應用，本質(zhì)上沒問題。

這也不是我一個人的觀點，明道云CEO任向暉寫過一篇《APaaS搞不定復雜的應用，是這樣嗎？》，把企業(yè)應用的復雜性分解為數(shù)據(jù)、權限、流程、算法、集成、報表等六個維度，然后逐一給出解決方案。這才是實事求是的態(tài)度。我覺得任總的分析已經(jīng)比較充分，我也不再展開說了。我相信任何人但凡不帶偏見，深入分析的，都會發(fā)現(xiàn)企業(yè)應用并沒有什么復雜性是低代碼一定搞不定的。

而且用低代碼平臺開發(fā)這類應用，還有不少獨特優(yōu)勢，如開發(fā)人員上手快（我們的經(jīng)驗是個把月就能用的很溜了），開發(fā)效率高，便于業(yè)務人員和開發(fā)之間的溝通（因為邏輯大多是可視化的），不容易形成孤島（因為專業(yè)的低代碼平臺默認就會根據(jù)模型生成API）。OutSystems在其網(wǎng)站上特意強調(diào)：

OutSystems is well-equipped to build ERP and similar large, complex systems with the desired performance and scalability.

OutSystems也有一些這方面的案例，做供應鏈、CRM、ERP的都有。OutSystems成立于2001年，那時候不開發(fā)企業(yè)應用開發(fā)什么呢？

但可能很多人會說，OutSystems作為廠商當然這么宣揚，但目前用低代碼開發(fā)復雜企業(yè)應用確實不多啊。沒錯，但我認為這只是時間問題。

首先，低代碼技術達到成熟狀態(tài)的時間并不長，即便是OutSystems。OutSystems雖然都成立20年了，但低代碼表面看似簡單，其實是一個相當復雜的技術體系，背后涉及核心的編程語言層面的設計，比如DSL、類型系統(tǒng)、泛型等等，還有怎么diff、debug、undo，都不容易。另外低代碼平臺還需要不斷追趕這20年變化極大的技術環(huán)境。20年前是C / S、.Net，后來流行B / S、Java，再后來又得搞App，操作系統(tǒng)從Windows變成Linux，現(xiàn)在又面臨從SOA到微服務的轉型。OutSystems的主任工程師Tiago Sim?es曾介紹過20年來OutSystems的發(fā)展（https:///outsystems-engineering/whats-not-new-in-outsystems-a-product-timeline-c781acd400cb#），可以看到OutSystems一邊一直到補功能，直到2014年的9.0版本支持數(shù)據(jù)聚合處理才算比較完整，另一邊一直在努力追趕技術趨勢，直到2016年的10.0版本一口氣推出Client-Side Logic、Local Storage、異步、Reactive等功能才算對移動App有較好的支持。這玩意是不做不知道，一做嚇一跳，我們是做了輕舟低代碼才知道這個東西很難。

更重要的可能是非技術因素。大部分企業(yè)對CRM、ERP的定制需求還沒那么高，相比用低代碼從頭開發(fā)來說，采用Saleforce、SAP這樣的套裝軟件實施，再做一些二次開發(fā)是更合適的選擇。這也解釋了為什么Saleforce、ServiceNow這樣的SaaS巨頭都有自己的低代碼平臺，而西門子會收購Mendix。另外ERP這樣的企業(yè)軟件實施強依賴咨詢經(jīng)驗，這不是低代碼能解決的，而業(yè)界有經(jīng)驗的咨詢顧問顯然更熟悉SAP這樣的產(chǎn)品，也沒有意愿改變。專業(yè)程序員對低代碼抵觸也非常大，好不容易練就一身武藝，用了低代碼好像都沒用了？業(yè)界越是宣傳用低代碼開發(fā)快多少倍，開發(fā)團隊可能越抵觸。

總之，業(yè)界流行說低代碼不能做CRM、ERP這類復雜的企業(yè)應用，這一說法很多人講，但都沒有根據(jù)。從技術原理出發(fā)，低代碼最適合做的恰恰就是企業(yè)應用。目前用低代碼做復雜企業(yè)級應用的case還不是很多，是因為低代碼技術也就剛成熟不久、定制需求還不夠強（套裝軟件能滿足）或者行業(yè)不愿做，并不能說明它做不了。

很多專家啊，不但錯誤的認為低代碼搞不定復雜企業(yè)應用，還在低代碼適合哪些類型的應用上也說錯了。

低代碼真正不太擅長的，是那些有各種特殊要求的應用，比如：

• 對算法和復雜數(shù)據(jù)結構要求比較高的：我想不會有人想到用低代碼平臺去刷LeetCode題、打ACM比賽的吧。這里有個細微的地方是要區(qū)分是業(yè)務邏輯比較復雜還是算法邏輯比較復雜，業(yè)務邏輯復雜對低代碼來說不是問題，算法邏輯復雜才是問題。那啥叫業(yè)務邏輯復雜呢，就是業(yè)務人員總之是說的清楚，或者是能理解的；啥叫算法邏輯復雜呢，就是業(yè)務人員只能給個目標，具體怎么實現(xiàn)是不管的，就算解釋也是一臉悶逼的聽不懂的。

• 對界面要求特別高的：比如游戲或抖音、云音樂這樣的社交娛樂型的應用。目前主流的低代碼平臺都不擅長做酷炫的界面（也有一些特定類型的低代碼平臺如App Onboard是面向游戲開發(fā)的，不在本文討論范圍之內(nèi)）。

• 頭部互聯(lián)網(wǎng)級應用：頭部互聯(lián)網(wǎng)應用用戶量巨大，為了優(yōu)化性能有很多很多trick，前后臺技術架構非常復雜，低代碼平臺的實現(xiàn)是比較標準的數(shù)據(jù)庫 / 邏輯 / 界面三層架構，無法滿足性能需求。注意這不是說所有互聯(lián)網(wǎng)應用都不合適，只是指那些用戶量特大的頭部應用。

• 分析和智能化應用：分析類應用自然應該用更專業(yè)的BI工具，智能化應用也應該用更專業(yè)的機器學習平臺等工具。

• 系統(tǒng)軟件、科學計算等其他專業(yè)性很強的應用。這個不多說了，估計也沒誰想用低代碼來做，但多說一句，雖然這些系統(tǒng)的內(nèi)核肯定不適合低代碼開發(fā)，但界面可是很適合，我們輕舟低代碼產(chǎn)品正是脫胎于云計算平臺的界面開發(fā)。

現(xiàn)在大家應該可以發(fā)現(xiàn)很多業(yè)界流行的觀點說低代碼適合這個那個的其實也都是錯的，比如：

• 說低代碼適合“簡單的工作流和表單流轉的應用”：事實上專業(yè)的低代碼并不見得特別適合這類應用，比如Gartner就說OutSystems這方面的支持還不太好。其實最適合這類應用的反而是那些“表單驅動”的產(chǎn)品，這些產(chǎn)品并非專業(yè)的低代碼平臺。專業(yè)的低代碼平臺搞這些也不是完全不行，但屬于大炮打蚊子，性價比不高。

• 說低代碼適合“生命周期短的應用”：事實上如果你用OutSystems這樣“最專業(yè)”的低代碼平臺去做營銷活動頁這樣“生命周期短的應用”，你肯定會欲哭無淚。為什么？因為營銷活動頁對界面的要求很高哎。

• 說低代碼適合“創(chuàng)新型應用”：有篇文章按Gartner的方法把應用分成基礎設施型（如 ERP）、差異化型（如 CRM）和創(chuàng)新型應用，說前兩類應用低代碼就別碰了，都是傳統(tǒng)IT的菜，低代碼就搞搞創(chuàng)新型應用，這個說法也不對。互聯(lián)網(wǎng)App算典型的創(chuàng)新型應用吧，上面已經(jīng)說過這個低代碼搞不定。

上面我們說低代碼很適合開發(fā)典型的企業(yè)應用，優(yōu)點明顯，如開發(fā)人員上手快、開發(fā)效率高、增進溝通和集成等，但也不要認為低代碼是銀彈，用了什么問題都解決了。原因主要有以下三個方面。

1）開發(fā)工具只能解決軟件研發(fā)的部分問題。作為開發(fā)工具，低代碼可以加快在需求比較明確時的軟件交付，也可以在大方向比較明確但具體需求不明時加快軟件的迭代更新。但企業(yè)應用和企業(yè)的經(jīng)營管理方式、業(yè)務方向、業(yè)務流程、組織架構密切相關，和人密切相關，這些方面如果有問題，軟件都不知道怎么做，這都不是開發(fā)工具所能解決，該請咨詢還是得請咨詢。低代碼就像特種兵，單兵作戰(zhàn)能力是強，但如果將帥不行，戰(zhàn)略戰(zhàn)術拉垮，也打不了勝戰(zhàn)。

2）低代碼能提升多少開發(fā)效率缺乏權威數(shù)據(jù)，不要有太高預期。業(yè)界有很多對低代碼開發(fā)效率的宣傳，最多的是說什么提升10倍啦，這些一看就是胡扯。一些廠商和分析機構會發(fā)布提效數(shù)據(jù)，看似效果特別好，但因為前面說的無代碼和低代碼沒分清問題，這些數(shù)據(jù)不可信。比如阿里“宜搭”的數(shù)據(jù)說平均將應用開發(fā)成本從17.5人天提高到3.5人天，提效500%，但前面說過“宜搭”是無代碼工具。無代碼工具因為都是面向特定類型的應用高度優(yōu)化的，提效明顯很正常的，但不通用。專業(yè)的低代碼廠商如OutSystems、Mendix，反而不敢宣傳提效多少倍，所以一個廠商宣傳的效果越好，就越不可能是專業(yè)的低代碼平臺。從我們的經(jīng)驗看，用低代碼做一些小系統(tǒng)確實挺快，但上了規(guī)模后還能是不是有數(shù)倍提升，我覺得也不大可能。根據(jù)我們的初步經(jīng)驗，我們覺得提升1到2倍是一個比較合理的預期。

3）行業(yè)典型的項目制限制了低代碼的價值。低代碼平臺因為可視化、效率高，最適合業(yè)務和開發(fā)密切溝通合作，快速迭代。但當前甲乙方之間典型的項目制要求雙方提前簽訂詳細的合同和SOW，這就把本來可以敏捷開發(fā)的生生打回到瀑布模式，這樣低代碼快速迭代的價值就很難體現(xiàn)。項目制存在太久，不是一時半會改的了的。

最后做個小結：

• 無代碼和低代碼不是一個層次的概念。低代碼是以OutSystems、Mendix等產(chǎn)品為代表，主要面向專業(yè)開發(fā)的通用應用開發(fā)平臺；無代碼則是一個營銷用語，用于形容很多種面向業(yè)務人員的工具，如應用搭建、在線表單、工作流等。不存在無代碼的通用應用開發(fā)平臺。無代碼這個概念過于寬泛，未來很可能會慢慢淡出市場。

• 要判斷一個低代碼平臺是否專業(yè)，可以重點看模型驅動、可視化開發(fā)、表達式語言、軟件工程、開放集成和腳本語言等六個方面。對照這些標準，不難看出迄今為止應該說國內(nèi)還很少有專業(yè)的低代碼平臺，雖然輿論甚是喧囂。

• 業(yè)界關于低代碼適用場景的觀點大多數(shù)都是錯的。比如業(yè)界很多人講低代碼搞不定復雜的企業(yè)級應用，但都毫無根據(jù)。從技術原理出發(fā)，低代碼其實最適合做的就是企業(yè)應用，即便是CRM、ERP這樣復雜的應用；業(yè)界認為低代碼適合做“簡單的工作流和表單流轉的應用”、“生命周期短的應用”、“創(chuàng)新型應用”等觀點也都是錯的，這些應用很多恰恰不適合低代碼。

• 低代碼不適合做的應用是對算法、界面、性能、分析和智能化等專業(yè)性要求高的應用。

• 低代碼對企業(yè)應用開發(fā)價值明顯，但也不是銀彈，不要過度神化。

對甲方來說，我認為CIO們應該從試點應用做起，通常來說要求自己的團隊用低代碼的阻力會很大，但可以要求乙方用低代碼，降報價。對乙方，我覺得短期很難賣平臺，最好是和甲方談個人力外包模式，避免項目制的僵化。業(yè)界說低代碼是“高級外包”倒也沒說錯，雖然我覺得既然用的是低代碼應該叫“低級外包”更合適??。

最后的最后，我再次呼吁分析機構能夠區(qū)分低代碼和無代碼，聚焦分析面向通用應用開發(fā)的低代碼開發(fā)平臺，促進這個行業(yè)的認知統(tǒng)一，產(chǎn)品的標準化，這樣才能夠推動行業(yè)發(fā)展。

無代碼將死，低代碼長存！