文/明道雲創始人任向暉

著名的IT諮詢公司Thoughtworks在台灣有一名徐姓CTO。 他曾經在自己的視頻號上公開攻擊低代碼市場，列出的理由卻十分可笑。 我看了全文後，相信這位CTO根本沒有動手實踐過，至少沒有全面研究過，完全在望文生義，自我想像。

本來我也懶得回應這種低劣的行業評論，可是世道險惡，我心中的IT媒體聖地InfoQ居然在節前發表頭條文章《為什麼我說低代碼是"行業毒瘤"？ 》。

在科技行業，各種技術熱點層出不窮，褒貶爭議也永遠在起伏抑揚。 可是，我從業二十多年，還沒看到過一個科技媒體用"毒瘤"這種詞彙來指責一個技術門類。 我真不知道這位CTO從哪裡來的憤慨？ InfoQ出於什麼動機要將這種文章作為頭條發表？

情緒先放一下。 我們先講道理。

低代碼預設的人群是初級和入門的人？

徐CTO認為LCAP產品是為入門程式師準備的，程式師成長了，就用不上了。 甚至拿低代碼平臺和Scratch兒童程式設計來類比。 這是對低代碼產品目標的根本性誤解。

這一代的LCAP毅然決然地要面向程式師以外的人，尤其是有一定IT素養的業務人員。 他們在企業組織中往往是業務流程設計和管理的骨幹人員，但是為了實現數位化工具，他們不得不費老大勁和開發人員溝通需求。 業務的Know- How並不能直接表達為軟體需求，所以為了溝通清楚一個IT系統的需求和標準，不得不嘴上說著，手上畫著，業務人員恨不得和開發人員靈魂合體。

這個過程就是這麼難。 IT行業的人對行業需求一知半解，不知輕重。 行業專家對軟體實現機制也是門外漢。 能夠讓行業經驗和軟體技術成功融合的產品和項目實屬罕見。

儘管這麼難，我依然看到很多傳統行業的人不知畏懼地投入，做出一個又一個專業度有限的軟體系統。 這樣的系統往往缺陷率高，抽象水準低，擴展性差。 即便這樣，能夠做出一個可用的系統已經屬於幸運者。 大部分定製開發的系統都存在嚴重的可用性問題，最終被束之高閣。 我聽到過很多次這樣的表述：「我們幾年前花XX萬做了一個系統，後來也用不下去...."。 這種資源浪費徐CTO想必是沒有感同身受的。

站在服務者的角度，有多少軟體開發公司的工程師們被派去遙遠的城市，在城鄉結合部從事外包駐場開發。 這些軟體工程師拿的薪水今天和農民工幾乎一樣，是真正意義上的碼農。 他們在客戶的場地，可不能像徐CTO那樣揮斥方遒，相反，他們要麼在無盡地等待客戶領導的需求，要麼就是頂著進度的壓力挑燈夜戰。

你說這樣的工作方式和產業現狀值得維護？ 你說程式師在這樣的環境中能夠成長？

我們不可能等待程式師成長，就算成長，數量也遠遠不夠。 產業數位化唯一的解決方案就是讓訊息系統的建設離開對程式師的依賴，離開對專業DevOps過程的依賴，讓更多的角色可以有效地參與進來。 這些角色包括行業內的業務專家，運營和管理專家，軟體行業內的產品經理，專案經理和實施專家。 有了這些擴充的參與者，企業數位化建設就會大幅加速。 甚至，連質量都遠遠高於傳統開發模式。

第二，徐CTO認為低代碼平臺暗含巨大的變革成本。 他說的對，不過他說的變革成本和我們面臨的不是一件事。 他說低代碼平台改變了原有開發過程中的工作方式，不僅沒有提高效率，反而增加了很多試錯成本。 而我認為，真正的軟體開發團隊的工作方式不需要任何的變化。 你們應該繼續使用日新月異的技術棧從事原生軟體開發。 真正的LCAP不是為了去取代高級語言的。

