近年來，“低代碼”這一概念在資本市場上愈發(fā)火熱，各種低代碼平臺項目也紛紛上馬。

然而，此類平臺的設(shè)計者與維護(hù)者們，或早或晚，終將會面對“低代碼”與生俱來的一組底層矛盾，而是否能合理地處理這組矛盾，最終決定了此平臺的發(fā)展前景。

背景

我們團(tuán)隊正在維護(hù)一套基于DSL（領(lǐng)域特定語言）的表單管理平臺。該平臺由客戶方團(tuán)隊自建，其中包含了前端UI、數(shù)據(jù)管理、表單規(guī)則管理等模塊。設(shè)計目標(biāo)是：讓業(yè)務(wù)人員以書寫DSL的方式定義表單模板，此后可以直接基于模板生成UI并管理表單數(shù)據(jù)，從而達(dá)到低代碼甚至零代碼創(chuàng)建表單的效果。該平臺自建立以來，已經(jīng)支持了數(shù)百個大型表單的成功上線，支持了公司業(yè)務(wù)的快速成長。然而隨著業(yè)務(wù)的持續(xù)發(fā)展，該平臺的疲態(tài)也日益凸顯：

• 難以支持復(fù)雜的表單需求（可用的表單組件、數(shù)據(jù)結(jié)構(gòu)、DSL語法不足，且新增成本過高）
• 平臺代碼極度難以維護(hù)
• 大型表單的性能表現(xiàn)糟糕

不可能三角

以上案例，生動展現(xiàn)了一款低代碼平臺的典型生命周期：

• 前期：平臺能力弱，但業(yè)務(wù)也簡單。平臺開始起步。
• 中期：平臺能力趨于成熟，業(yè)務(wù)逐漸變得復(fù)雜但仍在平臺能力范圍之內(nèi)。平臺支撐著業(yè)務(wù)快速發(fā)展。
• 后期：平臺觸達(dá)能力上限，部分業(yè)務(wù)需求開始超出平臺能力。

而此類平臺之所以會有如此表現(xiàn)，根本癥結(jié)在于其發(fā)展受到了“低代碼”天然自帶的一組矛盾的掣肘，該矛盾可以用不可能三角的形式加以描述：

如圖，該三角的三個頂點分別代表了低代碼平臺的三個核心設(shè)計目標(biāo)：

• Easy to Use – 易于使用
• Powerful – （功能）強(qiáng)大
• Low Complexity – 低（系統(tǒng)）復(fù)雜度

而這三個目標(biāo)形成了如此一個三角形的結(jié)構(gòu)，意味著在同一低代碼平臺上，他們永遠(yuǎn)不可能同時被滿足：

若一平臺在易于使用的同時功能強(qiáng)大，則必然擁有較高的系統(tǒng)復(fù)雜度。

其中，系統(tǒng)復(fù)雜度與維護(hù)成本成正比，與系統(tǒng)性能成反比。也即，較高的系統(tǒng)復(fù)雜度最終會導(dǎo)致平臺擁有較高的維護(hù)成本以及較低的系統(tǒng)性能。

例子：人工智能編程。用戶只需使用自然語言描述需求（易于使用），系統(tǒng)就能生成代碼（功能強(qiáng)大），但該技術(shù)至今仍未完全成熟（高系統(tǒng)復(fù)雜度）。

若一平臺易于使用的同時保持低系統(tǒng)復(fù)雜度，則必然功能受限

例子：Scratch少兒編程。使用圖形化界面編程（易于使用），指令只需經(jīng)過簡單翻譯即可執(zhí)行（低系統(tǒng)復(fù)雜度），但功能只能滿足教學(xué)目的（功能受限）。

若一平臺功能強(qiáng)大的同時保持低系統(tǒng)復(fù)雜度，則必然擁有較高的使用成本

例子：通用編程語言。圖靈完備理論上可以實現(xiàn)任何功能（功能強(qiáng)大），編譯或解釋為機(jī)器指令執(zhí)行（低系統(tǒng)復(fù)雜度），但存在較高的專業(yè)門檻（高使用成本）。

