（注：本文最早發(fā)布于2020年5月份，當(dāng)時(shí)低代碼平臺已經(jīng)在行業(yè)中被熱議，如今熱度不減，文中的思考也仍然適用）

最近在很多場合聽到大家在談?wù)摗暗痛a平臺”這個(gè)概念，尤其是其概念在投資和收購市場上的火爆，吸引了很多人的關(guān)注和目光。

一時(shí)“人人都是程序員”，“不會(huì)寫程序也可以快速開發(fā)應(yīng)用”的聲音四起，很多人都開始思考這是不是軟件開發(fā)行業(yè)的未來。

今天就聊聊我的想法和觀點(diǎn)。

低代碼平臺，是通向美好生活之路還是托拉拽重現(xiàn)江湖

低代碼開發(fā)平臺是一種aPaaS（Application Platform as a Service），它是僅需少量編碼甚至無需編碼 (0代碼) 即可快速通過可視化拖拽 (drag & drop) 的方式完成應(yīng)用程序開發(fā)的平臺。該名詞最早于2014年6月由Forrester Research最先提出。

低代碼開發(fā)平臺通常具備以下特點(diǎn)：

• 可視化集成開發(fā)環(huán)境（Visual IDE）;
• 大量可重用且支持拖拽的組件（drag & drop）
• 等等

如果你對這個(gè)概念還不太理解，可以想想一下《鋼鐵俠》中鋼鐵俠在自己的全息工作臺上擺弄設(shè)計(jì)各種鋼鐵俠的場景……（雖然目前的低代碼平臺還沒這么酷炫，但是大概的意思差不多）。

如果覺得這個(gè)例子太過科幻，其實(shí)我們身邊隨手都能看到類似的工具和平臺，比如，Mac系統(tǒng)中的Automator或是iOS中的快捷指令（原來叫做workflow），亦或是前幾年火過一陣的ifttt……

當(dāng)你第一次接觸到類似的平臺，相信一定會(huì)眼前一亮：軟件還能這么做？！我們現(xiàn)在這一行行攢代碼的方式太low了？！這難道才是軟件行業(yè)的未來？！

但當(dāng)你壓抑不住激動(dòng)的心情，跑到那些老程序員面前，眉飛色舞的介紹這個(gè)你認(rèn)為即將要改變軟件行業(yè)未來的新趨勢時(shí)，老程序員可能連正眼都不瞧你一眼，頂多從嘴角再吐出幾個(gè)字：“哎……又是托拉拽…… ”

要知道，“托拉拽”這三字，在老程序員的心中，可能并不是一段美好的記憶……

日光之下并無新事，只有你不曾經(jīng)歷的歷史

其實(shí)低代碼平臺不是最近才出現(xiàn)的概念（像很多其他的所謂的新概念一樣），Thoughtworks的技術(shù)雷達(dá)早在兩年前2018年的11月份那期，就已經(jīng)提到了Low-code platforms，不過遺憾的是，它并不是作為新技術(shù)的推薦，反而是被放到了Hold（暫緩，謹(jǐn)慎使用）的象限里。

翻譯成中文就是：

低代碼平臺使用圖形用戶界面和配置來創(chuàng)建應(yīng)用程序。 可惜的是，推廣低代碼平臺推薦的這種開發(fā)應(yīng)用的方式意味著你不再需要熟練的開發(fā)團(tuán)隊(duì)。這樣的建議忽略了以下事實(shí)：”編寫代碼只是創(chuàng)建高質(zhì)量軟件所需的一小部分，而諸如源代碼控制，測試和精心設(shè)計(jì)解決方案之類的實(shí)踐同樣重要”。 盡管這些平臺有其用途，但我們還是建議謹(jǐn)慎使用它們，尤其是當(dāng)它們帶有降低成本和提高生產(chǎn)率的奢侈主張時(shí)。

我個(gè)人也在10多年前，就有過使用類似號稱可以“托拉拽”快速實(shí)現(xiàn)應(yīng)用開發(fā)的工具平臺（當(dāng)時(shí)還叫做SOA平臺，但是仔細(xì)看了一下和現(xiàn)在大家談?wù)摰摹暗痛a平臺”我覺得沒什么不同）開發(fā)應(yīng)用的經(jīng)驗(yàn)，當(dāng)時(shí)的慘痛經(jīng)驗(yàn)讓我現(xiàn)在還記憶猶新……

