一直想寫篇文章，聊一聊“低代碼”這個話題，一方面，“低代碼”這個概念確實非常火，其熱度絲毫不亞于曾經的“中臺”，有人說，2021年是屬于“云原生”的時代，看起來我們每一年都在被技術的“娛樂圈”拋棄，明明連 Kubernetes 都還沒有入門呢？人們已然在歡呼雀躍般地聲稱要拋棄 Docker ，這個世界有時就是如此地魔幻，明明我們生活在一個擁有大量基礎設施的時代，我們不必再像前輩們“刀耕火種”一般地去開發軟體，可我們的生存空間為什么就越來越狹窄了呢？拼多多事件過去沒有多久，騰訊的陽光普照獎再次讓“打工魂”覺醒，也許果真像大魚海棠里設定的一樣，人的記憶只有7秒，而另一方面，我想結合我最近開發“作業流”的感受，來吐槽下這個看起來美好的“低代碼”，也許，對企業而言，引入“低代碼”的確能減少研發成本，可博主并不認為，它會降低業務本身的復雜性，如果所有聲稱“低代碼”或者“無代碼”的專案，最終依然需要研發人員來作為收場，對此，我想說，對不起，這不是我想要的“低代碼”，

低代碼發展現狀

或許，一個人成熟的標志就是，在面對一個未知的事物的時候，決不會不由分說地一通吐槽，就像一個人在職場上，你不能永遠都只是學會抱怨，相對于抱怨，人們更希望聽到的是解決方案，所以，一個人的成長，本質上就是不斷學會為自己、為別人找解決方案的程序，前者是為了認識自我，而后者是為了交換資源，所以，在聽我吐槽“低代碼”前，不妨先一起來看看低代碼的發展現狀，

國外趨勢

有人認為，“低代碼”的興起源于釘釘的低代碼應用 易搭 的落地，誠然，巨頭企業的每一個動向都引領著整個行業的風潮，可低代碼這個概念最早要追溯到1980年，彼時，IBM 的快速應用程式開發工具(RAD)被冠以新的名字——低代碼，這是低代碼這個概念首次面向大眾，此后的40年里，國外誕生了諸如 Outsystem 、Mendix 、 Zoho Creator 等等的產品，整體發展相對緩慢，直到2015年以后，AWS、Google、Microsoft 和 Oracle 等巨頭開始入局低代碼領域，2018年，西門子更是宣布以 6 億歐元收購低代碼應用開發領域的領導者 Mendix 、快速應用開發的低代碼平臺 Outsystem 獲得 3.6 億美金的投資，低代碼平臺市場開始火爆起來，我們所熟悉的 Power Platform，其實就是微軟的低代碼開發平臺，低代碼領域通常都需要大量的積累和研發，需要有10到20年左右的技術沉淀，

國內風云

國內的低代碼領域，相比國外發展起步較晚，可依然涌現出像牛刀、APICloud、iVX、搭搭云、氚云、簡道云、云表、宜搭云等等產品，從整體上而言，這類這類產品基本上都提供了可視化搭建環境，都聲稱無需編碼即可完成業務系統的搭建，其實，從一名程式員的初心出發，我們所做的一切努力都是為了以后不寫代碼，經常有人問，怎么樣可以做到零缺陷、零 Bug ，其實不寫代碼就好啦！我們并不擔心低代碼讓我們失業，相反地，如果低代碼可以消化掉 30% 的垃圾專案，那么，我們將會有更多的時間去做些有意義的事情，而不是在一個“劣幣驅逐良幣”的市場里，靠著 996 來爭個你死我活，而從低代碼的商業價值角度來看，Salesforce、Appian、Joget 這三家公司均已上市，Mendix 和 Outsystem 更是估值 10 億美元以上的獨角獸公司，這正是巨頭們入局低代碼的原因所在，

低代碼領域，目前關注的重點主要集中在：表單生成和處理、作業流生成和管理、辦公協作、人力資源、客戶關系、ERP 等企業應用上，就如同 SAP 、金蝶、 SCM 等企業軟體一樣，每一個軟體都曾聲稱能幫助企業解決某一類問題，低代碼領域同樣遵循“二八原則”，即 80% 的場景，通過定義的方法論、方式、工具集能夠實作；而剩下的 20% 的場景或許實作不了，需要使用者通過擴展的方式來自行解決，譬如，針對大多數企業都存在的 CRUD 的需求，通過在線的 Excel 表格來實作基于表的業務驅動，例如 SeaTable 就是這類主打協同作業的產品；針對大多數企業都存在的審批類的需求，則可以通過可視化的作業流設計系統來完成，例如 葡萄城 的 SpreadJS 和 活字格 ，同樣可以視為低代碼平臺，甚至早期的 .NET 開發者被人“黑”只會拖控制元件，這難道不是廣義上的低代碼嗎？

低代碼產品形態

搞清楚整個低代碼的發展現狀以后，那么，整個低代碼領域主要的產品形態有哪些呢？了解其主要的產品形態，對于我們形成低代碼的直觀印象非常有幫助，在我看來，主要分為四類：

• 表單生成類：以 宜搭云 和 JNPF 為代表，主張通過可視化的設計器來完成頁面布局、編排、設計，即所謂的“所見即所得”，類似的還有 iVX，
• 作業流生成類：以 Mendix 和 Outsystems 為代表，提供組件式的服務，通過編排作業流來實作特定的業務，即通過流程圖的方式來實作業務邏輯部分，不同的節點代表不同的功能，不同的線條代表不同的分支，
• 協同作業類：以 SeaTable 為代表，基于表的業務驅動開發平臺，可以以不同的維度管理資料、對資料可視化、共享協作等等，同時具備自動化規則、腳本運行等能力，
• 服務聚合類：以 APICloud 為代表，基于API聚合的組件市場工具，通過流程管理工具，可以管理整個應用的開發周期，從產品、設計開始，到研發測驗和運營，