出路

正所謂，

“

軟件工程就是trade-off的藝術(shù)

”

對于低代碼平臺上述的三個目標(biāo)來說，“我全都要”的結(jié)果只能是“全都得不到”，最終勢必會陷入到按下葫蘆浮起瓢的窘境當(dāng)中。所以，對于任何一款低代碼平臺的設(shè)計者來說，做出合理的trade-off都將是所有工作中的重中之重。

那么如何trade-off來破解“不可能三角”呢？需要基于以下2個事實：

事實1：易用性與性能/可維護(hù)性不可放棄

通常，一款低代碼產(chǎn)品的宣傳會向我們許諾至少以下兩個承諾：

1. 低代碼平臺一定會比傳統(tǒng)開發(fā)方式更方便/更快速/更易上手
2. 低代碼平臺的最終產(chǎn)物一定是可運行的商業(yè)應(yīng)用

對應(yīng)到我們的三個核心設(shè)計目標(biāo)上去，很容易看出：

• 第1條直接要求低代碼平臺必須是易于使用的，尤其是相對于傳統(tǒng)方式要有顯著優(yōu)勢，這是此類平臺的核心競爭力。否則面對同樣需求，客戶為何不選擇更成熟可靠的傳統(tǒng)方案，而要使用低代碼平臺呢？
• 第2條則要求低代碼平臺以及其產(chǎn)物必須是生產(chǎn)可用的。這要求平臺的產(chǎn)物要具有可接受的性能與可維護(hù)性，從而要求平臺的復(fù)雜度不宜過高。而低性能或不可維護(hù)的產(chǎn)品則是斷然無法應(yīng)用在生產(chǎn)中的。

與之相對的，雖然低代碼平臺也會將“功能強(qiáng)大”作為其一大賣點，但又往往會特意強(qiáng)調(diào)其功能具有特定的應(yīng)用范圍。常見的有針對企業(yè)工作流、報表、ERP等場景設(shè)計的低代碼平臺。

綜上，三個設(shè)計目標(biāo)可以被簡短的總結(jié)為：

• 易于使用是魂，是平臺的意義所在。
• 低復(fù)雜度是骨，是平臺在生產(chǎn)中可用的基石。
• 功能強(qiáng)大是肉，是平臺價值的組成部分。

事實2：單一方案至多只能滿足80%場景

我們可以將一款低代碼平臺所面向的問題域，劃分為封閉問題域與開放問題域兩類，它們之間的區(qū)別在于問題空間是否存在確定的邊界。

• 對于那些專注于解決封閉問題域問題的低代碼方案，經(jīng)過精心設(shè)計，是有機(jī)會做到使用一個通用方案覆蓋100%域內(nèi)場景的。此類方案中的佼佼者有SQL之于數(shù)據(jù)查詢領(lǐng)域，可以實現(xiàn)幾乎所有查詢需求。
• 然而對于一個開放問題域來說，由于不可能窮盡域內(nèi)所有可能的問題場景，則可以說完全不可能存在有某個單一的“終極方案”，能夠憑一己之力解決域內(nèi)所有問題。

例如說對于一個To C的低代碼開發(fā)平臺，在UI交互方面，它的問題域就是開放的。

因為終端用戶的交互需求無法窮盡：同樣是展示數(shù)據(jù)，既可以用文本、表格，亦可以用圖表、3D模型，甚至可以用AR、VR……

也因此，平臺不可能提供一個滿足100%應(yīng)用場景的UI構(gòu)建方案。

所以，我們可以化用“二八定律”對這個問題做個略微粗暴的總結(jié)（當(dāng)然這里的2與8都是虛數(shù)）：

對于一開放問題域，任何單一方案至多只能滿足其80%場景。

逃生艙

注：筆者非常喜歡React新版文檔中所使用的“逃生艙”（Escape Hatches）這一比喻，因此在此處也借鑒一番。但需要注意的是，這篇文章中的逃生艙與React中的概念并不完全相同，還需讀者自行鑒別。

