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