萬字長文講透低代碼 | IDCF

來源：冷技術(shù)熱思考 

作者：風輕揚

• 低代碼和無代碼（也稱零代碼）是什么關(guān)系？
• 怎么判斷一個低代碼平臺是否專業(yè)？
• 國內(nèi)是否有專業(yè)的低代碼平臺？
• 低代碼是不是新瓶裝舊酒？
• 低代碼真的搞不定專業(yè)的企業(yè)應(yīng)用嗎？
• 低代碼不適合開發(fā)哪些應(yīng)用？
• 低代碼并非銀彈。

一、低代碼和無代碼是兩回事

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

低代碼專指低代碼應(yīng)用開發(fā)平臺（LCAP），是一個被業(yè)界廣泛認可的概念，頭部的分析機構(gòu)如Forrester和Gartner都已經(jīng)發(fā)布了多年低代碼開發(fā)平臺的報告。

如下圖所示，大家可以看到這兩家的報告入選的產(chǎn)品都很接近，特別是頭部的六家簡直是一模一樣。這說明低代碼應(yīng)用開發(fā)平臺已經(jīng)是一個比較成熟的市場。

相反，分析機構(gòu)對無代碼的態(tài)度就很微妙了。雖然也有一些分析機構(gòu)也提無代碼開發(fā)平臺的概念，如G2（當然更不用說目前混亂的國內(nèi)分析機構(gòu)），但Forrester和Gartner從未發(fā)布過無代碼開發(fā)平臺的報告。

Forrester和Gartner倒也不是說無代碼是個偽概念，他們的共識是無代碼這個詞只是一個營銷用語，主要用來突出一個工具無需編程基礎(chǔ)，消除業(yè)務(wù)用戶的恐懼。

‘No-code’ is a marketing term, implying the tool is for non-professional developers. 

— By Gartner

(https://appian.com/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.forrester.com/blogs/watch-your-language-low-code-and-no-code-are-not-the-same/)

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

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

我覺得低代碼和無代碼的關(guān)系有點類似于關(guān)系數(shù)據(jù)庫和NoSQL。關(guān)系數(shù)據(jù)庫專指一種特定的數(shù)據(jù)庫，即便多家廠商的產(chǎn)品實現(xiàn)可能千差萬別，但至少提供的功能很相似，都高度遵循SQL標準。

低代碼開發(fā)平臺雖然今天的標準化程度還沒關(guān)系數(shù)據(jù)庫這么高，但無論是Gartner還是Forrester都已經(jīng)開始給出比較清晰的篩選標準，如要支持通用場景（如UI、邏輯和數(shù)據(jù)三層都要有）、要滿足專業(yè)開發(fā)需求等，隨著行業(yè)發(fā)展標準化程度肯定會進一步提高。

NoSQL則只要不是SQL都算，不管你是KV、wide-column、文檔還是圖，都可以叫NoSQL。NoSQL這個詞熱了有幾年，但現(xiàn)在不太講了，因為市場格局開始清晰之后，大家就不會關(guān)注過于寬泛的NoSQL，而是根據(jù)需要關(guān)注具體的類型。

我個人認為無代碼這個詞將來也一樣會慢慢淡出，雖然現(xiàn)在十二個門派很是熱鬧，但不出幾年真正有影響力的門派肯定也不多，這時大家也就不關(guān)注無代碼而是直接找具體的產(chǎn)品了。

本文后續(xù)只專注討論面向通用應(yīng)用開發(fā)的低代碼。低代碼不是一個想吸引業(yè)務(wù)用戶的用語，業(yè)務(wù)人員見了“代碼”兩個字就嚇跑了，再低也沒用，如果業(yè)務(wù)人員寫不了100行代碼的話，那10行也一樣寫不了。

低代碼平臺主要面向?qū)I(yè)開發(fā)，這點已經(jīng)是頭部分析機構(gòu)的共識，雖然Forrester之前走過彎路，曾經(jīng)也發(fā)布過面向業(yè)務(wù)人員的低代碼開發(fā)平臺報告，但近兩年已經(jīng)不再發(fā)布了，只保留面向?qū)I(yè)開發(fā)者的低代碼報告。

用戶數(shù)據(jù)也說明這一點，21CTO在《低代碼開發(fā)可不低，用戶仍需要與IT技術(shù)部門聯(lián)手》一文中提到據(jù)某統(tǒng)計“只有6%的低代碼開發(fā)是由業(yè)務(wù)人員完成的”，OutSystems的數(shù)據(jù)是69%的用戶是專業(yè)開發(fā)，宜創(chuàng)科技CEO宜博也曾說低代碼面臨“懂技術(shù)的看不上，懂業(yè)務(wù)的學(xué)不會”的尷尬。

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

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

二、專業(yè)的低代碼長啥樣

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

（模型驅(qū)動，OutSystems）

（表單驅(qū)動）

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

（怎么拋出和處理異常）

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

2.4 軟件工程

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

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

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

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

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

