“轉碼”無疑是最近這幾年在年輕人中廣泛談論的一個話題，而計算機科學（computer science）也更是被稱為“宇宙機”。但這一切的基礎，是過去二十余年間互聯網成為了全球經濟增長的重要引擎，作為互聯網產業的基礎，程序員自然也就吃到了時代的紅利。

然而隨著互聯網行業寒冬期的到來，降本增效、開源節流幾乎成為了全球互聯網廠商共同的應對措施，甚至高薪酬程序員的“35歲危機”一下子似乎變成了現實。但問題是程序員的門檻并不低，并且還是互聯網企業的剛需，那么有沒有一種既能保障代碼的產能、又可能降低成本的解決方案呢？答案其實是有的，而這就是自兩三年前開始變得火熱的“低代碼（LowCode）”概念。

只需少量代碼、甚至無需代碼即可完成開發工作，這是許多低代碼平臺描繪給企業用戶的圖景，看起來似乎廠商也有了可以不用高薪酬程序員的機會。可事實卻是，即便全球權威咨詢機構Gartner給出了在2021年至2026年間，中國LCAP（低代碼應用平臺）市場收入將以25.4%的復合年增長率加速增長這一樂觀預估，但從其他機構的統計數據來看，目前低代碼軟件在企業軟件市場的滲透率還不到1%。

那么問題就來了，低代碼平臺描述的未來是如此美好、又非常契合企業的需求，那么企業用戶怎么就不買賬呢？

為此，首先不妨來看看低代碼本身。即使Java、C 、python等經過計算機科學成熟階段出現的“高級語言”，它們即便與自然語言相接近，且能為計算機所接受的語意確定、規則明確、自然直觀，但它們始終是抽象的，代碼和代碼能實現的效果自然也不可等而視之。

作為與傳統計算機語言對應的存在，低代碼的表現形式是“可視化編程”、核心則為“代碼復用”，通過可視化、模塊化、拖拽式的特性，來代替傳統開發方式中大量編寫代碼進行開發。在低代碼的概念中，模塊化組件代替了編程語言中一行行的代碼，而可視化的設計則讓抽象思維變成了更容易理解的搭積木。

簡單來說，程序員就相當于是飯店里的廚師，是通過手藝來做出合格的菜品，而低代碼平臺則相當于是提供預制菜，生產的是完全沒有廚藝的消費者也能上手的半成品食物。既然預制菜能火、低代碼顯然也有爆發的理由，并且低代碼確實從一定程度上降低了編程的門檻，即便不具備編程技能的“小白”也能參與到開發過程中。

根據Gartner公布的相關數據顯示，APP開發服務的市場需求增長速度至少是目前全球IT交付能力的5倍，而低代碼則可以幫助軟件開發者填補這一缺口，讓用戶能夠自己開發系統解決方案。特別是在此次疫情加速的數字化進程中 ，低代碼更是能夠幫助相當多的傳統企業完成數字化轉型，以便企業能夠對不斷變換風向的市場做出即時反應、適應新的市場環境，并最終換取競爭優勢。

甚至于對互聯網廠商而言，低代碼也有著不可或缺的意義。眾所周知，“996”就是從互聯網行業流傳出來的，而這背后反映的是互聯網廠商面對日新月異的市場環境，只能通過堆積人力的方式來加快項目的交付、以實現快人一步的效果。除了996這樣明顯不科學的策略，“敏捷開發”這樣一個將項目的構建切分成多個子項目，以實現小步快跑、快速迭代的方式也被廣泛應用。

即便敏捷開發思想的出現加速了互聯網產品的完成速度，但依然滿足不了廠商的需求，到目前為止，互聯網行業都是加班問題的重災區。這是因為敏捷開發盡管能夠提升效率、但這還不夠，低代碼的出現不只是讓專業開發人員的進度更快，還可以讓業務人員也參與到開發應用中。

但非常遺憾的是，低代碼的一大問題就是“中看不中用”，并且僅僅這一個問題就阻礙了低代碼在企業級用戶中的普及。由于低代碼的目標是讓更多非專業人士也有參與到應用開發項目中的能力，為了實現這一點，低代碼平臺將過去代碼開發過程進行抽象、并形成可配置的各類組件，再通過添加組件和配置組件即可實現系統開發。但問題也出在了這里，低代碼為了實現普惠價值而顧此失彼。

雖然模塊化開發聽起來很潮，但將不同代碼實現的功能模塊化、通用化的代價，就是精確性下降。畢竟在低代碼平臺呈現給開發者的是不再是一行行代碼，而是一個個用以實現不同功能的模塊化組件，就像是預制菜的味道無論如何比不了正規餐廳一樣，最終呈現出的是通過低代碼平臺做出的應用，在性能上就是弱于傳統開發的同款產品。

要知道，在如今這樣市場競爭極為激烈的互聯網行業，如果最起碼的用戶體驗都無法保證，那么再好的創意也會被浪費。僅僅是這一條，就會讓相當多的企業對低代碼望而卻步。再說了，低代碼平臺通常采用組件式開發，應用組件相當于“黑盒”，企業用戶再次開發時如果不使用原先的低代碼平臺，就需要重新梳理理解代碼、重新編程，這就代表企業與低代碼平臺的捆綁性極強，而這也會被企業用戶所警惕。

換而言之，在目前低代碼開發無法媲美傳統開發方式的情況下，企業用戶顯然更傾向于維持現狀。