關於低程式碼和無程式碼---喧囂背後的致命問題

前言

2021年的時候，颳起了一陣」低程式碼」和」無程式碼」的風，結果豬沒見吹起來，風卻早早停了。

在我的職業生涯中遇到了很多的低程式碼的構想和實現，通常他們的想法非常樸素：寫程式碼寫煩了！或者是覺得增刪改查程式碼太沒有價值，又太有規律，於是就想著用工具解決勞動重複的問題。

如果你也是這樣覺得，首先還是要表揚：你確實是一個程式設計師，具備非常好的發現問題並解決問題的思維；如果你已經開始動手了，那麼恭喜你，已經進坑了。

文章先說結論：

沒有想清楚之前，不要做低程式碼，更不要做無程式碼。
投資者如果想正經投資獲取回報，謹慎投資低程式碼，不要投資無程式碼。

當然，用這個練手除外。上手實踐是掌握技術的必由之路。

故事

我們先從一個故事說起。很早之前還是delphi時代，那時候的最新作業系統是Windows 2000，大家最熟悉的XP還沒有出來。我的一群做基金核心系統的同事們程式碼寫煩了，於是做了一個快速程式碼生成器，通過簡單的設定和勾選，可以快速生成複雜的介面和增刪改查功能。80%的功能可以很快出來，無論是開發還是客戶都很高興。

但是問題在於剩下的20%，這剩下的部分通常是某個複雜的業務介面，或者是系統的演演算法核心，並且和前後端都可能關聯。大量的精力都投入在了20%的工作上，甚至需要跳出原有的框架，用一些技巧去滿足功能需求。一句話，就是痛苦指數相當高。前面省下來的時間，可能還不夠後面折騰的。讓我印象深刻的是客戶對我同事所在專案組工作的評價：

你們啊！把Delphi的優點做成了缺點！

所有的低程式碼和無程式碼平臺都有這個問題。工作量的嚴重不均衡：80%增刪改查爽的要死，20%的特殊功能折騰得想死。

根據」工作量轉移」原理，應用程式的工作量是≥某個值的，如果某一部分的工作量變小了，肯定是把工作量轉移到了其他的地方。例如spring框架封裝得這麼好，我們只需要編寫業務程式碼就可以了，貌似我們簡單了，但Pivotal的架構師們投入在spring上的工作量可不小了。這還是有人分擔的情況。拋開框架不談，哪怕我們集中在業務層，只要有類似業務框架這種全域性影響力的部件存在，工作量轉移的現象就表現得很明顯。業務框架做的事情越多，開發難度就越大，但沒有業務框架支援，每個業務模組的複雜度則會升高，關聯會越多，最終超出管理能力，逼迫架構師去提煉業務框架。

我的老東家K有自己的低程式碼開發平臺，並且圍繞這個做成了一個生態體系，集團開發核心產品，外圍供應商負責實施和二次開發。但這個低程式碼的生態是一個圍城，防止了外人的侵入，也把自己困在裡面。我問過幾個好朋友這個低程式碼平臺對業務需求的滿足率，大概在50%左右，也就是一半業務開發很快，一半業務要在這個體系之外編寫程式碼。

我在老東家D的一個同事，獨立開發了一個低程式碼平臺。這個低程式碼平臺的特點是用了一些」運算元」概念去擴充套件，缺點是依然是前端和邏輯繫結太死。

這幾個例子可以看出，所有的低程式碼平臺最大的問題就是」不靈活」。

另外的一個嚴重問題是」沒有普適性」。一個開發人員如果學習了某個X程式碼平臺的開發技術，就意味著他用X程式碼平臺的期間裡，和開放架構是脫離的。直白了說，這個開發人員換工作的時候會發現自己已經和行業流行技術棧脫節了。

低程式碼和無程式碼成了員工發展的絆腳石。

本質

低程式碼

低程式碼等價於DSL（Domain Specific Language，領域專用語言），馬丁福勒（Martin Fowler）說DSL最重要的特徵就是：

有限表達力

這是和通用語言相比最顯著的特徵，DSL是針對專門某個特定領域的程式語言。也就是意味著，DSL通常需要一個業務化的基礎平臺，並且為這個基礎平臺提供膠水程式碼。而我們所謂的低程式碼，充其量就是給DSL加了一個視覺化的介面。

無程式碼

無程式碼和低程式碼雖然只有一字之差，但是要求是天壤之別。無程式碼實際就是對標通用程式語言的，它要實現的是」圖靈完備性」。當前市面上除了Mendix和有限幾個競品之外，幾乎所有自稱無程式碼的產品，都實際上是低程式碼。信通院2022年在整理低程式碼和無程式碼平臺的標準，我在各種大佬參加的研討會上斗膽提問了一下，發現沒人意識到無程式碼需要和圖靈完備掛鉤。

無論是低程式碼，還是無程式碼，最終需要的都是後設資料的描述能力。

後設資料

後設資料的定義是」描述資料的資料」，通俗點講，SQL裡的DDL定義的就是後設資料。

CREATE TABLE table001 (
    id INT,
    title VARCHAR
)

現在後設資料的描述能力還相當原始，大部分人對後設資料的認知都集中在資料庫建表層面。實際上，我看到目前最高的後設資料是OMG組織的CWM（Common Warehouse Metamodel）規範定義。除了欄位定義之外，還有資料變換。

低程式碼和無程式碼的後設資料更復雜，實際上考驗的是設計者對應用程式構成的理解。目前的這些X程式碼產品，通常會抽象出來的應用程式元素有：

頁面：就是對應一個一個可以看到的頁面
控制元件/元件：頁面上的各種元素的抽象，基本都會支援繫結一些資料
事件/呼叫：呼叫後臺API的訊息，也有擴充套件成可以呼叫非後臺API
演演算法：獨立的演演算法或業務邏輯。通常會支援第三方定義

其他還有很多產品特有的概念和術語，然後把這一切糅合起來，就以為可以描述一個應用程式了。我很懷疑他們是否真的收集到了足夠的用例，並對他們設計的架構做過充分的驗證。

現在後設資料最大的問題就是

描述能力不足

展望

對於西門子的Mendix無程式碼平臺來說，最好的一個廣告就是特斯拉使用Mendix用4個月編寫完成了一個ERP。看到這個新聞的時候我只想說一句話

那是因為Elon Mask不是中國人，換個中國甲方試試！？

國內的幾個大廠的低程式碼/無程式碼平臺，做一些促銷表單應該是沒問題的。但是真正要達到替代應用程式的境界，難！

如何判斷一個X程式碼平臺是否有足夠的能力？只需要去看他們的資料結構定義功能，只有後設資料能力上來了，才有提升的機會。否則，只是靠幾個牛人拍腦袋想是沒用的。他們至少需要一個博士，去證明後設資料模型的圖靈完備性，否則做啥無程式碼？

這才是要點。

附加

目前加速程式碼編寫的工具不少，但是我只用一個工具JHipster，用它生成程式碼，然後自己改。這個又是一個很好的故事，我們下次聊。