三、國內(nèi)有專業(yè)的低代碼平臺嗎

四、低代碼真的是新瓶裝舊酒嗎

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

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

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

五、低代碼能開發(fā)復(fù)雜的企業(yè)應(yīng)用嗎

目前業(yè)界很多人認為低代碼搞不定復(fù)雜的企業(yè)應(yīng)用。

如ERP老兵果總在《低代碼，不要以比“中臺”還快的速度臭大街》一文中認為低代碼只適合用來做“簡單的工作流和表單流轉(zhuǎn)的應(yīng)用”或“大型應(yīng)用軟件的功能延伸的開發(fā)”，認為“不適合開發(fā)復(fù)雜邏輯的核心業(yè)務(wù)”。然而果總并沒有說為什么。

“技術(shù)領(lǐng)導(dǎo)力”在《如何用低代碼搞垮一家公司？》一文中認為低代碼只適合“創(chuàng)新探索類”、“生命周期短的”等應(yīng)用。同樣，也沒有給出依據(jù)。

類似的言論還很多，但都有一個共性，就是只說低代碼不行，不解釋，而且很多時候還把話說的那個斬釘截鐵。很多人還真的把自己當回事啊。

企業(yè)應(yīng)用聽起來高大上，但其實幾十年東西了，能有多復(fù)雜呢？界面不用很時尚，不用扛百萬并發(fā)，也沒智能推薦啥的高級算法，其實從軟件開發(fā)角度看企業(yè)應(yīng)用是比較簡單的。

企業(yè)應(yīng)用的復(fù)雜主要是領(lǐng)域模型和業(yè)務(wù)流程比較復(fù)雜，但從前文我們可以看到，低代碼平臺在建模和邏輯方面的能力都是比較全面的，再通過腳本語言、開放集成等擴展機制，對于不方便低代碼實現(xiàn)的地方，可以和專業(yè)代碼開發(fā)協(xié)作實現(xiàn)。所以用低代碼開發(fā)復(fù)雜應(yīng)用，本質(zhì)上沒問題。

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

OutSystems的主任工程師Tiago Sim?es曾介紹過20年來OutSystems的發(fā)展（https://medium.com/outsystems-engineering/whats-not-new-in-outsystems-a-product-timeline-c781acd400cb#），可以看到OutSystems一邊一直補功能，直到2014年的9.0版本支持數(shù)據(jù)聚合處理才算比較完整，另一邊一直在努力追趕技術(shù)趨勢，直到2016年的10.0版本一口氣推出Client-Side Logic、Local Storage、異步、Reactive等功能才算對移動App有較好的支持。這玩意是不做不知道，一做嚇一跳，我們是做了輕舟低代碼才知道這個東西很難。

更重要的可能是非技術(shù)因素。大部分企業(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這類復(fù)雜的企業(yè)應(yīng)用，這一說法很多人講，但都沒有根據(jù)。從技術(shù)原理出發(fā)，低代碼最適合做的恰恰就是企業(yè)應(yīng)用。目前用低代碼做復(fù)雜企業(yè)級應(yīng)用的case還不是很多，是因為低代碼技術(shù)也就剛成熟不久、定制需求還不夠強（套裝軟件能滿足）或者行業(yè)不愿做，并不能說明它做不了。

六、低代碼不適合開發(fā)哪些類型的應(yīng)用

• 對算法和復(fù)雜數(shù)據(jù)結(jié)構(gòu)要求比較高的：我想不會有人想到用低代碼平臺去刷LeetCode題、打ACM比賽的吧。這里有個細微的地方是要區(qū)分是業(yè)務(wù)邏輯比較復(fù)雜還是算法邏輯比較復(fù)雜，業(yè)務(wù)邏輯復(fù)雜對低代碼來說不是問題，算法邏輯復(fù)雜才是問題。那啥叫業(yè)務(wù)邏輯復(fù)雜呢，就是業(yè)務(wù)人員總之是說得清楚，或者是能理解的；啥叫算法邏輯復(fù)雜呢，就是業(yè)務(wù)人員只能給個目標，具體怎么實現(xiàn)是不管的，就算解釋也是一臉悶逼聽不懂的。
• 對界面要求特別高的：比如游戲或抖音、云音樂這樣的社交娛樂型的應(yīng)用。目前主流的低代碼平臺都不擅長做酷炫的界面（也有一些特定類型的低代碼平臺如App Onboard是面向游戲開發(fā)的，不在本文討論范圍之內(nèi)）。
• 頭部互聯(lián)網(wǎng)級應(yīng)用：頭部互聯(lián)網(wǎng)應(yīng)用用戶量巨大，為了優(yōu)化性能有很多很多trick，前后臺技術(shù)架構(gòu)非常復(fù)雜，低代碼平臺的實現(xiàn)是比較標準的數(shù)據(jù)庫 / 邏輯 / 界面三層架構(gòu)，無法滿足性能需求。注意這不是說所有互聯(lián)網(wǎng)應(yīng)用都不合適，只是指那些用戶量特大的頭部應(yīng)用。
• 分析和智能化應(yīng)用：分析類應(yīng)用自然應(yīng)該用更專業(yè)的BI工具，智能化應(yīng)用也應(yīng)該用更專業(yè)的機器學(xué)習(xí)平臺等工具。
• 系統(tǒng)軟件、科學(xué)計算等其他專業(yè)性很強的應(yīng)用。這個不多說了，估計也沒誰想用低代碼來做，但多說一句，雖然這些系統(tǒng)的內(nèi)核肯定不適合低代碼開發(fā)，但界面可是很適合，我們輕舟低代碼產(chǎn)品正是脫胎于云計算平臺的界面開發(fā)。

• 說低代碼適合“簡單的工作流和表單流轉(zhuǎn)的應(yīng)用”：事實上專業(yè)的低代碼并不見得特別適合這類應(yīng)用，比如Gartner就說OutSystems這方面的支持還不太好。其實最適合這類應(yīng)用的反而是那些“表單驅(qū)動”的產(chǎn)品，這些產(chǎn)品并非專業(yè)的低代碼平臺。專業(yè)的低代碼平臺搞這些也不是完全不行，但屬于大炮打蚊子，性價比不高。
• 說低代碼適合“生命周期短的應(yīng)用”：事實上如果你用OutSystems這樣“最專業(yè)”的低代碼平臺去做營銷活動頁這樣“生命周期短的應(yīng)用”，你肯定會欲哭無淚。為什么？因為營銷活動頁對界面的要求很高哎。
• 說低代碼適合“創(chuàng)新型應(yīng)用”：有篇文章按Gartner的方法把應(yīng)用分成基礎(chǔ)設(shè)施型（如 ERP）、差異化型（如 CRM）和創(chuàng)新型應(yīng)用，說前兩類應(yīng)用低代碼就別碰了，都是傳統(tǒng)IT的菜，低代碼就搞搞創(chuàng)新型應(yīng)用，這個說法也不對?；ヂ?lián)網(wǎng)App算典型的創(chuàng)新型應(yīng)用吧，上面已經(jīng)說過這個低代碼搞不定。

