在今天，“低代碼” 技術已經(jīng)很難被描述為⼀種新興的技術服務形式了。“低代碼”這⼀概念，早在1982 年，便由 James Martin 在《無程序員的應用程序開發(fā)》⼀書中正式提出。而從90年代起，國外在不同的軟件開發(fā)發(fā)展階段中，都分別研究并嘗試推出了對應的低代碼解決⽅案。但真正的時間拐點，要來到2015年前后，隨著基礎技術設施的不斷演進，低代碼相關技術逐漸露出曙光，且微軟、⾕歌等巨頭正式⼊局，低代碼賽道正式打開。

作為⼀種商業(yè)服務，低代碼無疑是明確的，提供完善的可視化開發(fā)界面，使用戶能夠以非傳統(tǒng)開發(fā)的模式進行應用開發(fā)，從而達成低成本、高效率的應用開發(fā)。但對于真正的開發(fā)模式而言，低代碼這⼀概念卻是開放的，市面上的產(chǎn)品不論從技術方案、使用方式還是應用場景而言，都早已百花齊放。

那么，什么樣的低代碼平臺才是更適合開發(fā)者的呢？我們不妨先從國內(nèi)市面上最流行的兩種低代碼平臺形態(tài)，來聊聊當前的低代碼平臺。今天我們著重探討下表單驅動模式。 

表單驅動 - 企業(yè)信息化的新中臺

⼀般認為，表單驅動是作為 BPM 系統(tǒng)的延續(xù)者出現(xiàn)的，再向前溯源的話，更像是早期使用 Excel 來進行數(shù)據(jù)管理的做法：多個參與者按某種約定，通過在電腦上編輯、 傳遞文檔、信息或者任務，來實現(xiàn)指定的業(yè)務目標。

⼀些從 BPM 系統(tǒng)或者電子表格類產(chǎn)品轉型而來的低代碼開發(fā)平臺，⼤多延續(xù)了這種表單驅動的模式。

表單驅動型的低代碼平臺自出現(xiàn)伊始，就有著明確的客戶群體和應用場景。如果說當前哪種低代碼平臺最適合讓從未從事過軟件開發(fā)的用戶能夠快速的完成⼀款小應用的開發(fā)，那么，非表單驅動型低代碼平臺莫屬。

表單驅動型平臺的核心編輯界面其實只有兩個，表單設計與流程設計，通過對表單的設計完成對其抽象數(shù)據(jù)的建模，并同步綁定數(shù)據(jù)的創(chuàng)建/編輯界面，再借由流程設計，來定義數(shù)據(jù)的流程狀態(tài)，以及不同狀態(tài)下的可操作角色，字段的可見/可編輯權限等。

在業(yè)界的通用觀點中，“表單驅動”具有更低的使用門檻和技術門檻，但是應用場景的局限性更高，通常僅用于開發(fā)簡單的數(shù)據(jù)填報系統(tǒng)，很難應用在企業(yè)級應用的開發(fā)過程中。

在理想化的企業(yè)內(nèi)部使用場景中，該平臺會由企業(yè)中的多個業(yè)務部門同時使用，每個部門按照自己的數(shù)字化需求來設計表單，同時參與其它部門的表單填寫、流傳過程。從而使企業(yè)中的每⼀個業(yè)務相關⼈員都可以在平臺上看到與自己相關的所有表單，作為自己的⼯作任務項或關注事項。而這，也是企業(yè)信息數(shù)字化的切實需求。

為了滿足上述場景，表單驅動型的低代碼平臺的設計思路也就變得明確了。

1. 為了能夠讓企業(yè)的任意⼀個員工都能夠很快上手，平臺需要最大化的降低實際使用者的學習成本。在用戶使用過程中，需要盡量取消抽象的軟件設計過程，甚至以犧牲靈活性為代價（比如界面與動態(tài)數(shù)據(jù)的綁定設計），讓用戶能夠與企業(yè)業(yè)務做直接對應，來達成設計目的。

2. 最好是單⼀平臺 + 多個同構微應用的模式。這樣才能夠有效的聚合信息，讓企業(yè)信息流轉效率上升。單⼀的表單收集型服務（如：問卷星、騰訊問卷等）雖然也能解決信息的收集問題，但對于信息同步，以及流程控制就會顯得乏力，而這卻是企業(yè)提升信息流轉的綜合效率所不可或缺的能力部分。 

表單驅動的局限同樣明顯

1. 受限于表單與數(shù)據(jù)模型強綁定的設計與使用方式，在實際使用過程中，往往難以設計出拓展性佳、復雜關聯(lián)的數(shù)據(jù)模型。⼤量的表單，一方面會形成⼤量的數(shù)據(jù)冗余（不同的表單設計背后所映射的是相同的業(yè)務數(shù)據(jù)），另一方面⼜容易形成數(shù)據(jù)孤島（表單設計過程中的關聯(lián)性設計缺失，無法在其它業(yè)務中進⾏數(shù)據(jù)復用）。同時，由于表單與數(shù)據(jù)模型的直接對應，也使得對數(shù)據(jù)的展示、操作界面只能借由當前表單執(zhí)行，難以設計復雜的數(shù)據(jù)檢索與數(shù)據(jù)交互。

2. 表單驅動型的低代碼平臺，通常只能處理數(shù)據(jù)的采集與展示，而無法基于數(shù)據(jù)進行更為智能化、自動化的衍生邏輯設計。為了彌補缺陷，低代碼平臺往往會增加 ⼀些可編程界面，以便用戶通過代碼途徑來解決上述問題。但伴隨著編碼功能的開放，平臺用戶的體驗也會開始割裂。更真實的情況是，大量對數(shù)據(jù)建模都算不上擅長的用戶，并沒有匹配的技術能力來完成代碼的編寫。

當然，不論如何，在企業(yè)數(shù)字化場景下，表單驅動型的低代碼平臺依然能解決日常企業(yè)業(yè)務中⼤部分簡單的信息流轉需求。但是對于開發(fā)者而言，表單驅動型低代碼平臺與開發(fā)者的工作場景卻往往是互斥的。

一方面，表單驅動的目標用戶并不是開發(fā)者本⾝，甚至平臺本⾝，就是為了在企業(yè)不具備開發(fā)能力，或降低開發(fā)成本時而出現(xiàn)的。

另⼀方面，則是因為表單驅動型平臺中，應用設計模式較傳統(tǒng)軟件開發(fā)而言，進行了⼤量簡化，這導致開發(fā)者在使用表單驅動型平臺的過程中，往往有大量的軟件設計思想無法在平臺中實現(xiàn)。

⼀⾔以蔽之，開發(fā)者與表單驅動，可能真的沒有什么緣分。