本期訪談嘉賓：寧偉，CSDN知名博主。葡萄城產品市場總監，2005年加入葡萄城，從事.NET平臺軟件開發和項目管理工作，2018年起專注于活字格低代碼平臺的市場運營與推廣。

嘉賓照片：

 談國內外低代碼平臺產品的發展脈絡

CSDN: 您怎么看待2019年這個時間點？低代碼目前真實的現狀是怎樣的？ 

嘉賓：事實上2014年開始，一些傳統的軟件開發工具廠商或者說主流的ToB風格的玩家已經紛紛入場研究低代碼了。葡萄城2012年啟動活字格的研究和開發，2016年就發布了活字格低代碼開發平臺。從一些行業研究機構的報告上看，現在市面上活躍的低代碼平臺廠商，除了一些互聯網巨頭在2019年入場之外，幾乎全都是2015年到2019年這段時間就已經入場開始產品布局的。也就是說低代碼，從2014年Forrester發布了低代碼的概念之后就一直存在了。

但是，2019年開始到今年，隨著風險投資的進場，這個概念突然之間爆火起來。是資本催生了低代碼的火爆，它的產品定義邊界也一直在演進。現在這個時間點在探討低代碼這個問題的時候，就需要去分時間階段的去看了。但整體上來講，在2019年風口起來之前就在入場的玩家，事實上是構成了目前中國低代碼行業的主力。

CSDN：目前要想定義清楚什么是低代碼，需要先為低代碼分類，國內外的低代碼平臺產品，他們的用戶群，產品定位其實都不盡相同，縱觀國內外的低代碼廠商，目前比較清晰的分類有哪些？

嘉賓：剛才我們聊了國內的大概情況，那么國外的其實也是有一些比較有意思的事情。低代碼概念在國外火起來，也是來自資本的助力。2018年Outsystems拿了3.6億美元的投資，估值達到超十億美金這種量級的，是當年的獨角獸。Outsystems是一家在葡萄牙的公司，總部在里斯本，開發團隊大概兩三百人。因為Outsystemss也是葡萄城開發控件的客戶，我們對這家公司的了解也比較深一些。他的發展歷程也可以幫助我們了解歐美在低代碼方面的發展歷程。

服務專業開發者的低代碼平臺：

以Outsystems為代表的國外主流低代碼開發平臺，它的產品開發工具的屬性，相比國內很多產品會更加純粹一些。舉個例子，Outsystems起步時，它所面對的用戶群體就是專業開發者。它的產品幾乎所有的設計全都采用了現有的軟件開發體系，包括模型驅動、前后端分離、包括構建外部API，以及調用第三方接口的做法等。包括在部署階段，整個流程都是按照一個專業開發者的專業開發工具的標準去做的。即便是部署也是私有化部署為主，在他的云端所采用的方式，跟很多人想的云端部署也不太一樣。

通常意義上講的云服務，SaaS服務一般情況下來講叫共享資源，是多租戶模式。也就是大家很多人去共享同一個云主機，用同樣一套資源來實現，通過錯峰使用時間，來實現資源的高效利用，這是云基本的底層邏輯，但是Outsystems在做這件事情的時候不一樣。

他們提供了獨占式的云服務模式。簡單理解就是說Outsystems的云上部署，后臺相當于給你創建了獨立的屬于你的一臺虛擬機。資源是獨占的，不會出現資源爭搶。當然這樣子來做，對于云服務商來講，它的成本是很高的。但當客戶把核心系統或者業務系統用低代碼的方式開發部署后，考慮到對處理能力和可用性的高要求，是更加希望它能夠獨享資源部署的。

這種服務于企業核心業務的底層邏輯并不是Outsystems的專利，國外的Mendix和國內的活字格、ClickPaaS等都是這個賽道下的典型玩家。只是有些廠商更偏重于提升產品作為開發工具的技術能力，將低代碼平臺作為一個獨立的產品進行銷售；另一些廠商投入更大的力量在自己組建實施團隊為客戶做交付而已。本質上，這些都是面向專業開發者的低代碼平臺。

需要注意的是，這里的專業開發者和程序員其實不完全劃等號。按照Gartner關于平民開發者和專業開發者的劃分，凡是向IT部門匯報的開發者都是專業開發者，而向業務部門匯報的開發者則是平民開發者。兩者的差異主要體現在工作職責和崗位劃分，而不是技術能力。所以，不管是Outsystems還是活字格，使用者中都不乏在企業IT部門中從事低代碼開發的初級技術人員，這些人與程序員配合，前者負責簡單的增刪改查和頁面設計，后者則更關注系統架構、數據庫設計以及編程擴展等高技術含量的部分。

