事件回顧?

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

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

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

圖片來源 @山海視頻截圖

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

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

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

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

業(yè)內人士感嘆：“低代碼，正在模糊專業(yè)開發(fā)者與非專業(yè)開發(fā)者之間的界限，在慢慢重構著員工與 IT 部門之間的關系?！?/span>

風起“稀缺”?

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

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

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

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

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

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

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

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

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

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

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

“飯碗”之爭?

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

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

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

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

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

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

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

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

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

三宗罪?

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

1、黑盒焦慮

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

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

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

2、不便維護

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

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

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

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

3、拼樂高

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

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

可這不正是反映了當下迫切的數字轉型開發(fā)需求嗎?

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

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

IT 新反思?

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

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

• 技術平民化

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

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

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

寫在最后?

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

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

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