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

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

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

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

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

04

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

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

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

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

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

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

貼兩張老圖讓大家感受一下當(dāng)年炸子雞—Delphi,。

點(diǎn)擊加載圖片

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

點(diǎn)擊加載圖片

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

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

我想說低代碼是新瓶裝舊酒的人啊,，看到特斯拉也會說新瓶裝舊酒，不還是汽車嗎,，看到iPhone也會說新瓶裝舊酒,，不就是個手機(jī)嗎，我就打打電話,，發(fā)發(fā)短信,。這些人啊，可能也不因?yàn)閯e的,，可能就是因?yàn)槟昙o(jì)太大了,。

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

05

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

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

很多人還真的把自己當(dāng)回事啊,。

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

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

而且用低代碼平臺開發(fā)這類應(yīng)用，還有不少獨(dú)特優(yōu)勢,，如開發(fā)人員上手快（我們的經(jīng)驗(yàn)是個把月就能用的很溜了）,，開發(fā)效率高,，便于業(yè)務(wù)人員和開發(fā)之間的溝通（因?yàn)檫壿嫶蠖嗍强梢暬模蝗菀仔纬晒聧u（因?yàn)閷I(yè)的低代碼平臺默認(rèn)就會根據(jù)模型生成API）,。OutSystems在其網(wǎng)站上特意強(qiáng)調(diào)：

OutSystemsiswell-equippedtobuildERPandsimilarlarge,complexsystemswiththedesiredperformanceandscalability.

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

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

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

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

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

06

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

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

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

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

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

頭部互聯(lián)網(wǎng)級應(yīng)用：頭部互聯(lián)網(wǎng)應(yīng)用用戶量巨大，為了優(yōu)化性能有很多很多trick,，前后臺技術(shù)架構(gòu)非常復(fù)雜,，低代碼平臺的實(shí)現(xiàn)是比較標(biāo)準(zhǔ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è)的機(jī)器學(xué)習(xí)平臺等工具,。

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

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

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

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

說低代碼適合“創(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)說過這個低代碼搞不定。

07

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

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

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

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

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

08

小結(jié)

最后做個小結(jié)：

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

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

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

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

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

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

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

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

(未完待續(xù),，還有一個很有意思的話題沒講,，就是程序員要不要怕被低代碼搶飯碗，找時間再慢慢寫）