低代碼平台 – 危險的賭注
低代碼應用平台（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：//blog.abmcode.com
wechat：abmcode_gh
