低程式碼平臺

低程式碼應用平臺（LCAP - Low Code Application Platforms）在多樣、複雜的現代軟體開發情勢下應運而生。根據 Gartner 的資料，Mendix 是這方面的翹楚，但其實類似的分析也適用於 Outsystems、Appian、Kony、Betty Blocks 以及其他低程式碼平臺。

在向企業高管行銷時，LCAP 們會號稱業務人員（也有說市民開發者，非專業開發者）就能構建企業級的解決方案。那麼，後來專業開發人員都失業了嗎？我們知道並沒有，反而幾年後 Mendix 推出了面向專業開發者的版本：

我猜測 Mendix 後來也意識到任何比基本的增刪改查複雜的事情都需要一個軟體工程師，就好像除了給輪胎打氣之外的汽車維修工作都是需要專業人員一樣。

那麼，長期依賴低程式碼平臺對業務業務發展來說，究竟有何利弊，下面我們將做一些分析。

非常適合原型開發

事實上，低程式碼平臺對開發簡單的自動化商業流程、或者交付可執行的原型系統來說，是業務開發人員不錯的選擇。在一個視覺化的設計器中定義資料模型，使用內建的元件、模板來設計腳手架互動UI，甚至可以使用特定的工作流元件描述業務邏輯，例如 Mendix 使用的 microflow：

完成之後，可以將設定好的應用一鍵部署到低程式碼的雲上執行（低程式碼一般都有云服務）。看上去簡單並且易操作，很多時候，這種神奇的演示會讓高管願意買單。

但是，當你的系統從原型階段升級到真正的業務階段時，使用者互動和業務邏輯會不可避免的越來越複雜。為了避免把系統搞得一團糟，此時，你亟需一個專業工程師來繼續推進專案。

那麼，從專業開發人員的角度看，又如何呢？

低（慢）程式碼

以 Mendix 為例，使用時，任何邏輯（包括計算和使用者互動）都需要用一個 microflow 來描述，如上節中的圖示。這裡就有一些問題。

首先，想象一下，拖動、設定，然後將十幾流程環節連線起來，不但繁瑣，還容易出錯，相比同樣的邏輯，開發者只需要在好用的 IDE 裡敲十幾行程式碼，相比之下，低程式碼反而成了慢程式碼。而業務規模上去以後，你的 microflows 不可避免的多到難以管理。

其次，可讀性。這種流程圖看上去很不錯，但是第一個框框裡的 Sub_RegistrationValidation 呢？不跟進去根本無法閱讀。

權宜之下，Mendix 提供了 Java Action。你可以在一個 microflow 中呼叫 Java 方法（但是由於雲部署的限制，對這些 Java 方法也有嚴格的限制）。它支援在 Eclipse 中編寫 Java 程式碼，儘管更多人選擇更優秀的 IntelliJ IDEA。另外，程式碼的透明度也是一個風險 - Java 程式碼的入口都在 microflows 中，所以偵錯、跟蹤都變的複雜了，邏輯和流程分散在兩處。

最後，在版本控制方面，Mendix 提供了基於 Subversion 的版本控制（開發者熟悉的 Git 還處於 Beta 階段）。

低技術要求

業務人員即可完成系統的設定，降低了對技術的要求。對業務主管來說可能很不錯，不再需要昂貴的、難找的專業開發者了。但事實可能不是這樣。當你真的需要一個專業開發人員時，就會苦惱如何找到一個好的開發人員，因為對於專業的工程師來說，使用低程式碼平臺意味著職業生涯的結束。

不可控

任何熟悉 Java 生態的人都不會低估開源的能量。當有一個異常丟擲時，你能看到發生異常的程式碼，也能通過偵錯來看發生了什麼，你能 Baidu，也能提一個 PR。最壞的情況下，你可以 fork 整個開源專案。這些都是可控的。

而使用低程式碼平臺，這就不用想了。低程式碼平臺是一個商業權屬的產品，對使用者來說，呼叫棧完全不可見。一旦出錯，只能選擇付費的售後支援，或者祈禱在某個討論群有人遇到過同樣的問題。無論是付費支援或者討論群，這種方式對知識並沒有形成積累（或許是不願意將產品的暴露的問題留下證據？），這與開啟搜尋引擎直接貼上 Java 呼叫棧然後敲回車的體驗可差遠了。

供應商鎖定

使用低程式碼的一個關鍵問題是，你實施的業務邏輯執行在供應商提供的產品內。由於供應商使用的特定資料庫、特定流程元件、特定的業務邏輯編寫方式，所以很難將已有業務遷移至其他平臺。

