大家好，我卡頌。

你有沒有發現，每過幾年，「低代碼」的概念就會被翻出來熱炒一番。

這也難怪，軟件行業最大的成本就是人力成本（程序員的工資），「低代碼」號稱能夠：

• 用一個外包替代幾個程序員。
• 用產品、設計、財務人員替代程序員。
• 用xxxx替代程序員。

一個只有程序員受傷，還能降本增效的世界，資本怎能不愛。

概念翻來覆去炒了這么多年，為啥市面上還沒出現顛覆程序員工作方式的低代碼平臺呢？

今天，我們來聊聊這個話題。

低代碼，我們聊的是一回事么？

程序員和資本眼中的「低代碼」是一回事兒么？

對于程序員來說，「低代碼」的概念更接近于DSL?。比如，JSX?是對DOM的抽象。

如果將「直接書寫操作DOM的方法」看作代碼，那么「使用JSX這套DSL編寫的React代碼」就是低代碼。

因為前者是開發者面向宿主環境（瀏覽器）直接命令式的書寫代碼。

后者是開發者聲明式地操作狀態，React這個「低代碼平臺」再將「狀態變化」轉化為「操作DOM的方法」。

而對于資本來說，「低代碼」的概念更接近于「珍妮紡紗機」，有了他，就能革了紡紗工（程序員）的命。

為什么前者這種開發模式能夠在業界大規模普及，而后者不能呢？

這就要提到他們的本質區別 —— 是工具還是平臺？

工具 vs 平臺

工具與平臺的目的都是為了「降本增效」，他們的區別是什么？

一個應用從開發到上線平穩運營，涉及到很多工種的不同工作。

工具降本增效的方式是 —— 幫助「從事這些工作的工種降本增效」，比如：

• 前端、后端框架提升業務開發效率。
• Git用于多人協作時的代碼管理。
• Github Action用于完善CI、CD流程。

而平臺降本增效的方式是 —— 將工作流程、工作內容抽象成模塊，這樣即使是外行，只要組裝不同的模塊，就能拼湊出一個應用。

也就是說，前者降本增效是通過「提高專業人士的效率」，而后者是通過「以可視化的方式，降低工作門檻，讓非專業人士替代專業人士」。

但這里有個問題 —— 雖然平臺屏蔽了軟件開發的復雜度，但軟件開發會遇到的問題，他也沒法避免。比如：

如何應對定制化需求？

遇到「依靠模塊組裝無法滿足的定制化需求」，低代碼平臺怎么辦呢？

業界常見的解決方案是 —— 為低代碼平臺保留「編寫代碼的能力」。

畢竟，低代碼平臺的產物也是代碼，只要產物代碼結構清晰，程序員還是能在此基礎上開發定制化需求的。

但問題是，程序員的介入，這就將低代碼平臺推崇的如下映射條件：

從「非專業人員組裝的模塊」到「應用」

變成了：

從「非專業人員組裝的模塊」到「程序員的補丁代碼」再到「應用」

那這個應用的后續迭代，是不是也得程序員介入？這成本不又回來了么。

如何協作開發

現在我們假設，有個巨牛逼的低代碼平臺，非常好用，極大提升了開發效率。

老板一看，員工閑下來了，這不比股市跌了還讓人難受。

于是，馬上拍腦袋安排新的需求開發。開發人員不夠用了，怎么辦？招人。

這些人如何在低代碼平臺協作開發呢？難道再把Git的概念引入平臺？

如何測試

是個應用就會有bug。低代碼平臺再完善，能夠解決模塊自身的單測，但E2E測試誰來做？財務么？

思路要打開

上述林林總總的問題，隨著項目復雜度上升、維護時間變長后都會出現。

那該如何解決呢？在這里插個眼，有緣人知道答案請告訴我。

如果解決不了，那我們換個思路，如何才能不讓項目復雜度上升？不讓項目維護時間變長？

那就限制低代碼平臺的應用場景，比如：

• 開發營銷活動頁的低代碼平臺。
• 開發企業官網的低代碼平臺。

讓我們思路再打開下，平臺開發出來是為了賣錢的，只要用戶在意識到上述問題前把錢收了，不就行了？

搞互聯網的不好忽悠，那我們可以助力傳統企業數字化轉型嘛。20分鐘就給你搭出個官網，這轉型速度，未來可期啊。

請，轉賬付費。

理想的低代碼平臺

平臺型低代碼很難跑通，但是工具型低代碼卻有很好的前景。以React舉例。

在使用React?前，前端開發者直接操作DOM?。有了React后，「業務的前端邏輯」被封裝到名為「組件」的模塊中。

接下來，React?提出了Server Components，組件可以在服務端運行。

這一步將「業務的服務端邏輯」也封裝到「組件」中。

同時，Hooks在前端可以與「視圖狀態」掛鉤，在后端可以與「微服務」掛鉤。

這種基于「組件」、「Hooks」的「低代碼工具」，你喜歡么？