當業務變復雜，低代碼系統還能撐得住嗎？

去年我們部門接了個內部系統升級任務，要把原來用某低代碼平臺搭建的供應鏈審批系統，改造成能支撐多事業部、跨境業務的新平臺。這個舊系統已經跑了三年，初期確實幫我們快速上線，但后來問題越來越多。這次改造讓我們徹底想清楚了一件事：低代碼平臺有它明確的能力邊界，越界就是災難的開始。

一、項目起點：低代碼為什么被選中

五年前，公司只有一個事業部，采購流程簡單：申請→部門經理批→采購執行。當時IT人力緊張，業務方急著要系統，就選了當時流行的低代碼平臺。

快速搭建是最大優點：拖拽表單、配置審批流，兩周就上線了。初期效果很好：

??流程變更時，業務管理員自己就能調整，不用找IT

??基礎的數據報表直接生成

??移動端適配自動完成

二、問題開始浮現：復雜度增長超出預期

第二年公司開了新事業部，業務模式不同，審批流程開始分化：

1、流程分支爆炸：原來3個節點的流程，變成十幾條分支規則

2、數據關聯復雜：需要關聯庫存數據、供應商歷史評價、合同條款

3、權限需求細化：不同事業部的人只能看到特定數據，同部門還有數據隔離

這時候我們發現，低代碼平臺的“可視化配置”開始變得笨重。要在界面上配置一個包含20個條件的審批分支，操作繁瑣且容易出錯。更麻煩的是，有些業務規則用平臺提供的邏輯組件根本實現不了。

三、遭遇硬性技術限制

到了第三年，問題從“難用”變成了“無法實現”：

性能瓶頸明顯：當單表數據超過50萬條，平臺生成的查詢效率急劇下降。我們試圖優化，但無法控制底層SQL生成邏輯。平臺提供的“優化選項”很有限。

集成成本變高：需要和外部供應商系統對接，對方提供的是標準API接口，但低代碼平臺要求按特定格式封裝。我們不得不在中間加了一層自研的適配服務，反而增加了系統復雜度。

定制化需求無處安放：業務需要復雜的成本分攤算法，涉及多個系統的數據實時計算。低代碼平臺的處理方式是定時任務跑批，但業務要求實時性。平臺的計算引擎不支持我們寫自定義算法。

四、我們嘗試的補救措施

在決定重構前，我們嘗試了幾種方案：

1、混合開發模式：在低代碼平臺外部開發復雜功能，通過接口調用。結果是系統被拆得七零八落，維護更困難。

2、購買高級版：升級到平臺的企業版，確實多了些功能，但核心限制還在。而且鎖定效應越來越明顯：代碼完全依賴平臺，想遷移都難。

3、二次開發繞路：用平臺提供的“自定義代碼”模塊寫復雜邏輯。但這帶來新問題：調試困難、版本管理混亂、性能更差。

真正讓我們下決心重構的，是下面這個具體場景：

財務部門需要動態計算采購預算占用，規則是：已審批未執行的訂單占70%，已執行未入庫的占100%，還要考慮匯率波動(跨境采購)。我們在低代碼里用盡了各種辦法，最終實現出來的方案：

??計算一次需要15秒(業務要求3秒內)

??規則稍有變動就需要重新配置整個流程

??出錯時沒有任何有效的調試手段

五、重構方案：漸進式遷移

我們沒有一夜之間替換整個系統，那樣風險太大。而是制定了18個月的漸進遷移計劃：

第一階段：新功能用新架構

所有新增需求，只要涉及復雜邏輯，一律用自研系統實現。兩個系統并行，通過單點登錄和統一待辦銜接。

第二階段：核心流程逐個遷移

選擇使用最頻繁、問題最多的流程先遷移。我們選了采購申請流程，因為：

??業務影響面大，能驗證新架構的穩定性

??邏輯復雜，能體現自研系統的優勢

??用戶反饋直接，便于快速調整

第三階段：數據遷移與舊系統下線

等所有核心流程都遷移完畢，用三個月時間并行運行，最后徹底關閉低代碼系統。

六、技術選型的考量

新系統完全基于開源技術棧：

??后端：Spring Boot + 自研工作流引擎

??前端：Vue + 自研表單設計器(保留業務人員配置簡單表單的能力)

??數據庫：按業務域分庫，關鍵查詢都經過人工優化

最重要決策：保留合適的配置化能力。我們沒走回“一切硬編碼”的老路，而是：

1、簡單表單和基礎流程仍支持可視化配置

2、復雜邏輯用代碼實現，但提供清晰的接口

3、所有配置都有版本管理和回滾能力

七、遇到的挑戰和解決方式

遷移過程并不順利：

數據一致性難題：兩個系統同時處理同一類業務時，狀態同步很麻煩。我們最終引入了事件總線，任何狀態變更都發事件，由專門的服務保證最終一致性。

用戶習慣阻力：業務人員習慣了舊系統的操作方式。我們在新系統里盡量保持界面相似，同時針對痛點做改進，比如加載速度從平均8秒降到2秒內，用戶才愿意接受改變。

團隊技能轉型：原來維護低代碼的同事需要學習編程。我們安排結對編程，逐步過渡，現在他們既能寫代碼，也懂得在合適場景使用配置化方案。

八、現在的架構與反思

目前新系統已穩定運行一年多，支撐了五個事業部、每天上千條流程。總結下來，我們對低代碼的定位更清晰了：

適合用低代碼的場景：

??生命周期短的工具型應用(6個月以內)

??邏輯簡單、變化頻率低的內部工具

??需要業務人員深度參與配置的標準流程

必須用傳統開發的場景：

??核心業務系統，預期使用3年以上

??需要高性能、復雜計算的場景

??需要深度定制和集成的場景

??有長期技術演進規劃的系統

九、給團隊的具體建議

如果你也在評估或正在使用低代碼：

1、一開始就要劃定邊界：明確哪些需求可以放在低代碼里，哪些不行。最好有技術評審機制。

2、關注逃離成本：定期評估遷移到自研系統需要多少工作量，避免被平臺鎖定得太死。

3、保留數據控制權：確保核心業務數據存儲在你能直接訪問的數據庫里，不要依賴平臺私有存儲。

4、性能測試要盡早：用接近真實的數據量測試，很多低代碼平臺在小數據量下表現尚可，數據一多就暴露問題。

5、建立過渡預案：設計架構時就要考慮未來如何遷移，比如接口要標準化，業務邏輯要模塊化。

最后一點思考

低代碼不是洪水猛獸，它確實解決了“快速交付簡單應用”的需求。問題往往出在期望錯配上：期待它能做超出設計范圍的事情。

我們現在的策略是“混合架構”：標準、簡單的流程用配置化平臺(自研的輕量級平臺)，核心復雜系統用傳統開發。關鍵是保持技術選擇的主動權，不被任何平臺綁架。

做技術選型時，少看宣傳文案，多分析自己的業務在復雜性、性能、集成、演進方向上的真實需求。系統撐不撐得住，不完全取決于技術本身，而更多取決于你的使用方式是否在它的能力邊界之內。超出邊界時，及時調整架構，比勉強修補更劃算。