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

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

一時“人人都是程序員”，“不會寫程序也可以快速開發(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）
• 等等

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

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

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

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

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

日光之下并無新事账嚎，只有你不曾經(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)率的奢侈主張時丛塌。

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

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

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

從另一個角度看蟹肘，如果低代碼平臺那么厲害词疼，為什么那么多互聯(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)注的）胸完。

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

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

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

嘿！你這一會兒說低代碼平臺不靠譜袖扛，一會兒又說還是有成功場景的砸泛，話都叫你說了，到底你要怎樣Ｇ狻（拔刀）

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

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

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

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

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

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

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

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

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

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

以史為鑒态兴，為什么有些低代碼平臺會大放異彩狠持，而有些則退出舞臺

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

• 低代碼平臺的選擇琅关，關(guān)鍵不看工具（語言設(shè)計(jì)解釋器）設(shè)計(jì)的多漂亮煮岁，而是要看其專注的問題領(lǐng)域及范圍（個人推薦越專注越好），以及對這個領(lǐng)域的建模和DSL（元模型）設(shè)計(jì)能力涣易。
• 如果是自建低代碼平臺画机，除了對于領(lǐng)域建模的工作必須要做意外，可以再衡量一下再做一個低代碼平臺的工具（托拉拽）部分的價值新症。往往有了良好設(shè)計(jì)和建模后步氏，大部分時候?qū)懘a的效率不比托拉拽的效率低，而且還有完整的軟件工程實(shí)踐（代碼腳手架徒爹、版本控制荚醒、測試、CICD…）支撐隆嗅。
• 而制作一個低代碼平臺的工具部分界阁，往往最大的價值并不是提高程序員的效率，反而是為了實(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)确垫，個人建議最好只作為過渡產(chǎn)品或是應(yīng)用于非企業(yè)核心領(lǐng)域。

文/Thoughtworks王健
原文鏈接：https://insights.thoughtworks.cn/low-code-platform/
更多精彩洞見帽芽，請關(guān)注微信公眾號Thoughtworks洞見删掀。