事件回顧?

最近看到不少低門(mén)檻開(kāi)發(fā)軟件應(yīng)用的新聞：“30 分鐘搭一款核酸檢測(cè)登記應(yīng)用”、“2 小時(shí)緊急上線(xiàn)抗疫求助應(yīng)用”、“00 后低代碼開(kāi)發(fā)者畢業(yè)月薪過(guò)萬(wàn)”等等。

近期，廣西防城港市出現(xiàn)疫情，全市展開(kāi)一輪大規(guī)模核酸檢測(cè)。柳鋼工人彭期文在釘釘上僅用 30 分鐘就通過(guò)低代碼搭起一款“核酸檢測(cè)登記”應(yīng)用，原本需要大規(guī)模的排隊(duì)登記，如今手機(jī)一掃，3 小時(shí)就能完成 7000 余人核酸檢測(cè)。

彭期文稱(chēng)，看到自己做的低代碼程序能夠幫助到這么多的醫(yī)療工作團(tuán)隊(duì)，還是感到十分高興。

圖片來(lái)源 @山海視頻截圖

鋼鐵工、社區(qū)志愿者、非專(zhuān)業(yè)畢業(yè)生……隨著低代碼的流行，很多弱編程基礎(chǔ)的“小白”都表現(xiàn)出“敏捷開(kāi)發(fā)”的潛質(zhì)。以第一則新聞為例：核酸登記軟件雖說(shuō)工程量不大，但麻雀雖小，五臟俱全，有業(yè)內(nèi)人士測(cè)算了下——

如果用傳統(tǒng)軟件開(kāi)發(fā)的方式，從需求調(diào)研，到產(chǎn)品設(shè)計(jì)、軟件開(kāi)發(fā)、前后端聯(lián)調(diào)、測(cè)試、發(fā)布，怎么也要 5 天吧(產(chǎn)品 1 人，2 天;開(kāi)發(fā) 2 人，3 天;測(cè)試 1 人，2 天，也就是 10 人 / 日)。

也就是說(shuō)，使用了低代碼，成本降低了 90% 。技術(shù)一把手，估計(jì)看到這個(gè)數(shù)字，肯定又得慌了。

低代碼開(kāi)發(fā)平臺(tái)通過(guò)可視化、模塊化、拖拽式來(lái)代替?zhèn)鹘y(tǒng)開(kāi)發(fā)方式的寫(xiě)大量代碼來(lái)進(jìn)行開(kāi)發(fā)，減少了傳統(tǒng)模式開(kāi)發(fā)中需要付出的冗雜的、重復(fù)性的編碼工作，從而達(dá)到“降本增效”的目的。

業(yè)內(nèi)人士感嘆：“低代碼，正在模糊專(zhuān)業(yè)開(kāi)發(fā)者與非專(zhuān)業(yè)開(kāi)發(fā)者之間的界限，在慢慢重構(gòu)著員工與 IT 部門(mén)之間的關(guān)系。”

風(fēng)起“稀缺”?

開(kāi)發(fā)圈有流傳一種“摩爾 996 定律”：平均每 18 個(gè)月就會(huì)有某種開(kāi)發(fā)工具跳出來(lái)說(shuō)能讓開(kāi)發(fā)成本降低一半，同時(shí)業(yè)務(wù)的需求就會(huì)增加到原來(lái)的兩倍。比如，程序語(yǔ)言的進(jìn)化路徑：

“01001001”式的機(jī)器語(yǔ)言→“mov”、“add”式的匯編語(yǔ)言→ “if”、“else”式的高級(jí)語(yǔ)言

即便是高級(jí)語(yǔ)言，也在高速迭代著：面向過(guò)程的 C、面向?qū)ο蟮?Java、面向智能的 Python。而這種迭代，也在圈內(nèi)引發(fā)了一波波如「VB 剛出來(lái)時(shí)，C 程序員看不起 VB，PHP 出來(lái)時(shí)，所有程序猿都看不起 PHP」 的梗。

低代碼會(huì)是下一代語(yǔ)言嗎?目前看不大可能。但這里只是想表明：編程語(yǔ)言迭代的背后是市場(chǎng)需求的高速增長(zhǎng)。軟件開(kāi)發(fā)自上世紀(jì) 50 年代誕生以來(lái)，它的需求在以越來(lái)越快的速度增長(zhǎng)，而軟件開(kāi)發(fā)人員一直是一種稀缺資源。

而為了解決這個(gè)開(kāi)發(fā)人員短缺問(wèn)題，業(yè)內(nèi)也使出了渾身解數(shù)，但一般分為兩大招數(shù)：

