低代碼不是行業毒瘤，你才是！

低代碼不是行業毒瘤，你才是！

文/明道云創始人任向暉

著名的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的觀點選編為頭條，那么也請置頂我的這篇。

祝讀者勞動節快樂！

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。