低程式碼平臺會是軟體業的未來麼？

最近在很多場合聽到大家在談論“低程式碼平臺”這個概念，尤其是其概念在投資和收購市場上的火爆，吸引了很多人的關注和目光。

一時“人人都是程式設計師”，“不會寫程式也可以快速開發應用”的聲音四起，很多人都開始思考這是不是軟體開發行業的未來。

今天就聊聊我的想法和觀點。

低程式碼平臺，是通向美好生活之路還是托拉拽重現江湖

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

低程式碼開發平臺通常具備以下特點：

• 視覺化整合開發環境（Visual IDE）;

• 大量可重用且支援拖拽的元件（drag & drop）

• 等等

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

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

當你第一次接觸到類似的平臺，相信一定會眼前一亮：軟體還能這麼做？！我們現在這一行行攢程式碼的方式太low了？！這難道才是軟體行業的未來？！

但當你壓抑不住激動的心情，跑到那些老程式設計師面前，眉飛色舞的介紹這個你認為即將要改變軟體行業未來的新趨勢時，老程式設計師可能連正眼都不瞧你一眼，頂多從嘴角再吐出幾個字：“哎……又是托拉拽…… ”

要知道，“托拉拽”這三字，在老程式設計師的心中，可能並不是一段美好的記憶……

日光之下並無新事，只有你不曾經歷的歷史

其實低程式碼平臺不是最近才出現的概念（像很多其他的所謂的新概念一樣），ThoughtWorks的技術雷達早在兩年前2018年的11月份那期，就已經提到了Low-code platforms[]，不過遺憾的是，它並不是作為新技術的推薦，反而是被放到了Hold（暫緩，謹慎使用）的象限裡。

翻譯成中文就是：

低程式碼平臺使用圖形使用者介面和配置來建立應用程式。可惜的是，推廣低程式碼平臺推薦的這種開發應用的方式意味著你不再需要熟練的開發團隊。這樣的建議忽略了以下事實：“編寫程式碼只是建立高質量軟體所需的一小部分，而諸如原始碼控制，測試和精心設計解決方案之類的實踐同樣重要”。儘管這些平臺有其用途，但我們還是建議謹慎使用它們，尤其是當它們帶有降低成本和提高生產率的奢侈主張時。

我個人也在10多年前，就有過一次使用類似號稱可以“托拉拽”快速實現應用開發的工具平臺（當時還叫做SOA平臺，但是仔細看了一下和現在大家談論的“低程式碼平臺”我覺得沒什麼不同）開發應用的經驗，當時的慘痛經驗讓我現在還記憶猶新……

就像是上文技術雷達提到的一樣，這種平臺往往Demo看起來非常的酷炫和有衝擊力，但是一旦真正應用到實際工作過程中就會出現各種問題：開發效率不升反降，平臺學習成本高，程式設計師學習動力不強，功能受限，感覺束手束腳，除錯難測試更難，資料不開放，平臺與工具繫結，效能問題等等……最後還是放棄了重新回到了原來的開發方式上。

類似的平臺其實還有很多很多，別的不提，就例如大家最熟悉的VB（Visual Basic），現在回頭來看不就是一個典型的試圖透過元件的托拉拽加少量程式碼的方式實現應用的快速構建的“低程式碼平臺”麼？而又怎麼會漸出了歷史舞臺？難道只是簡單的CS架構問題麼？話說想想BS架構下類似的工具也有不少，最後也都難逃同樣的命運……

從另一個角度看，如果低程式碼平臺那麼厲害，為什麼那麼多網際網路公司還在持續招聘那麼多的程式設計師，沒日沒夜的寫著最基本的程式碼開發軟體，為什麼不大量的使用低程式碼平臺來快速構建自己的應用呢？（對於網際網路企業，還有一點非常重要，就是非常注重核心系統的自研可控，以及對於資料的百分之百管理，這也是現在越
來越多非網際網路企業開始關注的）。

