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

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

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

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

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

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

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

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

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

即使是第三類平臺能夠完全拋開源代碼通過圖形化搭建任何復(fù)雜應(yīng)用，同樣道理，開發(fā)人員必須有面向?qū)ο蟮倪壿嬎季S，以圖形化的形式去構(gòu)建領(lǐng)域?qū)嶓w、值對象、領(lǐng)域服務(wù)、領(lǐng)域事件，通過連線去建立這些要素的邏輯關(guān)系。

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

1、提供了大量常用標(biāo)準(zhǔn)組件和函數(shù)；

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

3、以圖形化方式建立各種數(shù)據(jù)模型；

4、以圖形化方式建立各種業(yè)務(wù)對象；

5、以圖形化方式實現(xiàn)了界面的布局；

6、以有向連線的方式為計算邏輯和業(yè)務(wù)對象建立關(guān)聯(lián)；

7、實現(xiàn)基本語法邏輯的自動識別。

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

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

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

更重要的是，所有低代碼平臺都已經(jīng)經(jīng)過內(nèi)部的反復(fù)測試，并有了大量應(yīng)用實踐，有足夠的成熟度才會推向市場。

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

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

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

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

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

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

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

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