企業應用領域的LCAP到底取代的是什麼呢？ 一句話 —— 那些模式高度一致的企業中後台應用。 形象一點說，就是長這個樣子的應用：

是不是很眼熟？ 無論CRM，ERP，還是ERP，MES，這些軟體門類都是屬於企業中後台應用，它們都是圍繞關係資料庫而建立數據管理和工作流程。 實際上，企業應用中90%以上的應用都是這個模型，業內稱為CRUD（數據增刪查改）應用。 正是因為模式上的一致性，讓我們得以有機會抽象出這類應用構建所需要的基本要素，並且將這些要素的顆粒度充分提高，靈活組合，得以滿足千變萬化的具體場景。 在我們的明道雲中，這些基本要素包括工作表、視圖、統計、用戶許可權、工作流和頁面。 每一個要素都通過可視化應用配置的方式來面向非程式師，只有在個別的環節允許程式師寫一些代碼來進一步提高靈活性。

我調研過，在定製開發的企業應用中，目前有九成以上都使用了Ants前端框架，這是阿裡巴巴提供的一個開源前端元件。 這個元件所提供的所有範式基本上就圍繞CRUD場景而展開的。 所以，即使使用Java、C#或者PHP等高級語言開發的原生應用，也遵照的是同一個範式。 既然模型如此穩定，為什麼每個應用都要從第一行代碼開始寫起呢？ 這就是LCAP產品為之努力的方向，在這個特定的應用類型下，用積木搭建的方式來取代DevOps過程，因為後者就是離不開程式師。

有人又質疑，企業應用沒有增刪查改那麼簡單。 高級的ERP怎麼怎麼樣複雜，演算法如何如何先進，低代碼都搞不定，像你們明道雲標榜的零代碼肯定沒戲。 有這個疑問的人，我建議你先動手實踐。 再不濟，看看案例和視頻也可以。 你要相信，一代一代產品的努力，我們總是無限接近最佳的結果。 企業應用中的複雜問題並不是只有代碼開發一種方案，LCAP或者稱為APaaS的這一代產品不可能停留在20年前，我們只是用了不同的解決方案。 航天發動機夠複雜吧？ 人家是怎麼解決的？ 是將巨大的複雜問題拆解成若干個子系統，每個子系統再拆分為子子系統，最終落實一個個的簡單問題。 APaaS也不例外。 有興趣的，可以擴展閱讀《APaaS搞不定複雜應用，是這樣嗎？ 》

懷疑是沒有用的，動手幹才是真諦。

所以，我所看到的變革成本，正是徐CTO你這種人的存在。 倚仗著專業出身，大廠履歷，幹著指點江山的便宜活。 IT評論家可以存在，但ThoughtWorks這樣的組織，應該站在產業的最前沿，給大夥的創新帶個頭，而不是老氣橫秋地指摘創新行動。 創新的言論可能天真，守舊的語氣實在令人厭惡。 他還在一個小視頻里質問低代碼產品是否「圖靈完備」？ 掉書袋掉到褲襠裡了。

低代碼不會是永遠的風口，那又怎麼樣？

徐CTO認為今天低代碼的熱度是不會持續的，風口總歸會過去。 但這等於是廢話。 沒有不會過去的風口。 你知道1970年企業IT界最大的風口是什麼嗎？ 關係資料庫！ 今天你聽到有人說關係資料庫是風口嗎？ 當然不會，但是你看看關係資料庫今天的普及程度和使用率？

連我自己都希望這個風口快點過去。 天天被行業談論，難免遇到你這種幺蛾子。 只有風口過去，APaaS才能真正主流化，傳統用戶開始採納，產品變得更加成熟，紛爭變得沒有意義。 這是IT行業幾十年來不變的節奏。 如果你真的理解IT行業的真諦，就不會說出"低代碼是行業毒瘤"這種話來。 至於InfoQ的編輯，也請你們回歸到技術媒體的本分，多提供知識和方法論，少一些妄斷。 如果你把徐CTO的觀點選編為頭條，那麼也請置頂我的這篇。

祝讀者勞動節快樂！