為什么現(xiàn)在的低代碼平臺(tái)大多被抵制?(如何看待低代碼平臺(tái))
網(wǎng)上關(guān)于低代碼的爭論已久,每次有廠家宣傳自己的產(chǎn)品多好用,或者提問低代碼平臺(tái)好不好用的問題時(shí),底下都是唱衰一片,很少能有正面的評(píng)價(jià)。
這樣的現(xiàn)象不難看到,從低代碼誕生之初,這種輿論和怒火幾乎就沒有停止。為什么程序員和組織者不能接受低代碼,是因?yàn)榈痛a“降本增效”的愿景阻礙了公司的發(fā)展前途嗎?
情況恰恰相反,現(xiàn)在低代碼平臺(tái)正是因?yàn)闆]有實(shí)現(xiàn)最初“提效”的承諾,才導(dǎo)致如今不溫不火的局面,甚至到了草木皆兵的時(shí)刻,要理解這樣的原因,我們必須先看看現(xiàn)在市面上的低代碼平臺(tái)都有什么特點(diǎn)。
低代碼平臺(tái)的困境
將現(xiàn)在的低代碼平臺(tái)進(jìn)行主流分類,可以分成 3 種:
1.針對(duì)業(yè)務(wù)人員使用,也就是所謂的零代碼。無需任何專業(yè)開發(fā)者介入,由幾個(gè)Saas拼成的。
通常的適用場景就是BI/工作流/表單/在線表格,主要給業(yè)務(wù)人員使用,有權(quán)限和人員管理等。(例如明道、簡道、宜搭…名字后帶”云“的大多是這種模式)
2.針對(duì)企業(yè)推出的內(nèi)部開發(fā)框架,需要開發(fā)者,整體需要安裝到企業(yè)內(nèi)部。
不對(duì)個(gè)人開發(fā)者開放,無法生成單獨(dú)應(yīng)用代碼并獨(dú)立部署的;(例如:Zoho、Power Platform、活字格、輕流…)
3.需要部分研發(fā)人員,能生成代碼和框架,將應(yīng)用導(dǎo)出并部署到其他平臺(tái)或服務(wù)器上的,但業(yè)務(wù)人員沒法用(如Mendix、iVX、輕舟、靈犀、odoo、無遠(yuǎn)、牛刀…)
我們可以分點(diǎn)來討論下,為什么現(xiàn)在的低代碼平臺(tái)在推廣過程中會(huì)受到這么大的阻礙。
1.程序黑盒
低代碼的優(yōu)勢在于高度集成和抽象的組件模板,但所謂成也蕭何、敗也蕭何。
因?yàn)楦叨确庋b的功能模塊不可視,在開發(fā)時(shí)一旦遇到Bug、性能等問題,由于不清楚低代碼內(nèi)部的實(shí)現(xiàn)邏輯,問題排查無從下手,代碼調(diào)試要反復(fù)切換界面,開發(fā)人員只能等官方人員的調(diào)試和修改,自己是沒有任何辦法修理bug的。
大部分的低代碼平臺(tái)實(shí)際上并不具備語言屬性,更像是一個(gè)為企業(yè)定制好的產(chǎn)品,因?yàn)闊o法生成代碼,內(nèi)部邏輯又不能進(jìn)行整修,一旦低代碼平臺(tái)出現(xiàn)什么事故,或者跑路不干了,就意味著在低代碼平臺(tái)上付出的所有心血都付之一炬,沒有任何討還的可能。
這意味著把自己的命懸在別人的刀下,哪怕能換得一些效率的提升(能不能提升可能還得打一個(gè)問號(hào)),損失的卻是自己的所有主動(dòng)權(quán),甚至命脈。因此,作為一個(gè)技術(shù)的高管,是不敢貿(mào)然采用這種方案的。
2.不信任,和開發(fā)者自身的實(shí)力下降
低代碼平臺(tái)通過拖拽的方式生成應(yīng)用,但不生成代碼,這意味著程序員對(duì)這個(gè)東西是陌生的,哪怕在日新月異的互聯(lián)網(wǎng)技術(shù)人群中,學(xué)習(xí)新東西是一直要保持的習(xí)慣,但對(duì)于一種“根本不生成代碼”的平臺(tái),他們天生就懷著抵觸心理,而且是水平越高的程序員,抵觸就越嚴(yán)重;
一方面,這意味著放棄他們的強(qiáng)項(xiàng),踏入一個(gè)完全未知的陌生領(lǐng)域,跟所有人在一個(gè)水平線上“同臺(tái)競技”,另一方面,長期使用低代碼,或是不生成代碼的產(chǎn)品開發(fā),必然造成專業(yè)能力的退化,這意味丟掉飯碗、喪失競爭力,沒有程序員會(huì)在這樣的情況下選擇相信一個(gè)低代碼平臺(tái)
3.功能不完備
據(jù) Gartner 統(tǒng)計(jì),當(dāng)前,國內(nèi)LCAP(低代碼應(yīng)用開發(fā)平臺(tái))滲透率尚不足 5%。
首要的問題就在于,供應(yīng)端的功能供給不足,由于部分行業(yè)的場景復(fù)雜,表單驅(qū)動(dòng)型和基于 BPM 的低代碼產(chǎn)品不能夠滿足要求,這也是市面現(xiàn)存的低代碼平臺(tái)最核心的痛點(diǎn):開發(fā)能力不足。
如果說一個(gè)低代碼平臺(tái)真能實(shí)現(xiàn)5倍10倍開發(fā)效率的提升,在增效的前提下引用靈活的代碼接口處理定制化的需求,哪怕是冒著以上兩種風(fēng)險(xiǎn),在這樣的利益誘導(dǎo)下,很多公司也會(huì)選擇鋌而走險(xiǎn)。
但低代碼平臺(tái)自身的能力不足,就意味著一切美夢都只是泡影,只要生產(chǎn)力的需求沒有提上來,低代碼再怎么宣傳和推廣也是無濟(jì)于事,B端C端用戶們會(huì)用使用體驗(yàn)做出自己的選擇,目前的局面就是這種解釋的最好反映。
通過上面的論述,我們可以發(fā)現(xiàn),不生成代碼的低代碼平臺(tái),本身可能就是個(gè)偽命題。
我個(gè)人對(duì)不生成代碼的平臺(tái)很難抱有認(rèn)同,就是這個(gè)原因,而在能生成代碼的平臺(tái)中,國外有Mendix、Outsystems做得比較成熟和完備。
國內(nèi)有網(wǎng)易的 Codewave (但只面對(duì)企業(yè))、牛刀(功能缺失嚴(yán)重,架構(gòu)也比較老)、iVX(相對(duì)較好)、odoo(前端后端不分,成本高)等等,以后我會(huì)出一篇更詳細(xì)的討論生成代碼式的低代碼平臺(tái)點(diǎn)評(píng),歡迎大家關(guān)注捧個(gè)場。