Mendix 可能是被經常問到這個問題，他們釋出了一篇文章來解釋如何解除鎖定。其中提到了，你可以拿到你的資料、SQL DDL，UI 資源和 Java 程式碼（microflows 可以神奇地轉為 Java 程式碼）。但是，這些程式碼可以脫離 Mendix 的執行庫和 API 獨立編譯或者執行嗎？很顯然不行，你需要自己重新編寫系統執行的框架，你拿到的，僅僅是你原來就有的模型和業務邏輯。因此，基於低程式碼平臺構建的系統，系統本身並不屬於你，你有使用權，而無所有權。

擴充套件性受限

Mendix 的目標客戶是大型企業，所以「擴充套件性」在他們的市場材料中被多次提及。2017年他們引入了「stateless runtime」的概念，並支援業務節點的叢集部署，所有對談資訊既存在使用者端，又持久化到資料庫。理論上，業務節點的橫向擴充套件將沒有上限。聽起來很棒，但有一個問題 - 資料庫。

資料庫通常是企業級應用的瓶頸所在。在叢集的無狀態 Mendix 服務後面是用什麼在儲存資料呢？就是關係型資料庫。Mendix 使用的是 PostgreSQL。在叢集部署的架構中，要求所有的業務節點都連線至同一個資料庫。

如果控制權在自己手裡這樣也可以接受。Oracle 及其他資料庫已經證明了 RDBMS 是可以橫向擴充套件的，可以優化 DB 結構、快取資料或者使用 Citus 這樣的方案來做擴充套件。但問題是使用低程式碼平臺後，資料庫並沒有掌握在你的手裡。最終，平臺的擴充套件性上有所限制並且無法提供對效能進行微調的引數。

價格

最後還得說一下價格問題。由於低程式碼平臺涉及的開發量很小，因此，一般都是以系統的使用者人數和部署方式收取授權費用。公有云部署相對便宜，私有部署相對昂貴。對於幾千內部使用者的大型企業，每年的費用要超百萬。而這個費用，僅僅只能算是使用費或者租賃費。

LCAP 的流行

通過上述分析，我們可以看到，低程式碼平臺的缺點應該說是遠遠大於能提供的便捷性的。但是為什麼 LCAP 還是那麼流行，甚至一度站上創業的風口呢？

在大型企業機構中，對專業軟體工程師團隊的管理（不論是內部團隊，還是外包團隊），目前看來有些過於複雜。由於需要軟體團隊負責不同部門、不同系統的實施，而交叉管理的技術負責人和專案負責人又有各自的預算和任務優先順序，造成工作互相推諉、或者難以合作，最後導致各自的想法都很難實施。而有意思的是，面對這種複雜的情況，高階管理人員的下意識對策是招聘更多的開發人員和一線經理。毋庸置疑，情況會越來越糟。最後，企業高管會因此尋求那種神奇的、能解決所有問題的解決方案，比如，低程式碼平臺。

如何避免這種情況的出現不是本文需要討論的內容。但這也只是一個管理問題，而非技術問題。團隊管理的最終結果如果能讓 3~10 個具有相當資質的開發人員全力投入一個專案，並且能與直接拍板的人溝通，那肯定能獲得更快、更便宜的產出。

其他選擇

軟體開發方面，根據使用工具的不同，可以分為三個等級：傳統開發、使用少程式碼平臺開發、使用低程式碼甚至零程式碼平臺開發。這幾個選擇的比較如下：

我們可以看到，傳統開發的優勢是自主研發度和自由度非常高，並可以實現任何想要的功能，但是代價就是開發速度慢。而低程式碼（零程式碼）平臺，在開發速度（T2M）上無人能敵，缺乏的是系統的靈活度和自主度。少程式碼平臺則兼顧了開發效率、自主度和靈活度。以 Jmix 為例，構建在開源的 Spring Boot 之上，結合 IntelliJ IDEA 提供快速的視覺化開發工具，並無縫整合擴充套件元件提供開箱即用的功能。對於開發人員而言，這類平臺可能是 LCAP 的最接近的替代方案，同時仍然提供靈活性和便捷的開發過程。

因此，可以根據專案的需求、團隊的情況和偏好選擇開發方式，然後再選擇具體的框架、平臺。

總結

低程式碼平臺很適合開發原型或者演示系統，直接提供了面向業務人員的 IT 系統，並提供結果的視覺化展示。這種場景下，由於參與的人很少，因此成本也很低。

但是不建議在複雜且多使用者的業務系統中使用低程式碼平臺，一方面隨著複雜度提高，開發速度會變得更慢且難以管理，而另一方面，使用者數量大使得每年的「使用費」居高不下，並且系統難以遷移和替換。

只要人工智慧還沒有替代程式設計的工作，企業軟體就應該由專業開發人員來構建。因此，設定一個可到達的目標，組建一支精幹的小型團隊，聘請有能力的領導，讓他們自己選擇工具，並且融入業務領域，你的想法將很快實現！

如果對我們提供的內容有意見或者建議，歡迎聯絡我們：
blog：https://blog.abmcode.com
wechat：abmcode_gh