使用低程式碼平臺 - 危險的賭注

低程式碼應用平臺（LCAP - low code application platforms）在多樣、複雜的現代軟體開發情勢下應運而生。依據Gartner（高德納，全球最具權威的IT研究與顧問諮詢公司）的資料，

Mendix

是這方面的翹楚，所以允許本文將它做為參照。但其實類似的結論也適用於 Outsystems、Appian、 Kony、 Betty Blocks 以及其他平臺。

在向高管推銷時，LCAP 們會號稱業務人員（即非專業開發人員）就能構建企業級的解決方案。那麼，後來專業開發人員都失業了嗎？事實是 - 幾年以後 Mendix 承認：專業開發人員比以往更需要。見下圖。

好尷尬呀！我猜測 Mendix 意識到任何比基本的 CRUD 複雜的事情都需要一個軟體工程師，就好像除了打氣之外的汽車維修工作都是需要專業人員一樣。

不幸的是，當下的低程式碼平臺並不是給專業開發人員設計的。並且長時期的依賴低程式碼平臺對業務來說是危險的賭注。下面我來解釋其中的原因。

做原型開發很贊

事實上 Mendix 對開發簡單的自動化商業流程、或者交付可執行的原型系統來說，是業餘開發人員不錯的選擇。在一個視覺化的設計器中定義資料模型，使用內建的元件、模板來設計腳手架互動UI，甚至可以使用 microflows（microflow 類似於 Java 中的方法，有入參，出參，可在裡面做迴圈，判斷等等）描述業務邏輯：

完成之後，可以把應用一鍵部署到 Mendix 雲上，然後執行。看上去簡單而有魔力，這足夠讓企業高管籤支票。

但是，當你的應用過了原型階段，使用者互動和業務邏輯會不可避免的越來越複雜。這個時候，為了避免結果一團糟，你將需要一個專業工程師來推進專案。

所以下一步，我們從專業工程角度來看。

低（慢）程式碼

用低程式碼平臺的時候，任何邏輯 - 包括計算和使用者互動 - 都需要用一個 microflow 來描述，如上節中的圖示。這裡就有一些問題。

首先，會慢。想象一下，拖動、配置，然後將十幾個模板連線起來，相比於在好用的 IDE 裡敲十幾行程式碼。 規模上去以後，你的 microflows 不可避免的多到難以管理。

其次，可讀性。模板看上去很妙，但是後面的 Sub_RegistrationValidation 呢？不跟進去根本無法閱讀。

權宜之下，Mendix 提供了 Java 操作。你可以在一個 microflow 中呼叫 Java 方法（但是由於雲部署的限制，對這些 Java 方法也有嚴格的

限制

）。你可以在 Eclipse 中寫好 Java 程式碼，儘管更多人選擇更優秀的IDE - IntelliJ。透明度是一個風險 - Java 程式碼的入口都在 microflows 中，所以除錯、跟蹤都變的複雜了。邏輯流程分散在兩處。

最後不得不提的一點是版本控制。好訊息是確實有這方面的版本控制軟體，壞訊息是它是 Subversion 的一個受限制的子集。跟 git 再見吧。

不可控

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

用 Mendix 的話就什麼都別想了。它是一個商業權屬物，呼叫棧裡是個黑盒子。你可選的只有付費的售後支援，或者祈禱上天能在

社群

獲得回答，每月大概200個問題，與

stackoverflow

上帶 Spring 標籤的問答數目比比？

銷售商鎖定

Mendix 可能是被經常問到這個話題，他們釋出了一篇

文章

來解釋如何解除鎖定。如果仔細閱讀，它提到了：

你可以拿到你的資料、DDL，UI 資源和程式碼（microflows 可以神奇地轉為 Java 程式碼）。

那麼你拿到的程式碼可以脫離 Mendix 的執行庫和 API 獨立編譯或者執行嗎？事實上，這需要重寫整個系統。你被鎖在一個商業權屬物平臺上，你甚至不擁有你構建的系統。

擴充套件性受限

Mendix 的目標客戶是大型企業，所以“擴充套件性”在他們的市場材料中被多次提及。2017年他們引入了“stateless runtime” - 無狀態執行時，所有會話資訊即存在客戶端，又持久化到資料庫。理論上，橫向擴充套件將沒有上限。聽起來很酷，但有一個問題 - 資料庫。