換一個角度，客觀來看，其實“托拉拽”也不是沒有成功場景，例如在常見的工作流設計（BPM）和最常見的辦公自動化（OA）場景下，很多場景都是透過“自定義表單+基於托拉拽的流程編排”來實現的，在過去一段時間也很好的滿足了一些場景需求。

而在軟體開發領域，我們熟悉的UML+設計器+ MDD（Model driven development）也曾紅極一時，雖然最後MDD雖然沒有得到大範圍的應用，但是基於UML的托拉拽方式對於軟體進行設計，還是延續至今。

還有一個我們更熟悉的場景，SQL其實也算是一個最常見的“低程式碼平臺”的成功應用場景，如果把“SQL”看成一個“程式語言”（本質上就是），那我們在用各種資料庫設計工具對於資料庫進行設計，並最終由工具自動轉化為“SQL”在資料庫中執行的過程，其實就是一個理想“低程式碼平臺”運作的過程。（想象一下沒有類似的工具平臺，全部SQL需要手寫的酸爽滋味）。

嘿！你這一會兒說低程式碼平臺不靠譜，一會兒又說還是有成功場景的，話都叫你說了，到底你要怎樣！（拔刀）

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

不吹不黑，客觀洞察低程式碼平臺的本質

如果想搞清楚，低程式碼平臺的應用場景和價值，一定要“透過現象看本質”，思考一下低程式碼平臺在酷炫的介面，眼花繚亂的功能背後，其本質到底是什麼？

廢話不多說，直接給結論：

低程式碼平臺 = 領域特定語言（DSL） + 語言直譯器（Interpreter）

其實我們大多數人對於低程式碼平臺搞不清楚，根本上是因為關注點錯了，我們將太多的關注點放到了各種酷炫的“托拉拽”的工具上面（雖然很有衝擊力，尤其是對非程式設計師），也就是 語言直譯器（Interpreter）部分，而恰恰忽略了其最重要的也是關乎於威力以及成敗的 領域特定語言（DSL）部分。

可能這裡的領域特定語言（英語：domain-specific language、DSL，後文簡稱為“語言”）大家會感到一些陌生，其指的是專注於某個應用程式領域的計算機語言，又譯作領域專用語言。值得驕傲的是，我司的“老馬”，Martin Fowler出過一本同名著作，也是DSL領域的豐碑之作。

說回來，其實也沒那麼複雜，我們常說：“語言的邊界就是思想的邊界” ，而領域特定語言（DSL），簡單理解就算是我們在面對某一個特定領域形成的語言（有時候也成為元模型），例如我們上邊提到的例子裡：

• 我們運算元據庫用到的SQL，其實全名就是Structured Query Language（結構化查詢語言）本質上就是面對關聯式資料庫系統的一種DSL，而各種SQL設計器，其實就是這門語言的設計器和直譯器而已。

  
  

• 我們在處理工作流時，其背後也有一套語言，例如常見的BPML（Business Process Modeling Language ，業務流程建模語言），我們看到的各種酷炫的流程設計編排工具和平臺，無非也就是這門語言的設計器和直譯器而已。

  
  

• 我們在設計軟體系統時，背後用的UML，全名叫Unified Modeling Language（統一建模語言），而無論是各種UML設計工具還是MDD（模型驅動開發方法），也都是這門語言的設計器和直譯器而已。

  
  

• 類似的例子還有很多……

所以一個低程式碼平臺的關鍵成敗，作為直譯器（Interpreter）的花裡胡哨的工具其實並不是關鍵。

低程式碼平臺關注解決的問題領域（軟體開發，軟體設計，應用開發、資料庫操作、系統整合、中臺能力組合編排…），以及是否能透過“抽象”和“約束”為這個領域設計出一套好的DSL（或是元模型），才是關鍵，也直接關乎平臺的成敗。

以史為鑑，為什麼有些低程式碼平臺會大放異彩，而有些則退出舞臺

講到這裡，有一個問題一直懸而未決，為什麼像VB這樣的低程式碼平臺會漸出歷史，而像SQL、工作流引擎這樣的低程式碼平臺則會持續換髮生命力呢？