輕應用場景的低代碼平臺：

據我對國內市場的了解，面向專業開發者的低代碼平臺在體量上并不占優勢。在資本的牽引下，國內的大多數低代碼平臺在向互聯網輕應用場景的平臺模式發展，從應用場景到技術路線，和前面提到的面向專業開發者的低代碼平臺存在很大的差異。

輕應用場景，在企業中它并不是核心業務場景。比如在生產制造型企業，一個輕應用場景舉個例子，比如做一張廠商宣傳海報，做一個疫情流調的填報等等，能夠快速上線，讓大家來填寫提交的。以此為例，工廠比如說有1000個人，1000個人就都是低代碼開發平臺最終輻射到的用戶群體。

而另外一個方面，軟件公司或者企業IT部門使用面向專業開發者的低代碼平臺，來實現核心系統應用，比如生產系統，庫存系統。料庫和成品庫之間庫存流轉，然后做財務的成本核算，業務財務一體化結算等等，這些核心業務的話，那它的使用群體的用戶數量，其實是很小的。一個企業的1000人中可能只有不到100個人在使用。對于互聯網公司和投資機構來講，10倍的用戶群體差異意味著質的差別。

所以，在互聯網投融資的支持下，國內更多廠商走上了面向輕應用，快速過大用戶群體的路線，并取得了動輒上億的融資回報。從另一個角度上看，用戶群體的規模就決定了中國低代碼平臺的輻射面，影響到的人肯定是要比歐美更廣泛的。

其實，這類低代碼平臺產品也可以理解為是無代碼平臺產品，Forrester稱這種為LCDP for business developers，與前面將的LCDP for professional developers對應。在資本市場的支持之下，我們相信無代碼會從低代碼中進一步分化。無代碼很快會成為一個新的分支獨立出去。因為這一些類型的產品，它的商業邏輯是固定的。那就是擁有更大的用戶群體，更大的流量入口機會，更多的投融資，讓更多人知道，然后上市變現，這是互聯網企業中一個非常典型的路徑，與軟件開發工具類廠商的底層邏輯完全不同。

降低二次開發成本的低代碼平臺：

低代碼除了上面這兩種定位之外，還有一種類型的典型應用就是二次開發。對于企業級軟件來講，CRM也好，ERP也好，它通常不是買回來就能用的。需要一個團隊來進行二次開發，適配企業獨特的個性化需求。這個對于大部分企業軟件來講是逃不過去的，甚至可以說是占到很大比例的。所以每一個做CRM，做ERP的廠商，他必須要考慮一個問題，怎么樣幫助我的實施團隊，以及我的商業伙伴，我的代理商的實施團隊，去快速的搞定二次開發這件事。但是，在低代碼出現之前，二次開發是需要靠編程的方式來實現的，而且必須用主系統規定的語言和類庫，推廣起來難度很大。

低代碼的概念提出后，很多的CRM、ERP廠商第一時間開始琢磨低代碼做二次開發這個方向。Salesforce、微軟Dynamic以及國內的用友和金蝶也都是基于類似這樣的背景提出的低代碼平臺。幫助行業軟件快速完成二次開發，本身是一個非常典型的企業個性化應用場景。而且，參與這部分實施的開發者，整體技術水平、技術能力是比廠商側的研發人員低的，低代碼的引入會為他們帶來更多的可能性。

所以二次開發的工具也在逐步迭代和升級，現在我們看到的低代碼開發平臺Lighting、PowerApps、YonBIP等就是不斷讓二次開發變成了一個更低成本的事情。但是這也滋生出一個問題就是，在不同平臺下的低代碼開發工具所生成的系統依然要圍繞著主系統運轉，他們之間是非常割裂的。這就會給后續的系統間擴展，復用，移植等很多方面帶來障礙。

上面提到的三個類別并不能覆蓋所有低代碼產品，Forrester在報告中甚至給中國的低代碼廠商劃分出了9大類別。低代碼平臺的多樣性很強，初次看到“低代碼”時，人們很容易產生盲人摸象的感覺。這也是目前大家對低代碼的意見存在較大分歧的主要原因。所以，如果你真的想要了解這個行業，在迷霧中找到一條路，還是得根據自己團隊的技術能力、需要面對的應用場景選擇合適的類型入手。如果你是一個程序員，要開發核心的生產和銷售軟件，卻將輕應用低代碼平臺作為評估低代碼技術的唯一選項，我相信你無疑會對低代碼很失望；但是，如果你選擇了服務專業開發者的活字格，結論很可能是相反的。不要以為這是個玩笑般的比喻，我們的售前技術支持團隊反饋說有不少程序員都走了這個彎路。