就像是上文技術(shù)雷達(dá)提到的一樣，這種平臺往往Demo看起來非常的酷炫和有沖擊力，但是一旦真正應(yīng)用到實(shí)際工作過程中就會(huì)出現(xiàn)各種問題：開發(fā)效率不升反降，平臺學(xué)習(xí)成本高，程序員學(xué)習(xí)動(dòng)力不強(qiáng)，功能受限，感覺束手束腳，調(diào)試難測試更難，數(shù)據(jù)不開放，平臺與工具綁定，性能問題等等……掙扎了一段時(shí)間，最后還是放棄了，重新回到了原來的開發(fā)方式上。

類似的平臺其實(shí)還有很多很多，別的不提，就例如大家最熟悉的VB（Visual Basic），現(xiàn)在回頭來看不就是一個(gè)典型的試圖通過組件的托拉拽加少量代碼的方式實(shí)現(xiàn)應(yīng)用的快速構(gòu)建的“低代碼平臺”么？而又怎么會(huì)漸出了歷史舞臺？難道只是簡單的CS架構(gòu)問題么？話說想想BS架構(gòu)下類似的工具也有不少，最后也都難逃同樣的命運(yùn)……

從另一個(gè)角度看，如果低代碼平臺那么厲害，為什么那么多互聯(lián)網(wǎng)公司還在持續(xù)招聘那么多的程序員，沒日沒夜的寫著最基本的代碼開發(fā)軟件，為什么不大量的使用低代碼平臺來快速構(gòu)建自己的應(yīng)用呢？（對于互聯(lián)網(wǎng)企業(yè)，還有一點(diǎn)非常重要，就是非常注重核心系統(tǒng)的自研可控，以及對于數(shù)據(jù)的百分之百管理，這也是現(xiàn)在越來越多非互聯(lián)網(wǎng)企業(yè)開始關(guān)注的）。

換一個(gè)角度，客觀來看，其實(shí)“托拉拽”也不是沒有成功場景，例如在常見的工作流設(shè)計(jì)（BPM）和最常見的辦公自動(dòng)化（OA）場景下，很多場景都是通過“自定義表單 基于托拉拽的流程編排”來實(shí)現(xiàn)的，在過去一段時(shí)間也很好的滿足了一些場景需求。

而在軟件開發(fā)領(lǐng)域，我們熟悉的UML 設(shè)計(jì)器 MDD（Model driven development）也曾紅極一時(shí)，雖然最后MDD雖然沒有得到大范圍的應(yīng)用，但是基于UML的托拉拽方式對于軟件進(jìn)行設(shè)計(jì)，還是延續(xù)至今。

還有一個(gè)我們更熟悉的場景，SQL其實(shí)也算是一個(gè)最常見的“低代碼平臺”的成功應(yīng)用場景，如果把“SQL”看成一個(gè)“編程語言”（本質(zhì)上就是），那我們在用各種數(shù)據(jù)庫設(shè)計(jì)工具對于數(shù)據(jù)庫進(jìn)行設(shè)計(jì)，并最終由工具自動(dòng)轉(zhuǎn)化為“SQL”在數(shù)據(jù)庫中執(zhí)行的過程，其實(shí)就是一個(gè)理想“低代碼平臺”運(yùn)作的過程。（想象一下沒有類似的工具平臺，全部SQL需要手寫的酸爽滋味）。

嘿！你這一會(huì)兒說低代碼平臺不靠譜，一會(huì)兒又說還是有成功場景的，話都叫你說了，到底你要怎樣?。ò蔚叮?/p>

少俠先冷靜先冷靜，待我為你撥云見日，其中玄妙娓娓道來……

不吹不黑，客觀洞察低代碼平臺的本質(zhì)

如果想搞清楚，低代碼平臺的應(yīng)用場景和價(jià)值，一定要“透過現(xiàn)象看本質(zhì)”，思考一下低代碼平臺在酷炫的界面，眼花繚亂的功能背后，其本質(zhì)到底是什么？

廢話不多說，直接給結(jié)論：

低代碼平臺 = 領(lǐng)域特定語言（DSL） 語言解釋器（Interpreter）

其實(shí)我們大多數(shù)人對于低代碼平臺搞不清楚，根本上是因?yàn)殛P(guān)注點(diǎn)錯(cuò)了，我們將太多的關(guān)注點(diǎn)放到了各種酷炫的“托拉拽”的工具上面（雖然很有沖擊力，尤其是對非程序員），也就是語言解釋器（Interpreter）部分，而恰恰忽略了其最重要的也是關(guān)乎于威力以及成敗的領(lǐng)域特定語言（DSL）部分。

