事件回顧?

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

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

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

圖片來源 @山海視頻截圖

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

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

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

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

業內人士感嘆：“低代碼，正在模糊專業開發者與非專業開發者之間的界限，在慢慢重構著員工與 IT 部門之間的關系。”

風起“稀缺”?

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

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

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

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

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

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

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

不難看出，第二招已經演變為不同的名稱，如第四代語言、計算機輔助軟件，當然還有現在大熱的無代碼 / 低代碼。

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

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

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

“飯碗”之爭?

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

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

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

現有傳統的開發人員的框架和工具都跟不上這種迫切需求的節奏。3 個月的交付速度與 30 分鐘的上線速度，大家一目了然。

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

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

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

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

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

三宗罪?

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

1、黑盒焦慮

“平臺上的各種可視化組件、邏輯動作和部署環境都是黑盒，如果內部出問題無法排查和解決。”

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

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

2、不便維護

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

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

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

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

3、拼樂高

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

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

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

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

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

IT 新反思?

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

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

• 技術平民化

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

• 讓專業者更專注

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

寫在最后?

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

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

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

對于低代碼你怎么看?歡迎大家在評論區留言，我們將在評論區選擇三位留言點贊最高的小伙伴，送出我們 51CTO 價值200元的獨家技術圖譜一份，歡迎大家踴躍參加哦~

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