低代碼真的是“行業(yè)毒瘤”?(低代碼 行業(yè)毒瘤)
放屁,現(xiàn)在那個(gè)程序員不在使用低代碼工具,你真的以為低代碼這個(gè)概念是最近才有的嗎?你懂個(gè)屁,低代碼一直都是高效的生產(chǎn)力工具;
這是我看到標(biāo)題為 《“行業(yè)毒瘤”低代碼》這篇文章的第一反應(yīng);
好了,平復(fù)一下激動(dòng)的心,在開始之前,考慮到有的小伙伴可能還不太了解低代碼開發(fā),咱們先介紹一下 “低代碼開發(fā)” 這個(gè)概念到底是什么;
低代碼的概念
低代碼開發(fā)(Low-Code Development,LCD),這個(gè)概念是在2011年被正式提出的,開發(fā)者主要通過圖形化用戶界面和配置來創(chuàng)建應(yīng)用軟件,而不是像傳統(tǒng)模式那樣主要依靠手寫代碼。對應(yīng)的,提供給開發(fā)者的這類低代碼開發(fā)功能實(shí)現(xiàn)的軟件,稱為低代碼開發(fā)平臺(tái)(Low-Code Development Platform, LCDP)。低代碼開發(fā)模式的開發(fā)者,通常不需要具備非常專業(yè)的編碼技能,或者不需要某一專門領(lǐng)域的編碼技能,而是可以通過平臺(tái)的功能和約束來實(shí)現(xiàn)專業(yè)代碼的產(chǎn)出。
從定義中我們可以看到,低代碼開發(fā)的工作方式主要依賴操作圖形化的用戶界面,包括拖拽控件,以及修改其中可被編輯區(qū)域的配置。這種可視化的開發(fā)方式,可以追溯到更早的 Dreamwaver 時(shí)期。而隨著前端項(xiàng)目的日趨復(fù)雜,這種方式已不再適應(yīng)現(xiàn)代項(xiàng)目的需求,于是漸漸被更專業(yè)的工程化的開發(fā)模式所取代。
但是,快速生成項(xiàng)目代碼的訴求從未消失。人們也慢慢找到了實(shí)現(xiàn)這個(gè)目的的兩種路徑:
一種是在高度定制化的場景中,基于經(jīng)驗(yàn)總結(jié),找到那些相對固定的產(chǎn)品形態(tài),例如公司介紹、產(chǎn)品列表、活動(dòng)頁面等,開放少量的編輯入口,讓非專業(yè)開發(fā)者也能使用,這其實(shí)就是無代碼方式了。
另一類則相反,順著早期可視化開發(fā)的思路,嘗試以組件化和數(shù)據(jù)綁定為基礎(chǔ),通過抽象語法或 IDE 來實(shí)現(xiàn)自由度更高、交互復(fù)雜度上限更高的頁面搭建流程。這種項(xiàng)目開發(fā)方式通常需要一定的開發(fā)經(jīng)驗(yàn)與編碼能力,只是和普通編碼開發(fā)方式相比,更多通過操作可視化工具的方式來達(dá)到整體效率的提升,因此被稱為低代碼開發(fā)。
在實(shí)際場景中,尤其是商用的低代碼平臺(tái)產(chǎn)品,往往提供的是上面兩種開發(fā)方式的結(jié)合。
低代碼開發(fā)的典型應(yīng)用場景
低代碼開發(fā)的一類典型應(yīng)用場景是在 PC 端中后臺(tái)系統(tǒng)的開發(fā)流程中,原因如下:
1:盡管中后臺(tái)系統(tǒng)的具體頁面布局并不固定,但整體 UI 風(fēng)格較統(tǒng)一,可以基于統(tǒng)一的 UI 組件庫來實(shí)現(xiàn)搭建,通過組件拖拽組合即可靈活組織成不同形態(tài)功能的頁面,因此適用于低代碼類型的開發(fā)模式。
2:中后臺(tái)系統(tǒng)涉及數(shù)據(jù)的增刪改查,需要有一定的編碼調(diào)試能力,無法直接通過 UI 交互完成,因此不適用無代碼開發(fā)模式。
以中后臺(tái)系統(tǒng)的開發(fā)為目標(biāo),低代碼開發(fā)的方式還可以細(xì)分為以下兩種:基于編寫 JSON 的開發(fā)方式,和基于可視化操作平臺(tái)的開發(fā)方式,下面我們來依次介紹一下。
基于編寫 JSON 的低代碼開發(fā)
當(dāng)我們?nèi)徱曇粋€(gè)項(xiàng)目前端部分的最終呈現(xiàn)時(shí),可以發(fā)現(xiàn):
1:一個(gè)項(xiàng)目的前端部分本質(zhì)上呈現(xiàn)的是通過路由連接的不同頁面。而前端開發(fā)的目標(biāo)就是最終輸出頁面的展示與交互功能。
2:如果學(xué)過瀏覽器基本原理,你會(huì)知道:每一個(gè)頁面的內(nèi)容在瀏覽器中,最終都?xì)w結(jié)為 DOM 語法樹(DOM Tree) 樣式(Style) 動(dòng)態(tài)交互邏輯(Dynamic Logic)。
3:在組件化開發(fā)的今天,一個(gè)規(guī)范定義的組件包含了特定功能的 DOM 子樹和樣式風(fēng)格。因此頁面的內(nèi)容又可以定義為:組件樹(Component Tree) 動(dòng)態(tài)交互邏輯(Dynamic Logic)。
而基于 JSON-Schema 的低代碼開發(fā)的切入邏輯是:
在特定場景下,例如開發(fā)中后臺(tái)增刪改查頁面時(shí),大部分前端手動(dòng)編寫的代碼是模式化的。
頁面組件結(jié)構(gòu)模板和相應(yīng)數(shù)據(jù)模型的代碼組織,可以替換為更高效的 JSON 語法樹描述。
通過制定用于編寫的 JSON 語法圖式(JSON Schema),以及封裝能夠渲染對應(yīng) JSON 語法樹的運(yùn)行時(shí)工具集,就可以提升開發(fā)效率,降低開發(fā)技術(shù)要求。
下圖中的代碼就是組件語法樹示例,我們通過編寫一個(gè)簡單的 JSON 語法樹以及對應(yīng)的編譯器,來展示低代碼開發(fā)的模式。
編寫 JSON 開發(fā)的缺點(diǎn)
但另一方面,這種方式也存在著一些不足:
輸入效率:單從組件結(jié)構(gòu)的描述而言,使用 JSON 描述的代碼量要多于同等結(jié)構(gòu)的 JSX 語法,對于有經(jīng)驗(yàn)的前端開發(fā)者而言,通常無法第一時(shí)間感受到效率的提升。
學(xué)習(xí)記憶成本:由于引入了新的 JSON 語法圖式,無論對于前端開發(fā)者、后端開發(fā)者還是非專業(yè)的人員來說,上手的學(xué)習(xí)成本都不可避免。此外,不同組件存在不同屬性,要在實(shí)際編寫過程中靈活運(yùn)用,對記憶量也是一個(gè)考驗(yàn)。而反復(fù)查閱文檔又會(huì)造成效率的下降(對于這個(gè)問題,有個(gè)優(yōu)化方案是利用 IDE Snippets 的選項(xiàng)功能生成對應(yīng)的語法提示)。
復(fù)用性和可維護(hù)性:對于多頁面存在可復(fù)用業(yè)務(wù)組件的情況,在 JSON 編寫的模式下往往需要手動(dòng)復(fù)制到各頁面 JSON 中,犧牲了復(fù)用組件的可維護(hù)性。此外,對于功能復(fù)雜的頁面,對應(yīng)的 JSON 長度也會(huì)讓維護(hù)體驗(yàn)變得不太美好。
問題排查難度增加:這個(gè)問題涉及面向人群,如果是非專業(yè)的人員從事 JSON 的開發(fā)過程,當(dāng)遇到問題時(shí),在如何排查上可能造成阻礙,因此通常需要配備額外的專業(yè)人員來提供技術(shù)支持。
針對編寫 JSON 過程中的輸入效率、記憶成本和可維護(hù)性等問題,許多低代碼工具進(jìn)一步提供了可視化操作平臺(tái)的工作方式。下面再讓我們來了解下,這種方式是怎么解決上述問題的。
可視化操作平臺(tái)的低代碼開發(fā)
可視化的低代碼操作平臺(tái)把編寫 JSON 的過程變成了拖拽組件和調(diào)試屬性配置,如下圖所示,這樣的交互方式對用戶來說更直觀友好,開發(fā)效率也會(huì)更高。
絕大部分的可視化操作平臺(tái)都將界面布局分為三個(gè)區(qū)域:左側(cè)的組件選擇區(qū),中部的預(yù)覽交互區(qū)以及右側(cè)的屬性編輯區(qū)。這三個(gè)區(qū)域的排布所對應(yīng)的,也是用戶生成頁面的操作流程:
首先,在左側(cè)面板中選擇組件。
然后,拖入中間預(yù)覽區(qū)域,并放置到合適的容器塊內(nèi)。
最后,調(diào)試右側(cè)面板中新移入的組件屬性。
調(diào)試完成后,進(jìn)行下一個(gè)組件的循環(huán)操作直到整個(gè)頁面搭建完成。
低代碼開發(fā)的產(chǎn)品有很多,其中既包括商用的產(chǎn)品,例如 Kony、OutSystems、Mendix、Appian、iVX(國內(nèi))等,也包括開源類的產(chǎn)品,例如阿里飛冰、百度 Amis、貝殼河圖、Vvvebjs、react-visual-editor 等。這里就不一一介紹了,感興趣的話,你可以進(jìn)一步搜索了解。
最后,低代碼真的不是行業(yè)毒瘤,這些年也一直都在不斷演進(jìn),很多人擔(dān)心低代碼會(huì)讓程序員丟掉飯碗,從而抨擊它,我嚴(yán)重懷疑這樣的人只能搞外包做企業(yè)官網(wǎng),因?yàn)榈痛a確實(shí)讓你不能行騙而丟了飯碗,再者說,后端運(yùn)維都有 Serverless 了,為什么前端不能有低代碼,不去提升技術(shù)能力,杞人憂天的胡謅八扯,說白了,程序員這個(gè)行業(yè),本身就是一個(gè)技術(shù)工種,就像早年間木匠鐵匠一樣,必然會(huì)被成熟的工業(yè)化替代,如果編程行業(yè)幾十年如一日的需要大量勞動(dòng)力加入,那就是真正的停止不前了,就像現(xiàn)在也一樣,十年前你會(huì)寫點(diǎn) HTML CSS 應(yīng)聘個(gè)前端開發(fā)完全沒問題,現(xiàn)在你如果還只會(huì)這些,早餓死了,哪些腳手架工具,框架代碼難道不是低代碼的一種體現(xiàn)嗎?
就現(xiàn)在來說,擁抱變化和發(fā)展,提升技術(shù)能力才是正道,做那個(gè)消滅程序員的程序員,直到有一天這個(gè)世界沒有程序員了,才是程序員最大的勝利;
晚安,42……