CSDN：如果要給開發者一把尺子，去衡量這個產品是否真的適合自己，從開發效率，技能提升，或者穩定性等等方面，獲得一個對低代碼平臺產品相對全面的評估。只用三個問題來判斷，你會如何選擇？

嘉賓：這是一個方法論的問題。我認為應該用這三個問題來判斷：

1.  “拿來干什么”。不同類型的低代碼產品有不同的應用邊界和底層邏輯。開發者評估一款低代碼產品時，首先弄清自己的應用場景。如果你希望做的是簡單的輕應用，講究短平快，不需要考慮和其他軟件集成以及持續發展的問題，那么選擇面向專業開發者的低代碼平臺的話，學習成本就太高了；如果你希望用低代碼技術開發核心業務系統甚至分階段搞定全公司所有軟件開發，輕應用平臺顯然無法承載你的夢想。

2.  “怎么干”。同樣的應用場景，不同的產品有不同的實現路徑。條條大路通羅馬，但是高速公路需要掏過路費，鄉村小道跑的不舒服。具體到開發工具上，我們需要根據自己的技術能力選擇更適合自己的低代碼平臺。不過，如果有學習的意愿和投入，我建議選擇架構更專業、開放性更高、與大學里軟件開發課程更近的那一款，提升一下軟件開發的上限。

3. “誰干成了”。實踐是檢驗真理的唯一標準。如果我們沒有足夠的時間來做詳細的評估，可以去看一下其他人用該平臺開發的系統，從界面自由度、功能復雜度到穩定性，都能體現到案例中。比如如果一個平臺有大量開發ERP、MES這種核心系統的案例，客戶的要求會比做后勤部門數據填報的輕應用高很多，所以該平臺的穩定性應該沒問題。所以，去這些低代碼平臺廠商的官網看看他們推的案例，也是一個不錯的方法。

CSDN：程序員喜歡的低代碼平臺產品要具備什么樣的特點

嘉賓：對于程序員來說，轉型到低代碼開發和新學一門編程語言在本質是一樣的，必須考慮學習的成本和之前經驗積累的復用性。所以，我們接觸過的大多數程序員在做低代碼平臺選型評估時，首先會看這個工具用起來，跟之前寫代碼的流程一樣嗎？跟寫代碼的架構一樣嗎？為啥？因為這樣程序員和其他技術性崗位一樣，專業知識，專業技能是需要持續積累和復用的，只有這樣才能讓職業生涯走得更順。所以，我們不能讓程序員之前一行一行寫代碼，積攢起來的經驗，在切換到低代碼平臺開發之后，全部作廢。如果做不到這一點，大多數程序員就會被推到了低代碼的對立面。

程序員在選擇開發工具的時候希望能繼續延續自己的優勢，逆勢而為就會為產品的落地造成很大的障礙。順勢而為就可以延續程序員之前積攢的經驗，成為更好的開發者。

落實到具體功能上面，我們之前做過一次調研，面向活字格低代碼平臺的用戶群體，征集開發者最喜歡的三個功能是什么。最終，我們整理出三個點，現在看也是比較有代表性的。

第一個是：抹平數據庫之間的差異性，自動適配MySQL、MS SQL Server、Oracle的數據類型和特殊語法，學習成本更低。

第二個是：可以在開發中對服務端API可以調試，并且提供包含各步驟耗時在內的詳細日志。讓低代碼不再是一個黑盒子，Debug非常方便。這里多說幾句，在核心業務系統中業務邏輯一般會很復雜，哪怕最簡單的一個庫存出庫，也并不是說創建一張出庫單就完了。實際的業務流程中除了出庫單，還要更新庫存數據，做設置好的低庫存檢測，觸發警報的同時，調用采購系統的接口發起補貨流程，最后更新財務使用的庫存數據等等。這一系列操作都需要確保事務性和處理性能。事實上，我們很難確保一次性將這些操作全部搞正確，低代碼平臺能提供快速定位和修復問題的能力變得非常重要。

第三個是：前端布局可以自由修改。有很多的低代碼開發平臺的產品，壓根不允許你自己布局，對UI要求高的客戶來說，這種方案來說就非常不友好了。

從上面的這些內容可以看到，程序員最關心的功能是什么？第一就是一定要能操作數據庫，第二是一定要能像寫程序一樣去精確的控制業務邏輯，第三就是一定要自由的做布局。說到底，一個前后端分離的企業軟件，就這三件事。

 *點擊填寫信息，可獲贈《CSDN低代碼開發者認知度與應用》洞察報告*