事件回顧?

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

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

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

圖片來源 @山海視頻截圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“飯碗”之爭?

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

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

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

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

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

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

• 無代碼：比如業(yè)界將慢慢不使用主要用于業(yè)務(wù)流程工作流和數(shù)字營銷內(nèi)容的代碼。
• 低代碼：將提供大多數(shù)定制 UI 布局和應(yīng)用程序邏輯(前端和后端)的主干。
• “高”代碼：對于復(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)然，本身低代碼平臺的開發(fā)程序員的需求就相當(dāng)旺盛。

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

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

三宗罪?

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

1、黑盒焦慮

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

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

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

2、不便維護(hù)

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

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

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

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

3、拼樂高

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

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

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

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

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

IT 新反思?

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

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

• 技術(shù)平民化

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

• 讓專業(yè)者更專注

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

寫在最后?

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

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

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