低代碼是一種近些年興起的企業軟件快速開發技術和工具。借助低代碼使用者無需編碼即可完成企業應用的常用功能，少量編碼擴展出更多功能。低代碼憑借低門檻、高效率和易集成等特性，被越來越多的軟件開發團隊青睞。Gartner預測，到2024年四分之三的大企業將會使用至少4種低代碼開發平臺，用于信息化應用開發。屆時，65% 的應用開發將通過低代碼完成。

面對低代碼的興起，程序員們有幾種不同的心態：一種是輕視的心態，認為低代碼技術不能登大雅之堂，只是給初學者使用的雕蟲小技，解決不了復雜的技術問題；一種是恐懼的心態，擔心低代碼會取代專業開發者，并淘汰大部分程序員的工作；一種是抵觸的心態，認為低代碼平臺是個黑盒子，很危險，有很多不穩定因素，未來的迭代升級無法保障；還有一種失落的心態，認為有了低代碼開發工具，程序員再不需要掌握高深的技術，工作中已經失去了成就感。

作為一個資深程序員，通過這兩年對各種低代碼平臺的了解，我想就低代碼平臺的興起談一談我個人的看法。

低代碼平臺的代表企業包括國外的OutSystems、Mendix等，國內的企業有奧哲網絡（氚云）、ClickPaaS、瓴碼、宜創科技、炎黃盈動、數式科技、輕流、搭搭云、黑帕云等低代碼創業公司，以及APICloud、明道云等延伸或轉型到低代碼領域的創業公司，以及大型企業旗下的業務模塊，如帆軟的簡道云、阿里的宜搭等?？梢詫⒌痛a開發平臺按照技術路徑架構分為三類：

一類是基于表單/引擎驅動的模式，通過建立多張表單，使用流程串聯，定義報表輸出方式，構建表單類輕應用。該類模式的技術壁壘不高，主要支持開發表單類應用，場景有一定局限性。更適合簡單短信項目，不適合長期的循環迭代產品的開發，尤其產品要面對多樣性需求，必須具備高配置屬性的時候。比如表格展示，同一個流程不同職位看到的表格都是一樣，涉及到敏感信息不能區別展示，無法實現千人千面。這類平臺有：輕流、搭搭云、阿里的宜搭、宜創科技等。

一類是基于aPaaS平臺模式，包含多種具體的技術手段和路徑，例如模型驅動、代碼生成、可視化編程等，底層技術涉及云原生、元數據、多租戶等。該類模式的技術壁壘較高，顆粒度更細，復雜度、靈活度更高，能夠支持廣泛場景的復雜應用開發，具備服務大客戶和中小客戶的能力。這類模式在面對復雜場景時，仍然需要編寫邏輯代碼。特別是在面向高并發應用場景，需要投入大量的后端軟件開發。這類平臺有：OutSystems、Mendix、奧哲網絡（氚云）、ClickPaaS、炎黃盈動、數式科技、黑帕云等。

還有一類是基于aPaaS+iPaaS平臺模式，這類低代碼平臺不但具備可視化模型驅動、代碼編譯自動生成，無論前端組件還是后端業務邏輯都能細粒度搭建，實現高度復雜、高度靈活的應用場景。這類平臺的iPaaS部分屬于領域驅動的設計模式，其核心概念：域、子域、領域實體、值對象、領域服務、領域事件等是天然的圖形化解決復雜問題的表達模式，面對任何復雜應用場景都能支撐aPaaS的可視化搭建，并能可視化集成各種業務應用，適應任何高并發的應用場景。這類平臺有：瓴碼PaaS。

每種低代碼平臺都有其存在的價值，第一類平臺雖然使用范圍較窄，程序員們也不要對其嗤之以鼻的輕視，這種平臺特別適合不懂軟件的業務實施人員使用，能夠快速響應業務簡單調整的個性化需求；

對于復雜業務場景的應用實現，雖然第二類平臺可以通過可視化搭建大部分功能，很多數值模型、業務流程模型的搭建仍然離不開專業程序員邏輯抽象能力，特別是很多復雜算法邏輯、以及后端系統架構的搭建還是要使用到源代碼實現。

即使是第三類平臺能夠完全拋開源代碼通過圖形化搭建任何復雜應用，同樣道理，開發人員必須有面向對象的邏輯思維，以圖形化的形式去構建領域實體、值對象、領域服務、領域事件，通過連線去建立這些要素的邏輯關系。

其實所有這些平臺只是一種工具，給程序員解決了以下幾個問題：

1、提供了大量常用標準組件和函數；

2、以圖形化方式替代了原先的計算邏輯；

3、以圖形化方式建立各種數據模型；

4、以圖形化方式建立各種業務對象；

5、以圖形化方式實現了界面的布局；

6、以有向連線的方式為計算邏輯和業務對象建立關聯；

7、實現基本語法邏輯的自動識別。