可能這里的領(lǐng)域特定語言（英語：domain-specific language、DSL，后文簡稱為“語言”）大家會(huì)感到一些陌生，其指的是專注于某個(gè)應(yīng)用程序領(lǐng)域的計(jì)算機(jī)語言，又譯作領(lǐng)域?qū)Ｓ谜Z言。值得驕傲的是，我司的“老馬”，Martin Fowler出過一本同名著作，也是DSL領(lǐng)域的豐碑之作。

說回來，其實(shí)也沒那么復(fù)雜，我們常說：“語言的邊界就是思想的邊界” ，而領(lǐng)域特定語言（DSL），簡單理解就算是我們在面對某一個(gè)特定領(lǐng)域形成的語言（有時(shí)候也成為元模型），例如我們上邊提到的例子里：

• 我們操作數(shù)據(jù)庫用到的SQL，其實(shí)全名就是Structured Query Language（結(jié)構(gòu)化查詢語言）本質(zhì)上就是面對關(guān)系數(shù)據(jù)庫系統(tǒng)的一種DSL，而各種SQL設(shè)計(jì)器，其實(shí)就是這門語言的設(shè)計(jì)器和解釋器而已。
• 我們在處理工作流時(shí)，其背后也有一套語言，例如常見的BPML（Business Process Modeling Language ，業(yè)務(wù)流程建模語言），我們看到的各種酷炫的流程設(shè)計(jì)編排工具和平臺，無非也就是這門語言的設(shè)計(jì)器和解釋器而已。
• 我們在設(shè)計(jì)軟件系統(tǒng)時(shí)，背后用的UML，全名叫Unified Modeling Language（統(tǒng)一建模語言），而無論是各種UML設(shè)計(jì)工具還是MDD（模型驅(qū)動(dòng)開發(fā)方法），也都是這門語言的設(shè)計(jì)器和解釋器而已。
• 類似的例子還有很多……

所以一個(gè)低代碼平臺的關(guān)鍵成敗，作為解釋器（Interpreter）的花里胡哨的工具其實(shí)并不是關(guān)鍵；低代碼平臺關(guān)注解決的問題領(lǐng)域（軟件開發(fā)，軟件設(shè)計(jì)，應(yīng)用開發(fā)、數(shù)據(jù)庫操作、系統(tǒng)集成、中臺能力組合編排…），以及是否能通過“抽象”和“約束”為這個(gè)領(lǐng)域設(shè)計(jì)出一套好的DSL（或是元模型），才是關(guān)鍵，也直接關(guān)乎平臺的成敗。

以史為鑒，為什么有些低代碼平臺會(huì)大放異彩，而有些則退出舞臺

講到這里，有一個(gè)問題一直懸而未決，為什么像VB這樣的低代碼平臺會(huì)漸出歷史，而像SQL、工作流引擎這樣的低代碼平臺則會(huì)持續(xù)煥發(fā)生命力呢？

這個(gè)問題很關(guān)鍵，因?yàn)橄肭宄诉@個(gè)問題，對于幫助我們判斷現(xiàn)在百花齊放的各種低代碼平臺是否靠譜，能否成功有非常大的借鑒價(jià)值。

其實(shí)這個(gè)問題也不難解釋，因?yàn)樯厦嫖覀円呀?jīng)提到，一個(gè)低代碼平臺的關(guān)鍵在于其關(guān)注的問題領(lǐng)域以及是否能為這個(gè)領(lǐng)域設(shè)計(jì)一套好的DSL，所以我們看待一個(gè)低代碼平臺，就只需要關(guān)注：

1. 它所關(guān)注的領(lǐng)域到底是什么？
2. 以及這個(gè)領(lǐng)域是否能抽象出一套通用的DSL（元模型）出來。

DSL關(guān)注的領(lǐng)域越“特定”，例如只關(guān)注在流程設(shè)計(jì)，或是只關(guān)注在關(guān)系數(shù)據(jù)庫查詢某個(gè)具體領(lǐng)域上，DSL的設(shè)計(jì)復(fù)雜度越低，反而語言的設(shè)計(jì)和包裝而成的低代碼平臺越容易發(fā)揮威力，獲得成功，大幅提升其實(shí)所在領(lǐng)域的效率。

反之，DSL關(guān)注的領(lǐng)域越“通用”（極致就是通用編程語言，例如C），越想覆蓋盡量多的領(lǐng)域場景，就會(huì)導(dǎo)致“語言”的設(shè)計(jì)復(fù)雜度越高，低代碼平臺的設(shè)計(jì)和應(yīng)用難度越大，失敗的概率也會(huì)越大（想想給C語言設(shè)計(jì)一個(gè)托拉拽的LowCode平臺的難度…）。

