老翅寒暑

前言

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，用它生成代碼，然后自己改。這個又是一個很好的故事，我們下次聊。