一、提高開(kāi)發(fā)人員生產(chǎn)率的框架和工具(解決了時(shí)間和成本問(wèn)題)

二、降低開(kāi)發(fā)門(mén)檻，讓非開(kāi)發(fā)人員也能夠開(kāi)發(fā)(這主要解決了稀缺性問(wèn)題，但也減少了時(shí)間和成本)

不難看出，第二招已經(jīng)演變?yōu)椴煌拿Q(chēng)，如第四代語(yǔ)言、計(jì)算機(jī)輔助軟件，當(dāng)然還有現(xiàn)在大熱的無(wú)代碼 / 低代碼。

低代碼大火的底層邏輯：數(shù)字化轉(zhuǎn)型不可避免、各企業(yè)應(yīng)用開(kāi)發(fā)需求激增、程序員資源極度短缺是大背景，將過(guò)往來(lái)回重復(fù)的開(kāi)發(fā)能力模塊化、可視化、可定制化。

因此，可以預(yù)見(jiàn)：程序員不會(huì)失業(yè)。就像支持二次開(kāi)發(fā)的 ERP 應(yīng)用軟件的推廣，并沒(méi)有降低市場(chǎng)對(duì)專(zhuān)業(yè)程序員的需求。相反，企業(yè)往往還需要為這種新開(kāi)發(fā)工具額外安排專(zhuān)家崗位。因?yàn)椋谄髽I(yè)而言，最實(shí)用、最有效且百分百可以實(shí)施到位的方案才是企業(yè)想要的，因?yàn)榈灿胁缓线m的地方，管理者可以隨時(shí)去改。而不是招聘一個(gè)傳統(tǒng)的開(kāi)發(fā)及維護(hù)團(tuán)隊(duì)來(lái)進(jìn)行長(zhǎng)周期操作。

于專(zhuān)業(yè)開(kāi)發(fā)者而言，可能失去的是技術(shù)含量不高的、重復(fù)造輪子的、無(wú)需創(chuàng)造力的項(xiàng)目機(jī)會(huì)。畢竟，光確定需求這個(gè)環(huán)節(jié)，就能讓開(kāi)發(fā)者與項(xiàng)目管理者、產(chǎn)品經(jīng)理“撕”上幾個(gè)星期。

“飯碗”之爭(zhēng)?

從某種角度看，縱然傳統(tǒng)的開(kāi)發(fā)模式枯燥、繁瑣些，但畢竟是程序員的活，現(xiàn)在連重復(fù)的“輪子”也不給造了。難免會(huì)讓人擔(dān)憂(yōu)：這不明擺的搶程序員飯碗嗎?

但社會(huì)不就是這樣的進(jìn)化邏輯嗎?任何軟件、語(yǔ)言的流行并付諸商業(yè)化，說(shuō)到底并不是出于程序員的個(gè)體喜好，而是背后的市場(chǎng)商業(yè)需求所推動(dòng)的。

你能阻擋數(shù)字化轉(zhuǎn)型的大勢(shì)嗎?如果沒(méi)有比低代碼更好的、更快的、更完美的解決“開(kāi)發(fā)者稀缺”的問(wèn)題，低代碼的流行就成了必然。

現(xiàn)有傳統(tǒng)的開(kāi)發(fā)人員的框架和工具都跟不上這種迫切需求的節(jié)奏。3 個(gè)月的交付速度與 30 分鐘的上線(xiàn)速度，大家一目了然。

當(dāng)然，這也并不意味著程序員會(huì)陷入「一個(gè)取代另一個(gè)」的“魷魚(yú)游戲”中。

正如各大編程語(yǔ)言在各自的領(lǐng)域各領(lǐng)風(fēng)騷一樣，可以預(yù)見(jiàn)低代碼會(huì)在生態(tài)中達(dá)到這樣一種“混合共存”的平衡：

• 無(wú)代碼：比如業(yè)界將慢慢不使用主要用于業(yè)務(wù)流程工作流和數(shù)字營(yíng)銷(xiāo)內(nèi)容的代碼。
• 低代碼：將提供大多數(shù)定制 UI 布局和應(yīng)用程序邏輯(前端和后端)的主干。
• “高”代碼：對(duì)于復(fù)雜的軟件組件，當(dāng)然還有基礎(chǔ)軟件(工具、操作系統(tǒng)等)，“高”代碼將持續(xù)存在，比如：3D 游戲界面(交互復(fù)雜)及其底層的游戲引擎(邏輯復(fù)雜)、超大型 CRM 系統(tǒng)(一方面是實(shí)現(xiàn)很復(fù)雜，另一方面，這種成熟軟件的標(biāo)準(zhǔn)化程度較高，大部分情況下可以直接用現(xiàn)成的 SaaS 軟件)。當(dāng)然，本身低代碼平臺(tái)的開(kāi)發(fā)程序員的需求就相當(dāng)旺盛。

