給程式設計師的低程式碼平臺為什麼必須“死”？

編輯導讀：低程式碼平臺分為兩種，一種是面向業務人員的，一種是面向程式設計師的。這兩個流派面向不同的群體，產品形態也不同。本文作者認為，低程式碼平臺並不能解決程式設計師的效率問題。一起來文中看看吧。

一、低程式碼的流派之爭

從低程式碼誕生之日起，就有了渭涇分明的兩種流派。一派追求顛覆式創新，希望透過類0程式碼的產品，直接觸達業務人員，打造出一種無須IT即可將業務數字化的全新體驗；另一派希望為程式設計師提供一站式的程式設計輔助，提高專案交付效率。

具體的各流派產品形態分析，可以參考我之前的文章《一文看懂低程式碼的現狀、打法和挑戰》。

二、兩派低程式碼提供的產品價值

今天，我們再來引入一個產品分析的經典公式。

產品價值=現有產品體驗+最佳化體驗-使用者遷移成本-使用者觸達成本。

由於這兩個流派的產品本就針對不同的使用者群體，而“使用者觸達成本”這個變數很大程度取決於企業DNA和渠道優勢領域，因此很難進行平行對比，我們再對這個公式進行一下簡化：

那麼，這個公式裡最重要的兩個變數就是“產品最佳化體驗”和“使用者遷移成本”，讓我們以這兩個變數為錨點來拆解一下這兩個流派的產品，分別為使用者提供了怎樣的價值。

首先，來看0程式碼產品。主要物件是業務人員或B端產品運營，瞄準的是原本標準化的SaaS場景和一些SaaS尚未覆蓋，但由於投產原因也被IT忽略的長尾需求。

在我們實際產品推廣實踐過程中，由於瞄準的是使用者之前尚未被滿足的需求，提供了一種全新的產品體驗來如此高效的完成業務數字化，業務使用者普遍對此比較興奮，因此，“最佳化產品體驗”這一項可以加上1分。

由於提供的是一種全新的產品體驗，不存在客觀意義上的使用者遷移問題，但考慮到低程式碼市場還處在較為早期階段，仍然需要投入較大使用者教育成本，因此，“使用者遷移成本”這一項可以減去0.5分。

現有產品體驗我們統一定義為1分，那麼對於0程式碼產品的“產品價值”得分就是：1.5分

接下來看針對程式設計師的低程式碼產品，我們先來拆解一下這類產品的使用者使用路徑，就以透過阿里宜搭搭建一個相對複雜的業務系統為例。

第一步，定義頁面：拖拉拽元件，完成頁面構建（同時也定義了表及表字段）

第二步，定義流程：透過流程表單頁，拖拉拽事件元件，定義業務所需流轉流程

第三步，定義邏輯物件，及觸發動作：選擇元件屬性，繫結為變數

第四步，串聯邏輯：在JS面板，以函式方法的形式完成整個應用頁面間邏輯串聯

第五步，上線：點選上線按鈕，完成應用的一鍵上線

帶著這個使用路徑的實戰體驗，讓我們再次回到那個公式。

“最佳化產品體驗”這一項帶來的提升主要體現在前端頁面搭建的提效，根據我們的實際對比試驗，就以標準表單頁+列表頁搭建為例，視覺化拖拉拽相比程式碼層級的複製貼上，提效比較明顯大約4-5倍，我們來先記5小分。

但同時，這個新的路徑中也帶來了一些“負最佳化”體驗，主要體現在定義邏輯物件和邏輯串聯兩個環節。我們試圖搭建一個案件工單處理系統的過程中，寫了約500行JS程式碼，定義了超過50個變數，每一次的定義變數都要經歷“選中元件”-“選中屬性”-“定義變數”-“繫結變數”的迴圈，操作效率低下的同時，由於變數較多，將變數與元件唯一標識對應也是非常讓人痛苦的，用我們直接上手前端開發同事的話來說就是“把節省的時間又吞回去了”，加上JS程式碼編寫過程中的互動體驗以及無法實時除錯等問題，這裡需要再減去4小分

最後，開發提效低程式碼產品“最佳化產品體驗”這一項綜合得分為1分。

“使用者遷移成本”這一項是面向開發人員低程式碼平臺的主要減分項。傳統開發除了需要遵循企業研發管理CI/CD的制度規範、安全及測試相關要求，還有一個最重要的因素——整合開發IDE工具。

根據Stack Overflow2021全球開發者調查報告的結果，VSCode繼續蟬聯榜首，獲評最受喜愛的整合開發IDE工具。自2011年微軟邀請Erich Gamma開始孵化Monaco Editor（VSCode前身，2015年移植到桌面平臺後更名VSCode），到2018年VSCode首次登榜，走過了7年的漫長時光，這期間不斷進行著市場教育、產品使用者相互塑造的過程。即便在VSCode霸榜多年的今天，身邊很多Java開發朋友依然在堅定的選擇IntelliJ和Eclipse。由此可見，對於一款毋庸置疑的生產效率工具，要想完成使用者遷移的挑戰是十分巨大的，更何況Web端IDE還不得不面對一些瀏覽器效能的客觀邊界，行業龍頭Mendix也不得不選擇自研本地IDE編輯器這種相對“笨重”的方式，來對沖這個問題。

由此可見，出於對原有生產效率工具挑戰這一原因，“使用者遷移成本”這一項我們來減去5分。

現有產品體驗我們依然定義為1分，那麼對於面向開發低程式碼平臺的“產品價值”得分就是：-3分

從我們天使使用者焦點小組訪談中獲得的資訊也同樣印證了這一點。

使用者表示“如果是以搭建一個重業務邏輯的複雜系統來講，前端頁面視覺化拖拉拽帶來的提效放在專案的全景中不值一提，而其他的體驗相較於十分熟練的IDE工具，是非常令人絕望的”。

相較於0程式碼平臺給業務人員帶來的“驚喜地”完整解決方案，低程式碼平臺的部分提效以及伴隨的“負體驗”和巨大遷移成本，確實無法提供較高的產品價值。

那麼，除了低程式碼平臺，究竟應該如何給程式設計師提效呢？

三、程式設計師需要什麼樣的提效產品

要想最大程度提高產品價值，我們還是要回到之前的公式，“使用者遷移成本”是效率工具產品的最大挑戰，無論你提供怎樣優秀的新體驗，都可能被遷移成本輕易的打回原形，因此面向程式設計師的程式碼級提效工具最好是維持以本地IDE為核心的產品形態，儘量少或不對使用者構成遷移挑戰，以便於我們更好的在“最佳化產品體驗”條線進行發力。

這裡列舉了一些程式設計師在專案開發中會面臨的關鍵節點，如果從一個全景視角來看，會發現有這樣的幾個特點：

“神聚而形散”：從抽象的角度，研發過程的確逃不出這樣幾個關鍵節點，但針對不同專案特點、團隊規模以及企業研發管理要求不同，各個節點從工具選擇、產出形式都沒有明確的標準；
“傻活比重不小”：再整個研發過程中，除了令人興奮的創作性工作，還存在不少重複的“傻活”。例如無趣的環境搭建、反反覆覆不知道寫了多少遍的通用樣式、常用介面。
“依賴人治”：研發過程中程式碼規範很依賴程式設計師的個人能力以及熟悉程度，人員流動造成的衝擊大

基於這樣的分析，我們對於要解決的問題和目標的產品形態應該有一個大致的概念了：