這個問題很關鍵，因為想清楚了這個問題，對於幫助我們判斷現在百花齊放的各種低程式碼平臺是否靠譜，能否成功有非常大的借鑑價值。

其實這個問題也不難解釋，因為上面我們已經提到，一個低程式碼平臺的關鍵在於其關注的問題領域以及是否能為這個領域涉及一套好的DSL，所以我們看待一個低程式碼平臺，就只需要關注：

1. 它所關注的領域到底是什麼？

2. 以及這個領域是否能抽象出一套通用的DSL（元模型）出來。

DSL關注的領域越“特定”，例如只關注在流程設計，或是隻關注在關聯式資料庫查詢某個具體領域上，DSL的設計複雜度越低，反而語言的設計和包裝而成的低程式碼平臺越容易發揮威力，獲得成功，大幅提升其實所在領域的效率。

反之，DSL關注的領域越“通用”（極致就是通用程式語言，例如C），越想覆蓋儘量多的領域場景，就會導致“語言”的設計複雜度越高，低程式碼平臺的設計和應用難度越大，失敗的機率也會越大（想想給C語言設計一個托拉拽的LowCode平臺的難度…）。

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

其實DSL中的S就是特定（Specific ）的意思，這個名字本身就已經把答案早就告訴了我們，只有關注特定的領域（Specific Domain）的領域特定語言（domain-specific language）往往才能發揮出更強大的威力！

那麼，低程式碼是否會替代或顛覆傳統的軟體開發方式呢？

想清楚了低程式碼平臺的本質，我們就知道其實本質上並不存在什麼高程式碼平臺低程式碼平臺之分，我們在用低程式碼平臺“托拉拽”，和在IDE裡敲程式碼本質上是一樣的，都是在用一個“工具”透過一套“語言”在描述和表達一類“業務”而已。

而區別只在於“語言”的“抽象層次”。

“語言 ”越接近於機器底層，對於”語言”的約束越少，IDE能幫我們做的事情越少，我們就得寫更多的程式碼，但是好處就是語言的通用性越強靈活性也越高，什麼領域的問題都能描述（想想彙編或C）。

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

所以“低程式碼平臺的興起”所代表的“語言”透過聚焦於一個特定領域從而進一步逼近業務的趨勢，就像是“中臺的興起”所代表的“平臺”透過聚焦於一個特定領域從而進一步逼近業務的趨勢一樣（原諒我，沒忍住），都是大勢所趨。

但由於存在效率與通用性的博弈，所以這個過程註定只能算是對於程式語言在特定領域的不斷再抽象和細化過程，並不會完全替代過去的軟體開發方式（就像雖然行業黑話確實能在特定行業內提升溝通效率，但行業黑話最終也無法替換中文一樣）。

總結

最後，再總結一下我的觀點：

• 低程式碼平臺的選擇，關鍵不看工具（語言設計直譯器）設計的多漂亮，而是要看其專注的問題領域及範圍（個人推薦越專注越好），以及對這個領域的建模和DSL（元模型）設計能力。

• 如果是自建低程式碼平臺，除了對於領域建模的工作必須要做意外，可以再衡量一下再做一個低程式碼平臺的工具（托拉拽）部分的價值。事實上，往往有了良好設計和建模後，大部分時候寫程式碼的效率不比托拉拽的效率低，而且還有完整的軟體工程實踐（程式碼腳手架、版本控制、測試、CICD…）支撐。

• 而製作一個低程式碼平臺的工具部分，往往最大的價值並不是提高程式設計師的效率，反而是為了實現對於業務人員的自助（Self-Service）服務平臺，釋放程式設計師的頻寬。

• 如果是選擇第三方低程式碼平臺（產品），在權衡其關注領域，模型和語言設計，以及工具設計使用者體驗之外，還需要考量其平臺繫結、資料開放性、可維護性、可測試性、效能標準、學習成本以及未來的向自建平臺的遷移成本等指標，個人建議最好只作為過渡產品或是應用於非企業核心領域。