三種不同方法和理念的共存需要互操作性。可以預(yù)見(jiàn)，在這種平衡中，用戶(hù)可以合并任何現(xiàn)有的軟件組件，無(wú)論是開(kāi)源的、商業(yè)許可的，還是由他們的團(tuán)隊(duì)構(gòu)建的。它們不應(yīng)該局限于低代碼平臺(tái)的組件，或者需要編寫(xiě)特定于該平臺(tái)的定制代碼來(lái)實(shí)現(xiàn)這一點(diǎn)。

所以，在混合共存中，飯碗穩(wěn)穩(wěn)的，不必?fù)?dān)心會(huì)丟。

三宗罪?

任何事物的發(fā)展都沒(méi)有那么美好，低代碼同樣也有備受詬病的三宗罪。

1、黑盒焦慮

“平臺(tái)上的各種可視化組件、邏輯動(dòng)作和部署環(huán)境都是黑盒，如果內(nèi)部出問(wèn)題無(wú)法排查和解決?！?/p>

沒(méi)錯(cuò)，低代碼平臺(tái)上的各種可視化組件、邏輯動(dòng)作和部署環(huán)境都是黑盒，如果一旦內(nèi)部出問(wèn)題，就很難排查和解決。這確實(shí)是目前使用低代碼平臺(tái)時(shí)繞不開(kāi)的最大痛點(diǎn)，但并不屬于低代碼技術(shù)本身的固有缺陷。