聊到這里，其實我們的最佳策略已經(jīng)不言而喻了。如上所述，已知：

• 事實1：易用性與性能/可維護(hù)性不可放棄
• 事實2：單一方案至多只能滿足80%場景

顯而易見，對于平臺設(shè)計者來說，他們應(yīng)該將絕大部分精力投入到服務(wù)好平臺最擅長的那80%業(yè)務(wù)場景當(dāng)中去，竭盡全力在優(yōu)勢領(lǐng)域中做到盡善盡美。

至于剩余的20%邊緣場景，在某些時候，直接放棄或許也是一種可以接受的選項。

當(dāng)然，對于那些富有野心的平臺來說，這恐怕難以接受。那么此時的最佳策略便是本節(jié)的標(biāo)題所指：在平臺設(shè)計之初，設(shè)計者就應(yīng)該考慮到為將來某些高級使用者提供一個完善的“逃生艙”機(jī)制。

這里的“逃生艙”指的是一種向平臺使用者暴露底層能力的機(jī)制。它可以是一組低級API，也可以是一批可供二開擴(kuò)展的集成點，甚至也可以是一套進(jìn)行定制開發(fā)的解決方案?？傊?，為了滿足從過去至將來100%的業(yè)務(wù)需求，平臺必須允許用戶在有必要的時候進(jìn)行“抽象降級”，有機(jī)會乘坐逃生艙從平臺規(guī)定的條條框框之中逃離。

這樣的設(shè)計思想其實在軟件工程領(lǐng)域相當(dāng)常見，譬如plugin API之于webpack、unsafe之于rust、指針之于C#等等……只不過由于低代碼平臺本身業(yè)務(wù)的復(fù)雜性，設(shè)計出一套優(yōu)雅的“逃生艙”機(jī)制并不容易，因此設(shè)計者在平臺設(shè)計的早期就必須考慮這個問題。

當(dāng)前我們團(tuán)隊遇到的問題，就是由于平臺早期缺乏良好的“逃生艙”設(shè)計，導(dǎo)致了面對超出平臺能力的新需求時無從下手：

• 若在原有架構(gòu)上修修補(bǔ)補(bǔ)——復(fù)雜度爆炸
• 若把架構(gòu)推倒重來——工期爆炸
• 若拒絕支持新需求——PM爆炸

可以用一個詞來形容——積重難返。

小結(jié)

如上，筆者將本人在低代碼平臺上遇到的困難與思考進(jìn)行了些淺顯總結(jié)，斗膽試圖借此來發(fā)現(xiàn)一點架構(gòu)設(shè)計的普遍規(guī)律，慚愧慚愧……

文章最后，再試著簡單總結(jié)一些由本文觀點得出的建議。

對于平臺使用者

對于使用者來說，最大的啟示是在技術(shù)選型的階段最好留個心眼，切勿輕信了平臺銷售對其產(chǎn)品功能的吹噓。尤其是如果有人膽敢宣揚他的平臺無所不能，今天開發(fā)明天上線后天解雇程序員云云，那你可得小心了。

正如前文所言，任何低代碼產(chǎn)品的出發(fā)點都是為了降低用戶的使用成本，所以如果一個平臺即承諾了易用性，又承諾了功能性，那么代價是什么？

經(jīng)驗來說，反倒是專注于一個特定領(lǐng)域的平臺供應(yīng)商往往更加務(wù)實，也有更大概率做出更成熟的產(chǎn)品。

對于平臺設(shè)計者

對于設(shè)計者來說，最大的挑戰(zhàn)是在如上不可能三角中取得平衡。對于不同類型的系統(tǒng)設(shè)計取向自然也不同，但對于低代碼平臺這一品類來說，大部分情況下，易用性和系統(tǒng)復(fù)雜度還是比功能性重要的多。

因此如果你的產(chǎn)品也具有類似的價值取向的話，那么作為架構(gòu)設(shè)計者，盡早地規(guī)劃“逃生艙”的設(shè)計和落實才是負(fù)責(zé)任的做法。