轉(zhuǎn)載自：技術(shù)領(lǐng)導(dǎo)力

本文的主題，來源于我跟一位讀者的交流：

這位讀者看了我在朋友圈分享的文章，問我低代碼會(huì)不會(huì)讓程序員更加內(nèi)卷？因?yàn)閹拙湓捳f不清楚，就干脆寫篇文章來解答一下。

要回答這個(gè)問題，需要先弄清楚：低代碼適合做什么，不適合做什么，以及低代碼解決的是“存量”問題，還是“增量”問題等等，下面我們進(jìn)入正題。

01 低代碼適合做什么？

先來思考一個(gè)問題：用低代碼能不能搭建一套完整的ERP系統(tǒng)？

答案是肯定的，特斯拉早期在搭建自己的ERP時(shí)，就采用低代碼平臺(tái)，當(dāng)他們的業(yè)務(wù)流程跑順之后，才用.net重構(gòu)了一遍。

但是一般企業(yè)不會(huì)用低代碼從零來開發(fā)整套ERP系統(tǒng)，因?yàn)槿绻阈枰惶譋RP，直接購買成熟的解決方案就可以了。除非你的情況跟特斯拉一樣，公司的業(yè)務(wù)模式跟同行業(yè)有很大區(qū)別（傳統(tǒng)汽車銷售是經(jīng)銷商模式，特斯拉是直營模式），那就另當(dāng)別論了。

就目前而言，低代碼不適合用來從0到1構(gòu)建厚重的企業(yè)核心數(shù)字化系統(tǒng)，低代碼更適合基于核心數(shù)字化系統(tǒng)之上，構(gòu)建創(chuàng)新類應(yīng)用、敏捷運(yùn)營類應(yīng)用。

有個(gè)更形象的說法，低代碼更適合做企業(yè)數(shù)字化建設(shè)當(dāng)中“最后一公里”的事情。

用大家熟悉的餐飲連鎖店來打個(gè)比方，企業(yè)核心數(shù)字化系統(tǒng)好比中央廚房，低代碼就是分布在城市各個(gè)角落的門店，中央廚房負(fù)責(zé)生產(chǎn)配菜，門店根據(jù)顧客實(shí)際需求，把配菜做一些輕加工或創(chuàng)新，提供給顧客。

同樣的道理，企業(yè)核心數(shù)字化系統(tǒng)提供各種經(jīng)營數(shù)據(jù)，低代碼基于這些數(shù)據(jù)，快速開發(fā)適合各個(gè)業(yè)務(wù)場景的業(yè)務(wù)應(yīng)用。

可以看出，這樣做的好處就是，極大提升了技術(shù)研發(fā)和系統(tǒng)交付的整體效率。

低代碼當(dāng)前正在處于“技術(shù)成熟度曲線”的創(chuàng)新萌芽期，隨著低代碼平臺(tái)的日益成熟，模板越來越豐富、生態(tài)越來越完善，未來低代碼的適用范圍也會(huì)得到擴(kuò)展。

當(dāng)前比較適合采用低代碼來開發(fā)的5類應(yīng)用有：

1、企業(yè)門戶。包括App、小程序、PC門戶等等，數(shù)據(jù)都來自中臺(tái)、后臺(tái)，企業(yè)門戶只是做展示，以及簡單的互動(dòng)。

2、數(shù)據(jù)操作及展示應(yīng)用。通過連接企業(yè)的數(shù)據(jù)庫，把生產(chǎn)經(jīng)營的數(shù)據(jù)進(jìn)行編輯刪除查詢等操作。

3、基于表單的應(yīng)用?；跀?shù)據(jù)庫的表單收集、處理、統(tǒng)計(jì)類應(yīng)用。

4、業(yè)務(wù)流程應(yīng)用。定義復(fù)雜的工作流，跨部門協(xié)作流程，復(fù)雜審批流程，比如：OA、人力、財(cái)務(wù)等系統(tǒng)。

5、移動(dòng)端應(yīng)用。基于已有核心生產(chǎn)經(jīng)營系統(tǒng)，進(jìn)行移動(dòng)化的應(yīng)用場景。

02 低代碼不適合做什么？

如上文提到的，就目前而言低代碼不適合用來從0開始構(gòu)建厚重的企業(yè)核心數(shù)字化系統(tǒng)，因?yàn)槭芟抻谀０?、生態(tài)、可擴(kuò)展性。

低代碼畢竟不是高級(jí)開發(fā)語言，因此對(duì)于界面效果要求特別高、復(fù)雜的算法和數(shù)據(jù)挖掘、高性能和復(fù)雜系統(tǒng)架構(gòu)、要求較高的底層開發(fā)等等，都不適合使用低代碼。