這也很容易理解，這就像是給“中文”寫一個(gè)解釋器的難度和失敗概率，要比給一個(gè)行業(yè)黑話（可能就幾十個(gè)詞）寫一個(gè)解釋器的難度和失敗概率大得多一樣。

其實(shí)DSL中的S就是特定（Specific ）的意思，這個(gè)名字本身就已經(jīng)把答案早就告訴了我們，只有關(guān)注特定的領(lǐng)域（Specific Domain）的領(lǐng)域特定語言（domain-specific language）往往才能發(fā)揮出更強(qiáng)大的威力！

那么，低代碼是否會(huì)替代或顛覆傳統(tǒng)的軟件開發(fā)方式呢？

想清楚了低代碼平臺的本質(zhì)，我們就知道其實(shí)本質(zhì)上并不存在什么高代碼平臺低代碼平臺之分，我們在用低代碼平臺“托拉拽”，和在IDE里敲代碼本質(zhì)上是一樣的，都是在用一個(gè)“工具”通過一套“語言”在描述和表達(dá)一類“業(yè)務(wù)”而已。

而區(qū)別只在于“語言”的“抽象層次”。

語言越接近于機(jī)器底層，對于”語言”的約束越少，IDE能幫我們做的事情越少，我們就得寫更多的代碼，但是好處就是語言的通用性越強(qiáng)靈活性也越高，什么領(lǐng)域的問題都能描述（想想?yún)R編或C）。

語言越接近于業(yè)務(wù)場景層，對于”語言”的約束越高，IDE能幫我們做的事情越多，我們就可以少寫些代碼（極致就是no-code），但壞處就是語言的通用性差靈活性降低，只能描述某個(gè)特定的領(lǐng)域的問題（想想SQL）。

所以“低代碼平臺的興起”所代表的“語言”通過聚焦于一個(gè)特定領(lǐng)域從而進(jìn)一步逼近業(yè)務(wù)的趨勢，就像是“中臺的興起”所代表的“平臺”通過聚焦于一個(gè)特定領(lǐng)域從而進(jìn)一步逼近業(yè)務(wù)的趨勢一樣（原諒我），都是大勢所趨。但由于存在效率與通用性的博弈，所以這個(gè)過程注定只能算是對于編程語言在特定領(lǐng)域的不斷再抽象和細(xì)化過程，并不會(huì)完全替代過去的軟件開發(fā)方式（就像雖然行業(yè)黑話確實(shí)能在特定行業(yè)內(nèi)提升溝通效率，但行業(yè)黑話最終也無法替換中文一樣）。

總結(jié)

最后，再總結(jié)一下我的觀點(diǎn)：

• 低代碼平臺的選擇，關(guān)鍵不看工具（語言設(shè)計(jì)解釋器）設(shè)計(jì)的多漂亮，而是要看其專注的問題領(lǐng)域及范圍（個(gè)人推薦越專注越好），以及對這個(gè)領(lǐng)域的建模和DSL（元模型）設(shè)計(jì)能力。
• 如果是自建低代碼平臺，除了對于領(lǐng)域建模的工作必須要做意外，可以再衡量一下再做一個(gè)低代碼平臺的工具（托拉拽）部分的價(jià)值。往往有了良好設(shè)計(jì)和建模后，大部分時(shí)候?qū)懘a的效率不比托拉拽的效率低，而且還有完整的軟件工程實(shí)踐（代碼腳手架、版本控制、測試、CICD…）支撐。
• 而制作一個(gè)低代碼平臺的工具部分，往往最大的價(jià)值并不是提高程序員的效率，反而是為了實(shí)現(xiàn)對于業(yè)務(wù)人員的自助（Self-Service）服務(wù)平臺。
• 如果是選擇第三方低代碼平臺（產(chǎn)品），在權(quán)衡其關(guān)注領(lǐng)域，模型和語言設(shè)計(jì)，以及工具設(shè)計(jì)用戶體驗(yàn)之外，還需要考量其平臺綁定、數(shù)據(jù)開放性、可維護(hù)性、可測試性、性能標(biāo)準(zhǔn)、學(xué)習(xí)成本以及未來的向自建平臺的遷移成本等指標(biāo)，個(gè)人建議最好只作為過渡產(chǎn)品或是應(yīng)用于非企業(yè)核心領(lǐng)域。

文/Thoughtworks王健

原文鏈接：https://insights.thoughtworks.cn/low-code-platform/

更多精彩洞見，請關(guān)注微信公眾號Thoughtworks洞見。