資料庫通常是企業級應用的瓶頸所在。在叢集的無狀態 Mendix 服務後面是用什麼在儲存資料呢？沒有驚喜 - 就是關係型資料庫。 Mendix 使用的是 PostgreSQL。Mendix 沒有快取，而且它生成的 DDL 是有問題的，比如，我見過對一個 1：N 的關係生成了一張 N：M 的臨時表。

如果控制權在自己手裡這樣也可以接受。Oracle 及其他資料庫已經證明了 RDBMS 是可以擴充套件的，你可以最佳化 DB 結構，快取資料或者使用 Citus 這樣的方案來做擴充套件。但問題是使用 Medix 的話控制權不在你手裡。

唯一可行的是使用只讀複製（如 Amazon RDS），但這個對寫資料沒有幫助。

總結，存在基礎上的擴充套件限制，並且缺少微調效能的選項。

降低（提高）技術要求

降低技術要求對主管來說聽起來很美妙，昂貴的、難找的專業人員不再需要了。實際上，這是一個壞招。當你真的需要一個專業開發人員時，就會苦惱如何找到一個好的開發人員，因為對於專業的工程師來說，使用低程式碼平臺意味著職業生涯的結束。

價格很美麗

最後但並非不重要。一個

單應用授權

最低 $1875每月，限於50個內部使用者，並且最少購買三年。可以部署到 premises 的企業授權最低 $7825，幾乎$100K（10萬$）每年。所以一個有幾千內部使用者的大型企業每年大概需要幾百萬美元。

並且要注意的是依據以上討論，我們只是針對相對比較簡單的應用。這對我來說很瘋狂了。這個定價下，你還不能自己釋出你自己構建的應用。

那為什麼LCAP還如此流行？

在我看來，答案令人沮喪。在大型機構中管理工程師團隊 - 無論是內部還是外部 - 目前來說都過於複雜。預先進行預算規劃，相關人員（架構師或者直線經理）各自有各自的議程，缺乏責任感等等。 所以推進、實現自己的想法很難。更有趣的是，管理人員下意識的應對策略還是僱用更多的開發人員，當然還有更多的經理。毋庸置疑，這會使情況變得更糟。我知道有幾家擁有超過10，000（！！！）個開發人員的銀行，我還知道里面至少有一半的人在從事無用的工作。 令人絕望的是，企業高管因此尋求那種神奇的、解決所有問題的解決方案，例如LCAP - 低程式碼應用平臺。

如何擺脫這一團糟是另一篇文章的主題。 但這是一個管理問題，而不是技術問題。 跳過所有細節，如果你能讓3-10位具有相當資質的人員全力開發，並能與相關人員和決策者直接溝通，你將獲得比想象中的更快、更便宜、出色的結果。

有其他選擇嗎？

如今，開發人員工具和框架有很多選擇。 例如，Spring Framework 是最流行的企業軟體開源框架，可以與 React 或 Angular 等 Web 框架很好地結合在一起。 在過去幾年中，

Spring Initializr

和

JHipster

之類的工具使上述操作變得更加容易。

如果你需要更快的結果和更容易採用的方法，那麼

CUBA Platform

之類的RAD工具非常值得考慮。 它建立在 Spring Framework 之上，並透過視覺化開發工具和無縫整合擴充套件外掛市場進行補充。 對於開發人員而言，這可能是 LCAP 的最接近的替代方案，同時仍然提供靈活性和便捷的開發過程。

因此，有很多選擇，如何選擇應取決於任務、團隊技能和偏好。

總結

低程式碼平臺用來開發原型很贊。 它們將業務相關人員和 IT 連線，使結果視覺化，促進雙方更快地達成一致。 由於參與人員很少，所以成本也很低。但也只能到此為止！

否則，繼續使用下去，開發速度將減慢，你將越來越多地陷入又貴又限制諸多的商業權屬平臺中。

只要 AI 還沒有替代我們工作，企業軟體就應該由專業開發人員來構建。 因此，設定一個可到達的目標，組建一支精幹的小型團隊，聘請有能力的領導，讓他們自己選擇工具，並且不要忘記將他們納入業務領域。 很快地，你將看到你的想法逐漸成形！