低代碼平臺 - 危險的賭注

低代碼應用平臺（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

標籤：其他

上一篇：Terraform：我可以有2個具有相同鍵但具有不同值的本地塊

下一篇：《技術管理實戰36講》學習總結