無代碼將死，低代碼長存
作者 | 汪源
來源 | 授權轉載自微信公衆號“冷技術熱思考”，經過不改變原意的刪改
業界說低代碼是“高級外包”倒也沒說錯，雖然我覺得既然用的是低代碼應該叫“低級外包”更合適。
低代碼這個概念今年極火，爭議也極大。有些人力捧，覺得以後“人人都是程序員”，也有不少人嗤之以鼻，還有很多人認爲低代碼是新瓶裝舊酒，早已有之，或者無非就是個高級外包。
本文希望對這個當前動盪不安的領域做一點“不草就”的綜合說明，想說清楚七大問題：低代碼和無代碼（也稱零代碼）是什麼關係、怎麼判斷一個低代碼平臺是否專業、國內是否有專業的低代碼平臺、低代碼是不是新瓶裝舊酒、低代碼真的搞不定專業的企業應用嗎、低代碼不適合開發哪些應用、低代碼是不是銀彈。
本文對低代碼相關的很多迷信和錯誤觀點都做了比較客觀的分析，希望能對促進這個行業的正確認知有幫助。
低代碼和無代碼是兩回事
第一步得把低代碼和無代碼分清楚，因爲這倆差異巨大，但現在業界經常混爲一談，導致很多很多問題，比如雙方爭論但指的不是同一個事情，廠商的口徑亂，行業報告的結果不能看。
低代碼專指低代碼應用開發平臺（LCAP），是一個被業界廣泛認可的概念，頭部的分析機構如 Forrester 和 Gartner 都已經發布了多年低代碼開發平臺的報告。如下圖所示，大家可以看到這兩家的報告入選的產品都很接近，特別是頭部的六家簡直是一模一樣。這說明低代碼應用開發平臺已經是一個比較成熟的市場。
相反，分析機構對無代碼的態度就很微妙了。雖然也有一些分析機構提無代碼開發平臺的概念，如 G2（當然更不用說目前混亂的國內分析機構），但 Forrester 和 Gartner 從未發佈過無代碼開發平臺的報告。Forrester 和 Gartner 倒也不是說無代碼是個僞概念，他們的共識是無代碼這個詞只是一個營銷用語，主要用來突出一個工具無需編程基礎，消除業務用戶的恐懼。
無代碼這個詞通常用來形容一些細分領域的開發工具，最常見的是應用搭建平臺（國外一般叫 App Builder 之類），如國外的 Appy Pie、國內的宜搭、簡道雲等，還可以用來形容 Airtable / AppSheet 這類在線表單工具或輕流這類的工作流工具。這幾類工具差別巨大，由此可見無代碼是一個相當寬泛的概念。如下圖所示，甚至還有人將無代碼和低代碼的江湖分成十二個“門派”。
（來源： https://pinver.medium.com/decoding-the-no-code-low-code-startup-universe-and-its-players-4b5e0221d58b ）
但無代碼的“通用”開發平臺，目前看並不存在。據我看將來也不會存在，因爲開發軟件必然要編寫邏輯，就必然要寫代碼，除非哪一天人工智能能做到自動寫代碼。
我覺得低代碼和無代碼的關係有點類似於關係數據庫和 NoSQL。關係數據庫專指一種特定的數據庫，即便多家廠商的產品實現可能千差萬別，但至少提供的功能很相似，都高度遵循 SQL 標準。低代碼開發平臺雖然今天的標準化程度還沒關係數據庫這麼高，但無論是 Gartner 還是 Forrester 都已經開始給出比較清晰的篩選標準，如要支持通用場景（如 UI、邏輯和數據三層都要有）、要滿足專業開發需求等，隨着行業發展標準化程度肯定會進一步提高。NoSQL 則只要不是 SQL 都算，不管你是 KV、wide-column、文檔還是圖，都可以叫 NoSQL。NoSQL 這個詞熱了有幾年，但現在不太講了，因爲市場格局開始清晰之後，大家就不會關注過於寬泛的 NoSQL，而是根據需要關注具體的類型。我個人認爲無代碼這個詞將來也一樣會慢慢淡出，雖然現在十二個門派很是熱鬧，但不出幾年真正有影響力的門派肯定也不多，這時大家也就不關注無代碼而是直接找具體的產品了。
本文後續只專注討論面向通用應用開發的低代碼。低代碼不是一個想吸引業務用戶的用語，業務人員見了“代碼”兩個字就嚇跑了，再低也沒用，如果業務人員寫不了 100 行代碼的話，那 10 行也一樣寫不了。低代碼平臺主要面向專業開發者，這點已經是頭部分析機構的共識，雖然 Forrester 之前走過彎路，曾經也發佈過面向業務人員的低代碼開發平臺報告，但近兩年已經不再發布了，只保留面向專業開發者的低代碼報告。用戶數據也說明這一點，據 Creatio 調查統計，“只有 6% 的低代碼開發是由業務人員完成的”，而 OutSystems 的數據是 69% 的用戶是專業開發，宜創科技 CEO 宜博也曾說低代碼面臨“懂技術的看不上，懂業務的學不會”的尷尬。
所以無代碼和低代碼完全不同，無代碼面向業務人員，低代碼面向開發人員；無代碼泛指多種開發細分領域應用的工具，低代碼特指一種通用開發工具；無代碼不被國際頭部分析機構認可，低代碼被廣泛認可。
現在國內很多行業專家和分析機構經常把兩者混爲一談，這對技術的價值衡量、甲方的技術規劃和選型都造成很大混亂，我迫切希望大家能夠把低代碼和無代碼區分開，集中研究具備通用能力的低代碼平臺。
專業的低代碼長啥樣
現在市場上魚龍混雜號稱“低代碼”的產品很多，怎麼才能快速區分是不是“專業”？很簡單，找一個最專業的產品來對標。
哪個產品纔是最專業的？我們可以先看看爲什麼低代碼這兩三年才熱起來？不是因爲 Salesforce 這樣的 SaaS 廠商，也不是 Appian 這類 BPMS 廠商，這輪低代碼熱其實主要是因爲 OutSystems。OutSystems 雖然也早在 2001 年就成立，但之前一直“猥瑣發育”，2018 年 D 融資了 $3.6 億，才突然引爆市場。無論 Forrester 還是 Gartner 都把 OutSystems 列入領導者象限，所以，OutSystems 就是專業低代碼平臺的代表。
對比 OutSystems 和很多國內所謂的低代碼平臺，我找出了六項區分度最高的判斷標準：模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言。
（1）模型驅動
“模型驅動”可能是最明顯的區分標誌，因爲剛好有一個也很流行的概念叫“表單驅動”。很多人搞不清楚這兩個概念，但其實這兩類產品挺好區分。
首先可以看用戶手冊，這樣不用安裝試用也能看出差別。使用模型驅動的平臺比如 OutSystems、Mendix 的手冊會有很大一章講怎麼做數據建模和處理，包括怎麼定義實體、實體間關係、主鍵、唯一性、索引、數據怎麼訪問、篩選、分組、統計等等，還提供 SQL 或類似擴展。使用表單驅動的產品則往往手冊第一章就是說明怎麼定義各種表單，都是各種和界面相關的控件，比如單選多選下拉框、文本日期數字等。
其次可以看界面。下圖是分別是模型驅動的 OutSystems 和某表單驅動產品的相關操作界面，大家看是不是很不一樣。
（模型驅動，OutSystems）
（表單驅動）
（2）可視化開發
可視化開發不是拖拉拽做個界面（這隻能叫可視化設計），而是要拖拉拽寫處理邏輯。看 OutSystems 這類產品的文檔，你會發現很多編程語言的基本構造都有，比如順序 / 分支 / 循環 / continue / break、輸入輸出參數、局部變量 / 全局變量、struct 和 list、異常等。雖然這些東西都是拖拉拽完成，看上去沒有密密麻麻的一行行代碼來嚇人，但也足以嚇退業務人員。一下幾張圖都來自於 OutSystems，大家可以感受一下。
（左：邏輯開發工具箱，注意有 If、Switch、For Each 流程控制；右：一個比較簡單的邏輯）
（怎麼拋出和處理異常）
（3）表達式語言
表達式語言有些類似 Excel 裡的公式，有表達式語言纔可以做一些比較複雜的計算。下圖是 OutSystems 的表達式編輯器，大家可以看到有各種操作符，還有很多內置函數，比如數學函數、字符串處理函數等。
OutSystems 這個例子看起來還比較簡單，但表達式語言也可以很複雜。微軟是搞語言的行家，下圖是個微軟 Power Fx 的例子，這個表達式是要提取一個句子最後一個單詞的表達式，也挺複雜吧（說實話我看了好大一陣子纔看懂）。
表達式語言也有更平易近人的設計，比如我們輕舟就是用類似 Scratch 的積木塊設計。兩種設計功能上是等價的，積木塊設計更容易上手，Power Fx 這樣的設計寫複雜表達式更方便。
（4）軟件工程
專業的低代碼平臺需要提供測試、debug、版本控制等軟件工程支持。開發軟件都會出 bug（低代碼平臺基本消除了語法層面的 bug，但對語義層面的 bug 一樣無能爲力），需求也總是會變。所以測試、debug、版本控制這些支持也是必不可少的。OutSystems 爲什麼做的最好，我覺得跟它完善的 debug 支持是分不開的。下圖是 OutSystems 的 debug 界面，看起來和專業 IDE 有的一拼。
（5）開放集成
理論上，有了模型驅動等上述四大功能，開發一個不是太複雜的獨立應用就夠了，但典型的企業軟件都是相互依賴和集成的，所以平臺還需要具備能夠調用外部 API 和開放 API 給別人的能力。平臺如果沒有這兩方面的功能，開發出來的應用相互之間都沒法連通和集成，全是技術債。我們看國外關於低代碼的文章，經常會看到一個詞叫 Shadow IT，說的就是這個問題。大家都胡亂的開發各種應用，還都集成不起來，將是一場大災難。
（6）腳本語言
腳本語言就是用 JavaScripts、Python、Java 等做擴展，這些其實就是正兒八經的專業編程語言了，但低代碼平臺會把工程複雜性都封裝好，讓開發者不需要配置部署環境，隨手就可以寫代碼，寫完一鍵發佈馬上可以運行。
其實上述標準和 Gartner 是很一致的。Gartner 在魔力象限報告裡說：
裡面模型驅動、可視化開發、表達式語言、腳本語言都提到了。
小結一下，判斷是不是"專業”的代碼，可以重點看模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言等六個方面。
國內有專業的低代碼平臺嗎？
國內看似已經有很多低代碼平臺，道一雲之前做過一個系列測評，T 研究、海比等也都出過分析報告，但只要我們對照上述標準就不難看出，雖然低代碼輿論很是喧囂，但迄今爲止應該說國內還很少有專業的低代碼平臺。
比如國內存在一類平臺叫“應用搭建平臺”，這些平臺有些標稱無代碼，有些標稱低代碼，但即便某些廠商標稱的是低代碼，其實基本上是採取“表單驅動”的設計。“搭建”和“開發”二字之差，差距其實非常大。應用“搭建”平臺這個概念，在 Gartner 這樣的國際頂級分析機構的字典裡是沒有的，和“開發”平臺不在一個量級。所以，大家如果看到“搭建”平臺，要特別留意，即便標稱是低代碼的，也好仔細的對照標準去評估一下，一般按前一節的標準，這些平臺是夠不上的。
國內分析報告提及的產品我都瞄過很多，但看一圈下來，個人認爲八成都夠不上專業低代碼開發平臺的門檻，目前我比較瞭解的也就 ClickPaaS 和 iVX 可能還夠得上（我也不確定，因爲 ClickPaaS 不開放用戶手冊，沒深入研究），畢竟它有模型驅動和開放集成。
這麼混亂的狀態讓我們的 CIO 們可怎麼辦呢，這再次說明如果缺乏有效的標準篩選真正專業的低代碼平臺，勢必低代碼和無代碼一鍋粥，結果大家都被搞得稀裡糊塗。
低代碼真的是新瓶裝舊酒嗎？
關於低代碼還有一種流行的觀點是新瓶裝舊酒，說二十年多年前的 Delphi、PowerBuilder（後稱 PB）早就是低代碼，但早就被時代淘汰了，今天的低代碼也沒戲。說這些話的大概率還是前輩。
要講清楚這些問題得稍微 digg 一點歷史，當年的 Delphi 和 PB 可是神一般的存在，因爲相比同時代的其他技術（比如詰屈聱牙的 MFC）來說易用性好太多，這倆不知道做了不知道多少企業信息化應用。隨手翻看一本《Delphi 開發典型模塊大全》，裡面盡是板材排料、進銷存、文檔管理、批發零售、房地產信息管理等案例。
這倆後來被時代淘汰，主要是因爲時代變了，沒跟上。互聯網時代來了後，軟件架構很快就從桌面端的 C / S 變成 Web 端的 B / S，再後來是移動 App。Web 應用和 App 對前後端的要求比桌面應用都要高很多，因爲大家做網頁或 App 都是要勾引用戶主動來訪問啊，不像桌面端的企業應用就算不好用你爲了工作也得用。互聯網的這個二十年，技術棧發展的越來越複雜，新的低代碼技術只能一直慢慢醞釀。
但經過 OutSystems 等廠商經過十多年的積累，今天的低代碼技術已經遠勝當年的 Delphi 和 PB。今天的低代碼要“低”的多，當年的 Delphi、PB 等如果按今天的標準，連入門的資格都沒有。
我們就以當年最流行的 Delphi 爲例，Delphi 雖然號稱“可視化編程語言”，但也就是實現了界面的可視化開發和數據庫的 ORM，所有的邏輯都是要用代碼寫的，包括怎麼把數據顯示在表格也都要寫代碼。我們說的六大標準裡，頭兩位的模型驅動、可視化開發這些都沒有。PB 也就比 Delphi 稍好一點，它核心的 DataWindow 可以無需代碼做出增刪改查，算是邁入模型驅動的門檻，但它不支持實體關係，模型驅動能力並不完整。同時 PowerBuilder 也沒有可視化的邏輯開發，按今天的標準也只能在門檻徘徊。
貼兩張老圖讓大家感受一下當年炸子雞—Delphi。
（Delphi 的主界面，實現了用戶界面的可視化設計）
（Delphi 的邏輯實現界面，得寫代碼）
士別三日當刮目相看，何況十多年。今天的低代碼並不是新瓶裝舊酒，而是新瓶新酒，裡外都是新的。說新瓶是因爲低代碼這個概念是新的，說新酒是因爲今日的 OutSystems 等專業低代碼產品的能力已經遠超二十年前 PC 時代的 Delphi 和 PB。
我想說低代碼是新瓶裝舊酒的人啊，看到特斯拉也會說新瓶裝舊酒，不還是汽車嗎，看到 iPhone 也會說新瓶裝舊酒，不就是個手機嗎，我就打打電話，發發短信。這些人啊，可能也不因爲別的，可能就是因爲年紀太大了。
關於低代碼從 DOS 時代至今的發展脈絡，阿朱在一文有詳細介紹，感興趣的可以看看。
低代碼能開發複雜的企業應用嗎？
目前業界很多人認爲低代碼搞不定複雜的企業應用。有人認爲低代碼只適合用來做“簡單的工作流和表單流轉的應用”或“大型應用軟件的功能延伸的開發”，而“不適合開發複雜邏輯的核心業務”，但並沒有說爲什麼。也有人認爲低代碼只適合“創新探索類”、“生命週期短的”等應用，但同樣沒有給出依據。類似的言論還很多，但都有一個共性，就是隻說低代碼不行，不解釋，而且很多時候還把話說得斬釘截鐵。
企業應用聽起來高大上，但其實幾十年東西了，能有多複雜呢？界面不用很時尚，不用扛百萬併發，也沒智能推薦啥的高級算法，其實從軟件開發角度看企業應用是比較簡單的。企業應用複雜主要是領域模型和業務流程比較複雜，但從前文我們可以看到，低代碼平臺在建模和邏輯方面的能力都是比較全面的，再通過腳本語言、開放集成等擴展機制，對於不方便低代碼實現的地方，可以和專業代碼開發協作實現。所以用低代碼開發複雜應用，本質上沒問題。
曾有文章把企業應用的複雜性分解爲數據、權限、流程、算法、集成、報表等六個維度，然後逐一給出解決方案。這纔是實事求是的態度。我相信任何人但凡不帶偏見，深入分析的，都會發現企業應用並沒有什麼複雜性是低代碼一定搞不定的。
而且用低代碼平臺開發這類應用，還有不少獨特優勢，如開發人員上手快（我們的經驗是個把月就能用的很溜了），開發效率高，便於業務人員和開發之間的溝通（因爲邏輯大多是可視化的），不容易形成孤島（因爲專業的低代碼平臺默認就會根據模型生成 API）。OutSystems 在其網站上特意強調：
OutSystems 也有一些這方面的案例，做供應鏈、CRM、ERP 的都有。OutSystems 成立於 2001 年，那時候不開發企業應用開發什麼呢？
但可能很多人會說，OutSystems 作爲廠商當然這麼宣揚，但目前用低代碼開發複雜企業應用確實不多啊。沒錯，但我認爲這只是時間問題。
首先，低代碼技術達到成熟狀態的時間並不長，即便是 OutSystems。OutSystems 雖然都成立 20 年了，但低代碼表面看似簡單，其實是一個相當複雜的技術體系，背後涉及核心的編程語言層面的設計，比如 DSL、類型系統、泛型等等，還有怎麼 diff、debug、undo，都不容易。另外低代碼平臺還需要不斷追趕這 20 年變化極大的技術環境。20 年前是 C / S、.Net，後來流行 B / S、Java，再後來又得搞 App，操作系統從 Windows 變成 Linux，現在又面臨從 SOA 到微服務的轉型。
OutSystems 的主任工程師 Tiago Simões 曾介紹過 20 年來 OutSystems 的發展（https://medium.com/outsystems-engineering/whats-not-new-in-outsystems-a-product-timeline-c781acd400cb#），可以看到 OutSystems 一邊一直到補功能，直到 2014 年的 9.0 版本支持數據聚合處理纔算比較完整，另一邊一直在努力追趕技術趨勢，直到 2016 年的 10.0 版本一口氣推出 Client-Side Logic、Local Storage、異步、Reactive 等功能纔算對移動 App 有較好的支持。這玩意是不做不知道，一做嚇一跳，我們是做了輕舟的代碼才知道這個東西很難。
更重要的可能是非技術因素。大部分企業對 CRM、ERP 的定製需求還沒那麼高，相比用低代碼從頭開發來說，採用 Saleforce、SAP 這樣的套裝軟件實施，再做一些二次開發是更合適的選擇。這也解釋了爲什麼 Saleforce、ServiceNow 這樣的 SaaS 巨頭都有自己的低代碼平臺，而西門子會收購 Mendix。另外 ERP 這樣的企業軟件實施強度依賴諮詢經驗，這不是低代碼能解決的，而業界有經驗的諮詢顧問顯然更熟悉 SAP 這樣的產品，也沒有意願改變。專業程序員對低代碼牴觸也非常大，好不容易練就一身武藝，用了低代碼好像都沒用了？業界越是宣傳用低代碼開發快多少倍，開發團隊可能越牴觸。
總之，業界流行說低代碼不能做 CRM、ERP 這類複雜的企業應用，這一說法很多人講，但都沒有根據。從技術原理出發，低代碼最適合做的恰恰就是企業應用。目前用低代碼做複雜企業級應用的 case 還不是很多，是因爲低代碼技術也就剛成熟不久、定製需求還不夠強（套裝軟件能滿足）或者行業不願做，並不能說明它做不了。
低代碼不適合開發哪些類型的應用
很多專家啊，不但錯誤的認爲低代碼搞不定複雜企業應用，還在低代碼適合哪些類型的應用上也說錯了。
主流低代碼平臺真正不太擅長的，是那些有各種特殊要求的應用，比如：
對算法和複雜數據結構要求比較高的：我想不會有人想到用低代碼平臺去刷 LeetCode 題、打 ACM 比賽的吧。這裡有個細微的地方是要區分是業務邏輯比較複雜還是算法邏輯比較複雜，業務邏輯複雜對低代碼來說不是問題，算法邏輯複雜纔是問題。那啥叫業務邏輯複雜呢，就是業務人員總是說的清楚，或者是能理解的；啥叫算法邏輯複雜呢，就是業務人員只能給個目標，具體怎麼實現是不管的，就算解釋也是一臉懵逼的聽不懂的。
對界面要求特別高的：比如遊戲或抖音、雲音樂這樣的社交娛樂型的應用。低代碼平臺可不擅長做酷炫的界面。（也有一些特定類型的低代碼平臺如 App Onboard 是面向遊戲開發的，iVX 前端能力比較強，但都比較小衆，不在本文討論範圍之內）
頭部互聯網級應用：頭部互聯網應用用戶量巨大，爲了優化性能有很多很多 trick，前後臺技術架構非常複雜，低代碼平臺的實現是比較標準的數據庫 / 邏輯 / 界面三層架構，無法滿足性能需求。注意這不是說所有互聯網應用都不合適，只是指那些用戶量特大的頭部應用。
分析和智能化應用：分析類應用自然應該用更專業的 BI 工具，智能化應用也應該用更專業的機器學習平臺等工具。
系統軟件、科學計算等其他專業性很強的應用。這個不多說了，估計也沒誰想用低代碼來做，但多說一句，雖然這些系統的內核肯定不適合低代碼開發，但界面可是很適合，我們輕舟低代碼產品正是脫胎於雲計算平臺的界面開發。
現在大家應該可以發現很多業界流行的觀點說低代碼適合這個那個的其實也都是錯的，比如：
說低代碼適合“簡單的工作流和表單流轉的應用”：事實上專業的低代碼並不見得特別適合這類應用，比如 Gartner 就說 OutSystems 這方面的支持還不太好。其實最適合這類應用的反而是那些“表單驅動”的產品，這些產品並非專業的低代碼平臺。專業的低代碼平臺搞這些也不是完全不行，但屬於大炮打蚊子，性價比不高。
說低代碼適合“生命週期短的應用”：事實上如果你用 OutSystems 這樣“最專業”的低代碼平臺去做營銷活動頁這樣“生命週期短的應用”，你肯定會欲哭無淚。爲什麼？因爲營銷活動頁對界面的要求很高。
說低代碼適合“創新型應用”：有篇文章按 Gartner 的方法把應用分成基礎設施型（如 ERP）、差異化型（如 CRM）和創新型應用，說前兩類應用低代碼就別碰了，都是傳統 IT 的菜，低代碼就搞搞創新型應用，這個說法也不對。互聯網 App 算典型的創新型應用吧，上面已經說過這個低代碼搞不定。
低代碼不是銀彈，不要過度神化
上面我們說低代碼很適合開發典型的企業應用，優點明顯，如開發人員上手快、開發效率高、增進溝通和集成等，但也不要認爲低代碼是銀彈，用了什麼問題都解決了。原因主要有以下三個方面。
1）開發工具只能解決軟件研發的部分問題。作爲開發工具，低代碼可以加快在需求比較明確時的軟件交付，也可以在大方向比較明確但具體需求不明時加快軟件的迭代更新。但企業應用和企業的經營管理方式、業務方向、業務流程、組織架構密切相關，和人密切相關，這些方面如果有問題，軟件都不知道怎麼做，這都不是開發工具所能解決，該請諮詢還是得請諮詢。低代碼就像特種兵，當兵作戰能力是強，但如果將帥不行，戰略戰術拉垮，也打不了勝戰。
2）低代碼能提升多少開發效率缺乏權威數據，不要有太高預期。業界有很多對低代碼開發效率的宣傳，最多的是說什麼提升 10 倍啦，這些一看就是胡扯。一些廠商和分析機構會發布提效數據，看似效果特別好，但因爲前面說的無代碼和低代碼沒分清，這些數據不可信。無代碼工具因爲都是面向特定類型的應用高度優化的，提效明顯很正常的，但不通用。專業的低代碼廠商如 OutSystems、Mendix，反而不敢宣傳提效多少倍，所以一個廠商宣傳的效果越好，就越不可能是專業的低代碼平臺。從我們的經驗看，用低代碼做一些小系統確實挺快，但上了規模後還能是不是有數倍提升，我覺得也不大可能。
3）行業典型的項目制限制了低代碼的價值。低代碼平臺因爲可視化、效率高，最適合業務和開發密切溝通合作，快速迭代。但當前甲乙方之間典型的項目制要求雙方提前簽訂詳細的合同和 SOW，這就把本來可以敏捷開發的生生打回到瀑布模式，這樣低代碼快速迭代的價值就很難體現。項目制存在太久，不是一時半會改的了的。
小結
最後做個小結：
無代碼和低代碼不是一個層次的概念。低代碼是以 OutSystems、Mendix 等產品爲代表，主要面向專業開發的通用應用開發平臺；無代碼則是一個營銷用語，用於形容很多種面向業務人員的工具，如應用搭建、在線表單、工作流等。不存在無代碼的通用應用開發平臺。
要判斷一個低代碼平臺是否專業，可以重點看模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言等六個方面。對照這些標準，不難看出迄今爲止應該說國內還很少有專業的低代碼平臺，雖然輿論甚是喧囂。
業界關於低代碼適用場景的觀點大多數都是錯的。比如業界很多人講低代碼搞不定複雜的企業級應用，但都毫無根據。從技術原理出發，低代碼其實最適合做的就是企業應用，即便是 CRM、ERP 這樣複雜的應用；業界認爲低代碼適合做“簡單的工作流和表單流轉的應用”、“生命週期短的應用”、“創新型應用”等觀點也都是錯的，這些應用很多恰恰不適合低代碼。
低代碼不適合做的應用是對算法、界面、性能、分析和智能化等專業性要求高的應用。
低代碼對企業應用開發價值明顯，但也不是銀彈，不要過度神化。
對甲方來說，我認爲 CIO 們應該從試點應用做起，通常來說要求自己的團隊用低代碼的阻力會很大，但可以要求乙方用低代碼，降報價。對乙方，我覺得短期很難賣平臺，最好是和甲方談個人力外包模式，避免項目制的僵化。業界說低代碼是“高級外包”倒也沒說錯，雖然我覺得既然用的是低代碼應該叫“低級外包”更合適。
最後的最後，我再次呼籲分析機構能夠區分低代碼和無代碼，聚焦分析面向通用應用開發的低代碼開發平臺，讓產出的報告具備參考價值。
作者介紹：
汪源，本站副總裁、本站杭研院執行院長、本站數帆總經理，互聯網技術委員會主席。2006 年獲浙江大學計算機專業博士學位，是國內大型通用關係數據庫內核技術最早的實踐者之一。畢業後加入本站，長期主持本站杭州研究院技術研究工作，在國內最早開展分佈式數據庫、文件系統、搜索等大數據系統建設。現作爲本站杭州研究院執行院長，全面負責本站集團基礎設施 / 雲原生 / 中間件 / 大數據 / 人工智能 / 信息安全 / 中臺等核心技術平臺建設、項目管理 / 用戶體驗與設計 / 運維保障 / 質量保障 / 創新服務等創新平臺建設和本站數帆基礎軟件業務。
本週好文推薦
活動推薦
產品創新的價值在於創造性的解決用戶問題，達成公司的商業目標、創造商業價值。那麼產品創新的方式有哪些？實踐路徑有哪些呢？8 月 20-21 日，PCon 全球產品創新大會和良倉孵化器創始合夥人、《人人都是產品經理》作者蘇傑一起聊一聊產品創新背後的故事。點擊底部【閱讀原文】查看專題詳情。
直面產品創新瓶頸，提升產品思維。大會門票限時優惠中～諮詢票務小姐姐瞭解優惠詳情：17310043226。