從而把程序員從代碼式的邏輯中解放出來，以圖形化更直觀的方式展示所有圖靈完備的機制。還能自動識別大部分語法邏輯，減少BUG數量。并通過組件標準接口的定義提高組件復用的效率。讓軟件開發效率有一個革命性的提高。所以，完全不必擔心程序員的工作會被淘汰，低代碼只是專業開發者手邊更趁手、更高效的工具罷了。

又有一種態度認為這些低代碼開發平臺是個危險的黑盒子，他們擔不起在無法控制的“黑盒”上開發關鍵任務帶來的風險，比如平臺不穩定怎么辦、開發進度過半發現有問題無法解決怎么辦、升級迭代無法實現怎么辦等等。首先，這種邏輯看起來沒毛病，所以，我將花更大的篇幅來解釋為什么這種抵觸是不合理的。

首先，低代碼的黑盒子是在開發者熟悉的技術棧上運行，而這些技術棧本身和低代碼類似，也經歷了被逐步認識、喜愛、鄙視并再次喜愛上的過程。比如瓴碼低代碼開發平臺就是的后端底層技術架構采用c++，后端業務邏輯采用NodeJS，前端完全使用JavaScript，安卓端和IOS端使用Flutter。這些技術棧保障了低代碼開發平臺自身的穩定性和可靠性。

更重要的是，所有低代碼平臺都已經經過內部的反復測試，并有了大量應用實踐，有足夠的成熟度才會推向市場。

事實上，我們都愛“黑盒子”，尤其是可以幫我們大幅節省時間的黑盒子。Java及其姊妹語言Scala，Groovy，和其他語言一樣依賴于開發者中最受歡迎的黑盒：JVM；而C#、VB.net依托在.net Framework上才能運行。那么，為什么我們會信任JVM、.net而不是低代碼呢？因為時間可以為這些平臺證明。

21世紀初，.net在誕生時也受到開發者社區的嚴格審查。但在看到它年復一年地順利運行后，信任度增加了。開發者知道C#和.net仍然會存在很長一段時間，而微軟將繼續支持這兩者。我不知道微軟將會如何執行我的C#，但是我依然信任著它。就像我相信V8引擎執行我的JavaScript，JVM運行我的Java一樣。當然，我也不能忘記曾經依賴的其他著名的黑盒：Spread、KendoUI、ActiveReport等前端控件。正是因為有了這些控件，我們開發應用的效率得到了數倍的提升。如果你從事過程序界面的開發，我相信你一定會和我有同感。

事實上，低代碼并不是一個這兩年橫空出世的技術，只是近些年更受媒體關注而已。十幾年來，已經有太多的案例能向你證明這個“黑盒子”的真實實力，應用場景從MES、ERP到SCM以及SCRM，終端平臺也支持PC瀏覽器、APP、企業微信和釘釘。所以，也許是時候給低代碼這個不算很新的黑盒子多點信心了。

另外，我們程序員中還有很多技術控，喜歡鉆研各種高深技術，確實通過技術的積累某方面講能夠提高技術人員的價值。但有很多技術已經大眾化、平臺化了，程序員們就大可不必去重復造輪子，只需要順手拿來用即可。

低代碼平臺就是一個屏蔽了很多復雜技術的大平臺，例如瓴碼PaaS系統，實現了基于領域驅動的微服務架構全部技術，包括：業務流引擎、分布式事務處理、分布式數據交互、異地多活的備災處理、高并發的負載均衡、安全與認證機制、微服務的健康檢測等等。程序員們只需要托拉拽、畫圖連線、簡單配置，即可調用平臺提供的技術接口，輕輕松松就能解決以前需要技術牛人花大力才能解決的問題。

那么，是不是有了低代碼平臺，開發工作就不需要技術牛人呢？并不存在這種問題，只是技術牛人的關注重點要發生轉變，再不用象以前關注系統端的技術，而更關注業務端的抽象能力，例如：如何把一套業務需求抽象出領域實體樹，定義域、子域之間的關系，以及每個領域實體內的值對象、領域服務、領域事件的定義。對業務的理解能力、對領域驅動的知識積累、對領域實體的抽象能力、對算法的邏輯思維能力，一樣可以把技術牛人發揮到極致。當技術牛人制作完一套業務系統的技術圖紙，以前需要996的上班幾個月才能完成的系統，使用低代碼平臺后短短幾周就被你攻克，就像摩天大樓的總設計師一樣自豪感悠然而生。總之，技術牛人是不可替代的。

程序員們除了低頭編代碼之余，也要學會抬頭看路。時代在發展，我們不但要緊跟時代步伐，有時還需要有比別人更長遠的眼光，時時保持一顆好奇的心，以及不斷學習的熱情，去探知新鮮事物。而不是不加思考、不去了解地抵觸或恐懼新鮮事物的出現。大部分人因看見而相信，只有很少部分人是因相信而看見。希望更多程序員們敢于相信，來迎接軟件生產力的這次大變革。

開始使用低代碼工具，乘著軟件開發技術的發展趨勢，從更高效率的在開發中獲益吧。