七、低代碼不是銀彈，不要過度神化

• 開發(fā)工具只能解決軟件研發(fā)的部分問題。

• 低代碼能提升多少開發(fā)效率缺乏權(quán)威數(shù)據(jù)，不要有太高預(yù)期。
  

• 行業(yè)典型的項目制限制了低代碼的價值。

小結(jié)

最后做個小結(jié)：

• 無代碼和低代碼不是一個層次的概念。低代碼是以O(shè)utSystems、Mendix等產(chǎn)品為代表，主要面向?qū)I(yè)開發(fā)的通用應(yīng)用開發(fā)平臺；無代碼則是一個營銷用語，用于形容很多種面向業(yè)務(wù)人員的工具，如應(yīng)用搭建、在線表單、工作流等。不存在無代碼的通用應(yīng)用開發(fā)平臺。無代碼這個概念過于寬泛，未來很可能會慢慢淡出市場。
• 要判斷一個低代碼平臺是否專業(yè)，可以重點看模型驅(qū)動、可視化開發(fā)、表達式語言、軟件工程、開放集成和腳本語言等六個方面。對照這些標準，不難看出迄今為止應(yīng)該說國內(nèi)還很少有專業(yè)的低代碼平臺，雖然輿論甚是喧囂。
• 業(yè)界關(guān)于低代碼適用場景的觀點大多數(shù)都是錯的。比如業(yè)界很多人講低代碼搞不定復(fù)雜的企業(yè)級應(yīng)用，但都毫無根據(jù)。從技術(shù)原理出發(fā)，低代碼其實最適合做的就是企業(yè)應(yīng)用，即便是CRM、ERP這樣復(fù)雜的應(yīng)用；業(yè)界認為低代碼適合做“簡單的工作流和表單流轉(zhuǎn)的應(yīng)用”、“生命周期短的應(yīng)用”、“創(chuàng)新型應(yīng)用”等觀點也都是錯的，這些應(yīng)用很多恰恰不適合低代碼。
• 低代碼不適合做的應(yīng)用是對算法、界面、性能、分析和智能化等專業(yè)性要求高的應(yīng)用。
• 低代碼對企業(yè)應(yīng)用開發(fā)價值明顯，但也不是銀彈，不要過度神化。

對甲方來說，我認為CIO們應(yīng)該從試點應(yīng)用做起，通常來說要求自己的團隊用低代碼的阻力會很大，但可以要求乙方用低代碼，降報價。

對乙方，我覺得短期很難賣平臺，最好是和甲方談個人力外包模式，避免項目制的僵化。業(yè)界說低代碼是“高級外包”倒也沒說錯，雖然我覺得既然用的是低代碼應(yīng)該叫“低級外包”更合適??。

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

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