低代碼不是行業(yè)毒瘤，你才是（低代碼不是行業(yè)毒瘤,你才是!）
文/明道云創(chuàng)始人任向暉
著名的IT咨詢公司ThoughtWorks在中國有一名徐姓CTO。他曾經(jīng)在自己的視頻號上公開攻擊低代碼市場，列出的理由卻十分可笑。我看了全文后，相信這位CTO根本沒有動手實踐過，至少沒有全面研究過，完全在望文生義，自我想象。
本來我也懶得回應(yīng)這種低劣的行業(yè)評論，可是世道險惡，我心中的IT媒體圣地InfoQ居然在節(jié)前發(fā)表頭條文章《為什么我說低代碼是“行業(yè)毒瘤”？》。
在科技行業(yè)，各種技術(shù)熱點層出不窮，褒貶爭議也永遠(yuǎn)在起伏抑揚?？墒?，我從業(yè)二十多年，還沒看到過一個科技媒體用“毒瘤”這種詞匯來指責(zé)一個技術(shù)門類。我真不知道這位CTO從哪里來的憤慨？InfoQ出于什么動機(jī)要將這種文章作為頭條發(fā)表？
情緒先放一下。我們先講道理。
低代碼預(yù)設(shè)的人群是初級和入門的人？
徐CTO認(rèn)為LCAP產(chǎn)品是為入門程序員準(zhǔn)備的，程序員成長了，就用不上了。甚至拿低代碼平臺和Scratch兒童編程來類比。這是對低代碼產(chǎn)品目標(biāo)的根本性誤解。
這一代的LCAP毅然決然地要面向程序員以外的人，尤其是有一定IT素養(yǎng)的業(yè)務(wù)人員。他們在企業(yè)組織中往往是業(yè)務(wù)流程設(shè)計和管理的骨干人員，但是為了實現(xiàn)數(shù)字化工具，他們不得不費老大勁和開發(fā)人員溝通需求。業(yè)務(wù)的Know- How并不能直接表達(dá)為軟件需求，所以為了溝通清楚一個IT系統(tǒng)的需求和標(biāo)準(zhǔn)，不得不嘴上說著，手上畫著，業(yè)務(wù)人員恨不得和開發(fā)人員靈魂合體。
這個過程就是這么難。IT行業(yè)的人對行業(yè)需求一知半解，不知輕重。行業(yè)專家對軟件實現(xiàn)機(jī)制也是門外漢。能夠讓行業(yè)經(jīng)驗和軟件技術(shù)成功融合的產(chǎn)品和項目實屬罕見。
盡管這么難，我依然看到很多傳統(tǒng)行業(yè)的人不知畏懼地投入，做出一個又一個專業(yè)度有限的軟件系統(tǒng)。這樣的系統(tǒng)往往缺陷率高，抽象水平低，擴(kuò)展性差。即便這樣，能夠做出一個可用的系統(tǒng)已經(jīng)屬于幸運者。大部分定制開發(fā)的系統(tǒng)都存在嚴(yán)重的可用性問題，最終被束之高閣。我聽到過很多次這樣的表述："我們幾年前花XX萬做了一個系統(tǒng)，后來也用不下去…."。這種資源浪費徐CTO想必是沒有感同身受的。
站在服務(wù)者的角度，有多少軟件開發(fā)公司的工程師們被派去遙遠(yuǎn)的城市，在城鄉(xiāng)結(jié)合部從事外包駐場開發(fā)。這些軟件工程師拿的薪水今天和農(nóng)民工幾乎一樣，是真正意義上的碼農(nóng)。他們在客戶的場地，可不能像徐CTO那樣揮斥方遒，相反，他們要么在無盡地等待客戶領(lǐng)導(dǎo)的需求，要么就是頂著進(jìn)度的壓力挑燈夜戰(zhàn)。
你說這樣的工作方式和產(chǎn)業(yè)現(xiàn)狀值得維護(hù)？你說程序員在這樣的環(huán)境中能夠成長？
我們不可能等待程序員成長，就算成長，數(shù)量也遠(yuǎn)遠(yuǎn)不夠。產(chǎn)業(yè)數(shù)字化唯一的解決方案就是讓信息系統(tǒng)的建設(shè)離開對程序員的依賴，離開對專業(yè)DevOps過程的依賴，讓更多的角色可以有效地參與進(jìn)來。這些角色包括行業(yè)內(nèi)的業(yè)務(wù)專家，運營和管理專家，軟件行業(yè)內(nèi)的產(chǎn)品經(jīng)理，項目經(jīng)理和實施專家。有了這些擴(kuò)充的參與者，企業(yè)數(shù)字化建設(shè)就會大幅加速。甚至，連質(zhì)量都遠(yuǎn)遠(yuǎn)高于傳統(tǒng)開發(fā)模式。
第二，徐CTO認(rèn)為低代碼平臺暗含巨大的變革成本。他說的對，不過他說的變革成本和我們面臨的不是一件事。他說低代碼平臺改變了原有開發(fā)過程中的工作方式，不僅沒有提高效率，反而增加了很多試錯成本。而我認(rèn)為，真正的軟件開發(fā)團(tuán)隊的工作方式不需要任何的變化。你們應(yīng)該繼續(xù)使用日新月異的技術(shù)棧從事原生軟件開發(fā)。真正的LCAP不是為了去取代高級語言的。
企業(yè)應(yīng)用領(lǐng)域的LCAP到底取代的是什么呢？一句話 —— 那些模式高度一致的企業(yè)中后臺應(yīng)用。形象一點說，就是長這個樣子的應(yīng)用：
是不是很眼熟？無論CRM，ERP，還是ERP，MES，這些軟件門類都是屬于企業(yè)中后臺應(yīng)用，它們都是圍繞關(guān)系數(shù)據(jù)庫而建立數(shù)據(jù)管理和工作流程。實際上，企業(yè)應(yīng)用中90%以上的應(yīng)用都是這個模型，業(yè)內(nèi)稱為CRUD（數(shù)據(jù)增刪查改）應(yīng)用。正是因為模式上的一致性，讓我們得以有機(jī)會抽象出這類應(yīng)用構(gòu)建所需要的基本要素，并且將這些要素的顆粒度充分提高，靈活組合，得以滿足千變?nèi)f化的具體場景。在我們的明道云中，這些基本要素包括工作表、視圖、統(tǒng)計、用戶權(quán)限、工作流和頁面。每一個要素都通過可視化應(yīng)用配置的方式來面向非程序員，只有在個別的環(huán)節(jié)允許程序員寫一些代碼來進(jìn)一步提高靈活性。
我調(diào)研過，在定制開發(fā)的企業(yè)應(yīng)用中，目前有九成以上都使用了Ants前端框架，這是阿里巴巴提供的一個開源前端組件。這個組件所提供的所有范式基本上就圍繞CRUD場景而展開的。所以，即使使用Java、C#或者PHP等高級語言開發(fā)的原生應(yīng)用，也遵照的是同一個范式。既然模型如此穩(wěn)定，為什么每個應(yīng)用都要從第一行代碼開始寫起呢？這就是LCAP產(chǎn)品為之努力的方向，在這個特定的應(yīng)用類型下，用積木搭建的方式來取代DevOps過程，因為后者就是離不開程序員。
有人又質(zhì)疑，企業(yè)應(yīng)用沒有增刪查改那么簡單。高級的ERP怎么怎么樣復(fù)雜，算法如何如何先進(jìn)，低代碼都搞不定，像你們明道云標(biāo)榜的零代碼肯定沒戲。有這個疑問的人，我建議你先動手實踐。再不濟(jì)，看看案例和視頻也可以。你要相信，一代一代產(chǎn)品的努力，我們總是無限接近最佳的結(jié)果。企業(yè)應(yīng)用中的復(fù)雜問題并不是只有代碼開發(fā)一種方案，LCAP或者稱為APaaS的這一代產(chǎn)品不可能停留在20年前，我們只是用了不同的解決方案。航天發(fā)動機(jī)夠復(fù)雜吧？人家是怎么解決的？是將巨大的復(fù)雜問題拆解成若干個子系統(tǒng)，每個子系統(tǒng)再拆分為子子系統(tǒng)，最終落實一個個的簡單問題。APaaS也不例外。有興趣的，可以擴(kuò)展閱讀《APaaS搞不定復(fù)雜應(yīng)用，是這樣嗎？》
懷疑是沒有用的，動手干才是真諦。
所以，我所看到的變革成本，正是徐CTO你這種人的存在。倚仗著專業(yè)出身，大廠履歷，干著指點江山的便宜活。IT評論家可以存在，但ThoughtWorks這樣的組織，應(yīng)該站在產(chǎn)業(yè)的最前沿，給大伙的創(chuàng)新帶個頭，而不是老氣橫秋地指摘創(chuàng)新行動。創(chuàng)新的言論可能天真，守舊的語氣實在令人厭惡。他還在一個小視頻里質(zhì)問低代碼產(chǎn)品是否"圖靈完備"？掉書袋掉到褲襠里了。
低代碼不會是永遠(yuǎn)的風(fēng)口，那又怎么樣？
徐CTO認(rèn)為今天低代碼的熱度是不會持續(xù)的，風(fēng)口總歸會過去。但這等于是廢話。沒有不會過去的風(fēng)口。你知道1970年企業(yè)IT界最大的風(fēng)口是什么嗎？關(guān)系數(shù)據(jù)庫！今天你聽到有人說關(guān)系數(shù)據(jù)庫是風(fēng)口嗎？當(dāng)然不會，但是你看看關(guān)系數(shù)據(jù)庫今天的普及程度和使用率？
連我自己都希望這個風(fēng)口快點過去。天天被行業(yè)談?wù)摚y免遇到你這種幺蛾子。只有風(fēng)口過去，APaaS才能真正主流化，傳統(tǒng)用戶開始采納，產(chǎn)品變得更加成熟，紛爭變得沒有意義。這是IT行業(yè)幾十年來不變的節(jié)奏。如果你真的理解IT行業(yè)的真諦，就不會說出"低代碼是行業(yè)毒瘤"這種話來。至于InfoQ的編輯，也請你們回歸到技術(shù)媒體的本分，多提供知識和方法論，少一些妄斷。如果你把徐CTO的觀點選編為頭條，那么也請置頂我的這篇。
祝讀者勞動節(jié)快樂！