這種平臺(tái)問(wèn)題，就如同 Windows 系統(tǒng)之于“藍(lán)屏”問(wèn)題一樣，我們選擇使用“抽象”來(lái)簡(jiǎn)化平時(shí)的操作，就不可避免會(huì)遇到“黑盒”問(wèn)題，讓天生愛(ài)刨根問(wèn)題的技術(shù)人有些忿忿，但如果因?yàn)樗{(lán)屏問(wèn)題，就不用 Windows 系統(tǒng)了吧!

2、不便維護(hù)

一開(kāi)始看起來(lái)很美好，一兩條命令什么都生成了，但是要改個(gè)什么東西，抽絲剝繭最后到最基礎(chǔ)的地方，發(fā)現(xiàn)需要繼承重寫(xiě)原來(lái)的類(lèi)才能實(shí)現(xiàn)需求，有的里面有 bug, 要改特別繞。

關(guān)于維護(hù)性，尚未成熟的低代碼自然有需要完善的地方。但其實(shí)，無(wú)論低代碼還是純代碼，造成應(yīng)用可維護(hù)性低的根本原因不是開(kāi)發(fā)工具，而是開(kāi)發(fā)者自身沒(méi)有去遵循一些軟件開(kāi)發(fā)的普適原則，比如工程規(guī)范性、命名可讀性、DRY/KISS/SOLID 原則等。

因此，低代碼平臺(tái)應(yīng)該積極引導(dǎo)和幫助開(kāi)發(fā)者去改善應(yīng)用的可維護(hù)性。知名的低代碼平臺(tái) Mendix 就提供了很好的參考：除了支持基本的模型分析與重構(gòu)(無(wú)用模型、對(duì)象重命名、子邏輯流提取)，還提供了基于 ISO/IEC 25010 標(biāo)準(zhǔn)的應(yīng)用質(zhì)量監(jiān)控(AQM)能力。

當(dāng)然，低代碼也有自己的適用場(chǎng)景和能力邊界。如果業(yè)務(wù)場(chǎng)景過(guò)于復(fù)雜，本身就不便于維護(hù)，建議考慮換“高”代碼方式。

3、拼樂(lè)高

“試用過(guò)一些所謂的低代碼開(kāi)發(fā)平臺(tái)，要么能力很弱，要么體驗(yàn)太差，只能開(kāi)發(fā)點(diǎn)玩具應(yīng)用。”

很多開(kāi)發(fā)者對(duì)于“拖拖拽拽搞定一個(gè)應(yīng)用”的開(kāi)發(fā)方式嗤之以鼻。而且現(xiàn)在實(shí)現(xiàn)的應(yīng)用也都是類(lèi)似“趣味編程”、“登記 / 審核表單”之類(lèi)的初級(jí)案例，安全、性能、可伸縮性都沒(méi)有保證。

可這不正是反映了當(dāng)下迫切的數(shù)字轉(zhuǎn)型開(kāi)發(fā)需求嗎?

當(dāng)市面上真正成熟的企業(yè)級(jí)低代碼開(kāi)發(fā)平臺(tái)出現(xiàn)以后，完全有能力以高效的開(kāi)發(fā)方式滿(mǎn)足大部分更“高級(jí)”的場(chǎng)景的功能需求。

當(dāng)然，目前低代碼的發(fā)展還有一宗“罪”：如果各大平臺(tái)使用專(zhuān)利技術(shù)，創(chuàng)建“應(yīng)用墻”，又或者在無(wú)代碼 / 低代碼開(kāi)發(fā)人員遇到限制時(shí)，將“高”代碼替代作為最后手段，就會(huì)讓開(kāi)發(fā)者忍不住暴怒一聲：行業(yè)“毒瘤”!

IT 新反思?

歸根到底，市場(chǎng)需求推動(dòng)了我們的生產(chǎn)工具。疫情蔓延加速了全球數(shù)字化轉(zhuǎn)型浪潮的進(jìn)程，低代碼概念雖然新，但技術(shù)并不新，就如同我們熟悉的編程語(yǔ)言、技術(shù)棧的演進(jìn)一般，保持一種平常心看待低代碼，就會(huì)發(fā)現(xiàn)——低代碼不過(guò)是軟件開(kāi)發(fā)生態(tài)中的一員一樣：開(kāi)拓了新的開(kāi)發(fā)方式，解決了企業(yè)開(kāi)發(fā)資源的稀缺的問(wèn)題。

而開(kāi)發(fā)者、技術(shù)管理者則需要重新思考并尋找開(kāi)發(fā)者及 IT 部門(mén)的定位：

• 技術(shù)平民化

時(shí)代不同了，商業(yè)環(huán)境和模式變了，有了云和 AI 加持，中小商業(yè)的數(shù)字化自然會(huì)催生相應(yīng)的知識(shí)體系和人員業(yè)務(wù)能力模型的重構(gòu)。如現(xiàn)在人人都可以在短視頻 App 上輕松視頻編輯，而不再是攝影專(zhuān)業(yè)人員獨(dú)門(mén)技能，但也互不影響。

• 讓專(zhuān)業(yè)者更專(zhuān)注

低代碼抽象了各行各業(yè)的業(yè)務(wù)邏輯，業(yè)務(wù)人員從邏輯層就可以實(shí)現(xiàn)應(yīng)用的創(chuàng)建，非常適合于短生命周期的短平快應(yīng)用，甚至可以用后即焚，例如調(diào)查問(wèn)卷、統(tǒng)計(jì)報(bào)表，經(jīng)過(guò)簡(jiǎn)單培訓(xùn)就可以上手操作，不用再勞煩 IT 部門(mén)。而掌握全棧技能的“高”代碼開(kāi)發(fā)人員，從事更具挑戰(zhàn)也需要深厚積累的應(yīng)用的創(chuàng)建，也可以封裝業(yè)務(wù)邏輯成低代碼模塊供低代碼開(kāi)發(fā)者使用。

寫(xiě)在最后?

時(shí)代在推動(dòng)，技術(shù)人的棧道只會(huì)越來(lái)越多。前段時(shí)間，Gartner 給出了一個(gè)預(yù)測(cè)：到 2025 年，70% 的新應(yīng)用將由低代碼 / 無(wú)代碼技術(shù)完成開(kāi)發(fā)。網(wǎng)上看到一位朋友有趣的描述，這里借用一下：

當(dāng)你與前端聯(lián)調(diào)了一上午接口，又與 PM 撕逼了一下午需求，再與自己的 bug 抗?fàn)幜艘徽?，好不容易遁入?mèng)鄉(xiāng)又被一連串報(bào)警短信吵醒時(shí)，是否有抬頭對(duì)著星空思考：該不該用低代碼呢?

向后看，低代碼目前有點(diǎn)“毒瘤”，但向前看，卻是另一番天地。

對(duì)于低代碼你怎么看?歡迎大家在評(píng)論區(qū)留言，我們將在評(píng)論區(qū)選擇三位留言點(diǎn)贊最高的小伙伴，送出我們 51CTO 價(jià)值200元的獨(dú)家技術(shù)圖譜一份，歡迎大家踴躍參加哦~

最后，51CTO在這里提前給大家拜個(gè)早年，祝大家新年快樂(lè)!