低代碼平臺設(shè)計的邊界問題
最近在研發(fā)低代碼平臺產(chǎn)品，研發(fā)的過程中的一些思考在這里記錄一下。
與低代碼（low-code）相對應(yīng)的幾個概念：
1. 背景
低代碼平臺面向不同的領(lǐng)域也有不同的細(xì)分，本文以我正在研發(fā)的企業(yè)經(jīng)營管理領(lǐng)域的低代碼平臺為主要討論對象。
平臺的目標(biāo)用戶
企業(yè)信息化項目外包團(tuán)隊
企業(yè)IT部門
企業(yè)管理層
以上三種用戶其實可以歸為兩類，一類是有一定編程能力的技術(shù)人員，一類是沒有編程能力的管理人員。
這里一定要強調(diào)技術(shù)人員是“有一定編程能力”的，而不是超高編程能力的，因為超高編程能力的人也許不愿意受到平臺的束縛，他們更愿意用庫來搭建自己的系統(tǒng)。
而管理人員既是管理系統(tǒng)的用戶，也是管理系統(tǒng)需求的源頭，如果能夠讓他們通過平臺對管理系統(tǒng)進(jìn)行一些簡單的定制（如字段級的調(diào)整）能夠節(jié)省大量的溝通成本。
這兩類用戶在平臺的視角下，都是一個最終系統(tǒng)的開發(fā)者。
2. 低代碼平臺的邊界
概括來講低代碼平臺是為用戶賦能的。
何為賦能？這里的賦能不同于管理學(xué)和心理學(xué)中的概念，在這里是”賦予能力“的意思：平臺為用戶提供開發(fā)應(yīng)用的能力。
必要的局限性
這種能力注定是有局限性的，因為無論何種低代碼實現(xiàn)，都是在提煉經(jīng)驗的基礎(chǔ)上隱藏“不必要”的復(fù)雜性，而這個“不必要”是在特定領(lǐng)域中基于"經(jīng)驗“的共識。這個“不必要”并不能通過純理論檢驗，也就是說總會有“黑天鵝”的。
舉例來說，通過 JSON Schema 生成表單是一種很常見的低代碼實踐。
JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.?
JSON Schema 是一種用于標(biāo)注和驗證 JSON 文檔的詞匯表。
考慮到 JSON 格式與 JS 語言是天生的一對兒，而 JSON Schema 也是匯集了眾多智慧的通行規(guī)范。那用 JSON Schema 來反推數(shù)據(jù)的輸入方式并形成表單，也是很自然事情。
但是 JSON Schema → 表單之間顯然還缺少一些東西，比如設(shè)定了最大值和最小值的數(shù)字類型，你可以用一個增加了輸入限制的input（或者各種UI庫的NumberInput），也可以是一個定制的滑塊輸入方式。
那好，我們增加一個擴(kuò)展語法（當(dāng)然可以通過可視化的設(shè)計器來編輯），用來指定 JSON Schema 各輸入項的控件，這樣是不是就能彌補了？
是的，能彌補一部分。
表單的布局呢？
生成這種布局的表單并不難，但是如果我們要把其中的一些字段放在同一行上呢？比如上圖中的Activity zone 和 Activity time，我要放到同一行上。
當(dāng)然解決這種情況也不難，讓擴(kuò)展語法支持設(shè)置表單項的寬度就好了。
那如果要讓表單支持對字段進(jìn)行分組，并且要為分組增加描述呢？
這里有兩種情況：
一種是JSON Schema本身就是以這種結(jié)構(gòu)描述的，也就是說前后端的接口定義上，基礎(chǔ)設(shè)置、流量規(guī)則、出價和排期方案、推廣對象這四組數(shù)據(jù)各自都是一個object類型。這種情況其實通過一個遞歸/遞推結(jié)構(gòu)就可以解決了。
另一種情況是JSON Schema本身是扁平的，但是為了提供更友好的表單界面，在前端人為的分組，或者同一組數(shù)據(jù)要在不同的角色的視角下要有不同的組織方式，這都是很常見也很合理的訴求。這時候擴(kuò)展語法就不夠用了，你需要一個獨立的定義，能夠?qū)Ρ韱巫侄蔚闹夭季帜芰Α?/p>
更多的問題
那要在表單項之間增加一段文字、圖片甚至視頻用以指導(dǎo)用戶錄入操作呢？
一個表單項要根據(jù)其他表單項聯(lián)動顯示和隱藏呢？
后分組的表單項要根據(jù)其他表單項聯(lián)動顯示和隱藏呢？
表單項需要異步檢查合法性呢？
多個表單項的值要聯(lián)合計算更新呢？
要做向?qū)降谋韱文兀?/p>
不可能三角
當(dāng)然這些技術(shù)上都可以實現(xiàn)，但是回到最初的關(guān)鍵字“不必要的復(fù)雜性”，這里面哪些是必要的復(fù)雜性，哪些是不必要的？這里不得不考慮用戶使用成本問題，復(fù)雜度到了一定程度之后，直接寫代碼反而效率更高。
而且平臺設(shè)計的太復(fù)雜了意味著引入了更高的學(xué)習(xí)成本，這個學(xué)習(xí)成本不一定是用戶愿意付出的。
對于技術(shù)人員而言，學(xué)習(xí)低代碼平臺中的使用是一種特定領(lǐng)域的知識，這種知識不能給他帶來編程技術(shù)水平的提升。在上面的例子中，最初的通過 JSON Schema 來生成表單的想法無非是想借助通行的標(biāo)準(zhǔn)來白嫖一些學(xué)習(xí)成本和一些使用成本。
對于管理人員而言，做這種復(fù)雜程度的操作太耗費時間，還不如交給專業(yè)的人來做。
如果用可選的方式隱藏復(fù)雜性呢？
這也分三種實現(xiàn)方式：
平臺把所有可能性劃分等級，大多數(shù)時候只暴露最常見的部分，其他部分在打開了高級選項之后向資深用戶提供。 這種做法依然有用戶愿不愿意投入學(xué)習(xí)成本的問題，并且窮舉所有的可能性這件事本身就是一個近乎不可能的任務(wù)。在低代碼平臺研發(fā)的初期，投入太多精力做這種工作顯然是得不償失的。
平臺以生成靜態(tài)代碼的形式向用戶提供無限的定制能力。 這種做法的問題是平臺能力是一次性的，生成的代碼被修改后，平臺設(shè)計器難以將用戶代碼同步回來。
平臺劃清明確的能力邊界，在邊界外終極定制能力，嵌入用戶代碼（埋點、插件、替換）。 比如在上面的例子中用戶可以直接設(shè)定一個Vue/React組件或者頁面來全權(quán)接管平臺的表單。在這個基礎(chǔ)上，也許還可以把平臺的實現(xiàn)暴露成可復(fù)用的組件，并且這個組件符合通行標(biāo)準(zhǔn)，技術(shù)人員可以把平臺的實現(xiàn)以Vue/React組件的方式引入到自定義頁面中，并通過注入插槽和為內(nèi)部組件注入屬性的方式來實現(xiàn)精確復(fù)雜的定制（但這種形式的可行性也是存疑的，畢竟依然會引入平臺特有的技術(shù)特性）。
綜上，低代碼平臺是為開發(fā)者賦能的，這種能力是快速開發(fā)一個質(zhì)量穩(wěn)定的應(yīng)用系統(tǒng)的能力，但是這種能力終究是要有邊界的，否則無異于重新發(fā)明一門沒人愛用的通用編程技術(shù)。
3. 邊界之外
低代碼平臺可以承托軟件質(zhì)量和開發(fā)效率的底限，但不一定能抬高上限。
低代碼平臺不能抬高上限，但也不該成為上限的天花板。
把開發(fā)者從重復(fù)性勞動中釋放出來，讓他們能夠投入到創(chuàng)造性的工作中去（而不是從一種重復(fù)性勞動變成另一種重復(fù)性勞動），對于低代碼平臺和開發(fā)者而言都是一件幸事。
