低代碼的興起，程序猿要拒絕還是擁抱（低代碼會(huì)取代程序員嗎）

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

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

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

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

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

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

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

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

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

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

其實(shí)所有這些平臺(tái)只是一種工具，給程序員解決了以下幾個(gè)問題：

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

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

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

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

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

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

7、 實(shí)現(xiàn)基本語(yǔ)法邏輯的自動(dòng)識(shí)別。

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

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

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

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

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

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

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

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

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

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

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

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