總結(jié)一下，不適合用低代碼開發(fā)的應(yīng)用場景：

1、對(duì)界面效果要求較高的應(yīng)用。比如短視頻應(yīng)用、交互酷炫的游戲。

2、復(fù)雜的算法和數(shù)據(jù)挖掘。雖然低代碼可以處理復(fù)雜的業(yè)務(wù)邏輯，但是不適合用來處理復(fù)雜算法和數(shù)據(jù)挖掘，這類應(yīng)用應(yīng)該采用更專業(yè)的BI開發(fā)工具、機(jī)器學(xué)習(xí)平臺(tái)等工具。

3、高性能和復(fù)雜架構(gòu)。許多互聯(lián)網(wǎng)巨頭的并發(fā)量動(dòng)輒千萬、上億，為了優(yōu)化性能需要做很多措施，如服務(wù)化、中臺(tái)化、集群化、云化等等。低代碼是相對(duì)標(biāo)準(zhǔn)的：界面層、邏輯層、數(shù)據(jù)層的架構(gòu)模式，無法應(yīng)對(duì)高性能和架構(gòu)靈活性。

4、要求較高的底層開發(fā)。如設(shè)備、硬件接口、驅(qū)動(dòng)程序等等，這類開發(fā)工作可能C、匯編語言更適合。

03 低代碼會(huì)讓程序員更加內(nèi)卷嗎？

我們知道了低代碼適合做什么，不適合做什么，也就搞清楚了低代碼平臺(tái)的能力邊界。

那么接下來探討：低代碼解決的是“增量”問題，還是“存量”問題？

在企業(yè)數(shù)字化建設(shè)的背景之下，低代碼實(shí)際上解決的是“增量”問題。因?yàn)樵趥鹘y(tǒng)研發(fā)模式之下，有些需求雖然也很重要，但是跟戰(zhàn)略項(xiàng)目相比又沒那么重要，于是這類需求就只能等待排期。

排期你懂的，短則一兩個(gè)月、長則半年一年，所以這類需求實(shí)際上是被壓制的。

有了低代碼，就可以低成本快速的開發(fā)這類需求，因此這是個(gè)“增量”市場。把程序員從這些技術(shù)含量較低的CRUD工作中釋放出來，去做一些更有技術(shù)含量的架構(gòu)優(yōu)化、底層服務(wù)升級(jí)。

可見，低代碼創(chuàng)造了一個(gè)“增量”市場，幫助程序員提高了工作的含金量，并不會(huì)造成程序員這個(gè)行業(yè)的內(nèi)卷。

04 低代碼會(huì)讓程序員失業(yè)嗎？

如上文分析，低代碼再強(qiáng)大也有它的能力邊界，并不能滿足所有軟件研發(fā)的場景。另一方面，高級(jí)軟件工程師的人才缺口一直都非常大，從有關(guān)部門發(fā)布的數(shù)據(jù)來看，2020年的人才缺口就有200萬以上。

低代碼不但不會(huì)讓程序員失業(yè)，反而會(huì)讓程序員越來越值錢。因?yàn)樾袠I(yè)分工將更加精細(xì)化了，大量常規(guī)的業(yè)務(wù)系統(tǒng)開發(fā)工作由低代碼來完成，既釋放了程序員的生產(chǎn)力。

一個(gè)職場人能夠掙多少錢，是由他所創(chuàng)造的價(jià)值決定的，程序員將精力投入到更有技術(shù)含量、更能產(chǎn)生商業(yè)價(jià)值的研發(fā)工作當(dāng)中。只要為公司做出了貢獻(xiàn)，公司必定會(huì)給你相應(yīng)的回報(bào)。老板也不傻，不給你加工資，萬一你跑到競爭對(duì)手那里怎么辦？

結(jié)語

技術(shù)作為人類改造自然的工具，被淘汰是它的宿命，因?yàn)榧夹g(shù)總是會(huì)不斷推陳出新、不斷迭代。

程序員要有深度思考的能力，罵自己的勞動(dòng)工具是“毒瘤”是非?？尚κ虑椋?dāng)然也不要過分迷戀它。

說笑可以，但是你要知道PHP從來不是世界上最好的語言、低代碼也不是世界上最好的開發(fā)工具，它只是一個(gè)工具而已，人才是這場技術(shù)變革的核心要素。

在我看來，程序員更像是魔法世界里訓(xùn)練有素的魔法師，他明白法術(shù)的威力，并且善用這種力量來讓生活變得更加美好。

魔法世界里最偉大的魔法師，不是那些法術(shù)最厲害的人，而是那些用善良、勇氣和智慧來感召更多的魔法師，為世界做出巨大貢獻(xiàn)的人。

程序員生逢其時(shí)，何其幸運(yùn)，美好的生活就在眼前，干就完了！