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

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

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

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

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

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

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

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

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

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

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

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

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

表單驅(qū)動的局限同樣明顯

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

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

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

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

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

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