所以，整體而言，低代碼產品的核心是表單引擎 和 流程引擎(BPM)，外圍支撐是BI引擎、*協同作業、服務聚合等等，目前，市面上主流的低代碼產品，表單引擎和流程引擎(BPM)基本是標配，所以，嚴格地說起來，上面的分類并不嚴謹，因為基本上都是混合式的產品形態，下面是部分低代碼產品的截圖：

低代碼研發痛點

相信大家都知道了，接下來的內容是本文真正的重點，為什么要這樣說呢？這主要和博主自身的作業有關系，簡單來說，公司需要一個想象中的可視化設計器，業務人員只需要通過拖拽就可以完成業務邏輯的編排，而開發人員則需要負責對外輸出組件供業務人員使用，這聽起來特別像我們剛剛討論的第二種產品形態對不對？聽起來非常美好對不對？我承認這個想法真的符合潮流、非常的“低代碼”，所以，我們前期采用了微軟的 Windows Workflow Foundation 框架，使用以后的效果大概是下面這個樣子：

多人協作不便

那么，我們在這個程序中到底遇到了哪些問題呢？首先，這種可視化編輯的場景，遇到的第一個問題就是多人協作，如果你使用過騰訊檔案、釘釘檔案這類在線檔案類產品，你應該能領悟到我說的這個點，微軟的這個框架是采用XMAL這種格式來儲存資料的，雖然理論上可以通過 Git 實作多人協作，實際維護起來表示非常地麻煩，所以，我們最終由單人去維護這些作業流，那么，更廣義上的低代碼又該如何解決這個問題呢？流程圖這種東西，就是一種看起來非常清晰，改起來非常麻煩的東西，就像一條鎖鏈一樣，你要不停地斷開和接上，

孱弱的表達能力

其次，是流程圖這種表現方式的“表達”問題，就像你如果需要在SQL里表示回圈要用到游標一樣，這類作業流都無法表達程式三個結構中的回圈，更不用說表達力孱弱的運算式啦，所以，這就造成一個非常尷尬的問題，你在流程圖里寫不了太復雜的運算式，一旦業務人員寫不出來，就需要開發人員去寫輔助性質的代碼，類似正則、字串插值、字串處理、格式化等等的函式或者API非常缺乏，當然，我最無法忍受的，就是組件與組件間傳值的方式，你除了回傳JSON和寫表再沒有其它方式，更何況這個JSON回傳給某個組件了，人家還未必能直接決議直接使用呢？因為編輯器無法系結這種復雜的資料結構，

混亂的變數和引數

接下來，我最想吐槽的是，關于全域變數和引數的問題，在流程圖中你經常需要各個分支的標志位(Flag)或者是臨時變數，然后你就看到了那種“變數滿天飛”的混亂局面，簡直像極了你剛開始寫的代碼，你需要順著每個線條，逐個點開每個組件的屬性面板，查看它都使用了哪些引數或者變數，至此，你終于明白了它的資料是如何流動的，從前，鄉愁是成千上萬行的代碼；現在，鄉愁是剪不斷理還亂的“蜘蛛網”，多年前，我對虛幻引擎(Unreal)的藍圖功能有多么憧憬；多年后，我對這種基于流程引擎的低代碼就有多排斥，尤其是，當我需要復用某一段邏輯的時候，我只能小心翼翼地選中節點和線條，然后再拷貝過去，

動態計算/事件順序/黑盒子

最后，我參考了一位被 Power Apps 所折磨的朋友的意見，除了上面提到的這些問題， 屬性面板或者公式無法使用動態計算的值，類似Vue 里面的計算屬性，從實際使用的體驗來看，這類以流程引擎和表單引擎為主要賣點的低代碼工具，其實都會存在這樣的問題，而面對這種問題，一般只能通過trick的手段來解決，同樣地，Power Apps 事件順序的不確定問題，因為低代碼實際上是框架提供了某種機制，可以幫你完成某個事情，所以，低代碼內部對于使用者來說，完全就是一個黑盒子，譬如 Power Apps 在無網路的環境下使用會卡頓，除錯起來非常不便等等，

本文小結

坦白來講，這篇博客實在沒什么“技術含量”，無非是按照一個月前的計劃在整理內容，我對“低代碼”持一種中立的態度，作為程式員，我是希望有這樣的技術來簡化流程，可以讓研發人員從枯燥的“增刪改查”中解放出來，留出時間去做更多有意義、有價值的事情，當我了解了低代碼和零代碼的差異以后，我突然明白，我需要的其實是零代碼，因為我希望那幫業務人員能自己搞定，這樣就不用再來煩我，可經歷這段時間的“低代碼”，我清醒地認識到，這個想法根本不現實，一來業務人員并不像他們想象的那樣，除了不會寫代碼以外無所不能；二來業務的復雜性滿足守恒定律，它永遠不會消失，只會從一種形式變成另一種形式，也許，低代碼真的能幫企業省不少錢；也許，企業最喜歡做的事情，就是花點小錢招人外包做這種事情，但我依然想告誡開發者們，不要去追逐這些看起來美好的東西，對企業來說，它今天使用 A 技術，明天使用 B 技術，完全無關緊要，可對于個人而言，這個選擇顯得非常重要，看一看曾經的 SAP 咨詢顧問就知道了，如果有一天 SAP 都倒閉了，你掌握著這些只有在 SAP 上能發揮作用的技術有什么用呢？對技術人員來說，學習通用型的知識和技能，永遠比把雞蛋放在一個籃子里要更保險，