加勒比无码一区人妻,国产亚洲欧美在线观看三区

2022，低代碼徹底火了，甚至火到?jīng)]有點(diǎn)相關(guān)經(jīng)驗(yàn)，都不好意思出去面試的程度，堪稱lowcode“元年”。在整個(gè)互聯(lián)網(wǎng)大裁員的背景下，無論你是否相信它是降本提效的利器，彷佛都不重要了。因?yàn)樾袠I(yè)趨勢(shì)總是這般浩浩蕩蕩，是不以個(gè)人意志為轉(zhuǎn)移的。從下圖某技術(shù)峰會(huì)的分享主題中就可見一斑。

剛好筆者最近正在開發(fā)一個(gè)B端低代碼的平臺(tái)。所以，想把這段時(shí)間的感悟整理一下與大家分享一些。不過，開頭先聲明一點(diǎn)，本文只聊觀點(diǎn)與感悟，不聊具體技術(shù)細(xì)節(jié)。

01
低代碼的產(chǎn)生背景

互聯(lián)網(wǎng)產(chǎn)品趨于標(biāo)準(zhǔn)化

據(jù)我觀察，有相當(dāng)一部分的程序員一提起低代碼就搖頭say no，表示曾經(jīng)被這些低代碼平臺(tái)“傷害過”，因?yàn)楫a(chǎn)品需求一旦涉及平臺(tái)暫不支持的功能，輕則導(dǎo)致加班返工，重則績(jī)效堪憂，甚至丟了工作。

這是一個(gè)新事物發(fā)展初期必經(jīng)的一個(gè)階段: 與現(xiàn)有環(huán)境水土不服。假如站在更高的角度，設(shè)想一下: 當(dāng)有一天，你的老板宣布，產(chǎn)品經(jīng)理以后提的需求一律不得超出低代碼平臺(tái)支持的能力范圍時(shí)，該作何感想。不要輕易說不可能，因?yàn)橘Y本的本質(zhì)就是追逐利潤(rùn)，假如由于這些非標(biāo)需求額外付出的開發(fā)成本，創(chuàng)造不了預(yù)期的收益，那對(duì)那些試錯(cuò)成本寬容度較低的團(tuán)隊(duì)而言，這些需求完全沒有存在的必要（回頭想一想，你的產(chǎn)品經(jīng)理提的那些奇奇怪怪且上線沒幾天就又改回去的需求，你真的認(rèn)為有價(jià)值嘛）。

了解點(diǎn)軟件外包行業(yè)的都知道，很多外包訂單都是先copy一個(gè)個(gè)的模版項(xiàng)目，在之上稍加改動(dòng)即可交付。因?yàn)楹退麄儗?duì)接的大部分客戶需求都很標(biāo)準(zhǔn)化。比如，客戶需要開發(fā)一個(gè)H5商城，商品、訂單、物流再加一個(gè)商品運(yùn)營(yíng)后臺(tái)就完全可以滿足需求了，甚至不在意UI的樣式與競(jìng)品一模一樣。不過這里也不排除有定制化開發(fā)的報(bào)價(jià)相比完全套模版會(huì)高出一大截的因素，但這也至少說明這些非標(biāo)需求是錦上添花的功能，根本不是剛需。

其實(shí)大廠也有這個(gè)趨勢(shì)。畢竟各廠的業(yè)務(wù)范圍越來越出現(xiàn)交叉的態(tài)勢(shì)，產(chǎn)品層面也都是互相copy，真正具有創(chuàng)新性的產(chǎn)品越來越少。C端的產(chǎn)品，尤其在一些大廠充分競(jìng)爭(zhēng)或者優(yōu)勢(shì)的業(yè)務(wù)領(lǐng)域，因?yàn)橐非骍I設(shè)計(jì)、交互、產(chǎn)品體驗(yàn)的差異性，所以相對(duì)不容易標(biāo)準(zhǔn)化。比如每年雙11的促銷各家要緊跟潮流，玩法每年都不盡相同，這種就很難標(biāo)準(zhǔn)化。但大部分的B端產(chǎn)品，對(duì)定制化要求不高，隨著產(chǎn)品形式的固化，用戶已然形成了一套約定俗成的交互習(xí)慣。

應(yīng)用開發(fā)的技術(shù)棧趨于成熟

就拿前端出活的主力:js框架來說，vue、react雖然還在大版本的迭代，但對(duì)整個(gè)開發(fā)方式的影響，已經(jīng)不足以與15、16年jQuery到現(xiàn)代框架的那種革命性相提并論了。更多是一些類如更靈活的邏輯拆分、服務(wù)端渲染等方面的優(yōu)化。針對(duì)前端開發(fā)中的痛點(diǎn)，拆分出的比如構(gòu)建工具、前端框架、框架之上的UI組件庫(kù)、跨端等等各個(gè)技術(shù)領(lǐng)域的邊界，也都劃分的比較明確了，且發(fā)展日趨成熟。這是前端低代碼出現(xiàn)的技術(shù)背景。

02
前端低代碼實(shí)現(xiàn)

筆者對(duì)低代碼的理解是: 可以通過配置化的低成本交互方式（主流是拖拽）加上少量的一些膠水代碼，去滿足一類應(yīng)用的需求。這里筆者以發(fā)展更加成熟的B端低代碼講述，C端也是很類似，但是因?yàn)闃邮健?dòng)畫等定制要求要比B端的復(fù)雜許多，所以目前前端低代碼相對(duì)成熟的應(yīng)用是在B端。低代碼實(shí)現(xiàn)原理其實(shí)非常簡(jiǎn)單，就是先預(yù)置豐富的原子組件，通過拖拽選擇所需組件在畫板上進(jìn)行位置的編排。之后，進(jìn)行一些組件屬性的設(shè)置。

最終生產(chǎn)出一份jsonSchema或者供開發(fā)者二次開發(fā)的“源代碼”，驅(qū)動(dòng)用戶端的內(nèi)容渲染。原理雖然簡(jiǎn)單明確，但它也有一些實(shí)現(xiàn)難點(diǎn)。比如以下幾種：

一、宏觀設(shè)計(jì)

首先設(shè)計(jì)一個(gè)能夠面向不同業(yè)務(wù)場(chǎng)景的低代碼項(xiàng)目，是個(gè)不小的挑戰(zhàn)。比如一個(gè)公司級(jí)別的低代碼項(xiàng)目，目標(biāo)是賦能各條業(yè)務(wù)線。這個(gè)就會(huì)有一個(gè)問題：每個(gè)業(yè)務(wù)對(duì)低代碼平臺(tái)的能力要求是不同的，除了大量可復(fù)用的功能，肯定也會(huì)有不少的定制化需求。甚至各條業(yè)務(wù)線的產(chǎn)品形態(tài)很不一致，有面向C端的，有面向B端的。

如果是中心化的思想，一套低代碼平臺(tái)，滿足各業(yè)務(wù)線的需求，首先人力成本很難均攤下去，其次平臺(tái)隨著接入業(yè)務(wù)線增多，不可避免的會(huì)變得臃腫不堪，難以維護(hù)。如果每個(gè)業(yè)務(wù)線都獨(dú)立做一套符合自身業(yè)務(wù)特性的低代碼，這樣難度會(huì)降低不少，但也意味著公司級(jí)別的低代碼物料復(fù)用變得困難。講下業(yè)界目前比較流行的解決方案：

1、在公司級(jí)甚至業(yè)界推動(dòng)低代碼協(xié)議統(tǒng)一。這樣就讓跨業(yè)務(wù)甚至業(yè)界的物料復(fù)用變得可能，阿里前端委員會(huì)為此付出了不少努力，大家有空可以了解下。

2、將低代碼架構(gòu)分層。先有一個(gè)低代碼基礎(chǔ)架構(gòu)，再用它去“生成”一個(gè)個(gè)面向具體業(yè)務(wù)場(chǎng)景的低代碼平臺(tái)。那么如何設(shè)計(jì)好這個(gè)“生成低代碼平臺(tái)的低代碼平臺(tái)”就成為了重中之中。這有點(diǎn)類似于低代碼“中臺(tái)”與“前臺(tái)”的關(guān)系。

二、實(shí)現(xiàn)細(xì)節(jié)

1、事件編排

下圖就是目前最常見的一種設(shè)計(jì)，可以配置點(diǎn)擊一個(gè)button時(shí)，要觸發(fā)哪種類型的事件，事件觸發(fā)要調(diào)用哪些函數(shù)，一般都會(huì)內(nèi)置一些比較常見的函數(shù)，比如打開一個(gè)Modal框等。如果內(nèi)置不滿足需求，就需要插入一些定制化的代碼。

2、狀態(tài)聯(lián)動(dòng)

這個(gè)相對(duì)好解決一些。阿里的formily、x-render、jsonschema-form等這些成熟方案的都能夠解決，他們之間的差異更多的是在聯(lián)動(dòng)性能上，不過這也是在超長(zhǎng)表單場(chǎng)景下差距才會(huì)比較明顯。

以下是阿里lowcode-engine的交互設(shè)計(jì)。

這個(gè)平臺(tái)內(nèi)置的相對(duì)簡(jiǎn)單。我接觸過的內(nèi)置相對(duì)豐富的是iofod這個(gè)全場(chǎng)景低代碼平臺(tái)，這里為他們的開發(fā)者打個(gè)廣告。筆者還與他們的開發(fā)者加了好友，吃驚的是這么大的工作量竟然是一個(gè)人完成的，體驗(yàn)下來比很多公司團(tuán)隊(duì)級(jí)的產(chǎn)品都用心。

3、異步數(shù)據(jù)綁定

傳統(tǒng)的前端開發(fā)大量時(shí)間其實(shí)是花在與后端接口的對(duì)接上，這些工作在目前前端低代碼的開發(fā)模式中，一點(diǎn)都不會(huì)少。

如下圖，你需要一個(gè)表單回填的功能。后端給的詳情數(shù)據(jù)，與前端表單需要的格式差異很大，這里就不得不去手寫一個(gè)轉(zhuǎn)換函數(shù)去解決。

這也是低代碼平臺(tái)大家詬病最多的一點(diǎn)，即：還是需要寫代碼。但是低代碼的價(jià)值，從來就不是追求一行代碼不寫，而是讓開發(fā)者盡量的少寫代碼。有人說，我copy代碼其實(shí)來的更快，而且這功能我開發(fā)起來很熟，代碼不會(huì)有任何問題。但是，你是不是經(jīng)常在提交cr之后，又悄悄的commit了幾個(gè)fix呢。最可怕的是測(cè)試也覺得這功能很常見，不用細(xì)測(cè)了，將隱患帶上了線。試著回顧一下過往項(xiàng)目的bug列表，是不是很多都是因?yàn)椴唤?jīng)意的走神或者疏忽造成的。這就是低代碼目前就能夠解決的一個(gè)問題，通過內(nèi)置一些常見的功能，減少常見功能的開發(fā)、測(cè)試成本。使大部分功能的交付質(zhì)量，不依賴于某一個(gè)開發(fā)者在某一段時(shí)間的開發(fā)經(jīng)驗(yàn)、精力及水平。這是筆者認(rèn)為，現(xiàn)階段低代碼技術(shù)的最大價(jià)值。

03
低代碼對(duì)行業(yè)的影響

框架、類庫(kù)的作者也許會(huì)喜聞樂見

因?yàn)橹耙嫦虿煌瑢哟蔚那岸碎_發(fā)者，框架、庫(kù)的作者往往會(huì)在API設(shè)計(jì)時(shí)盡量追求友好易懂，但這種追求會(huì)在其他方面比如性能方面作出妥協(xié)。這就像尤雨溪說的那樣，框架開發(fā)有時(shí)更像是“帶著鐐銬跳舞”。很多時(shí)侯，用起來“爽”與高性能是一件不可兼得的事情，編程語言的發(fā)展就是一例，java、python、js等這些高級(jí)語言的流行，本質(zhì)就是通過犧牲一部分的性能，從而提升普通開發(fā)者的編程體驗(yàn)。如果未來的前端框架，只面向低代碼平臺(tái)的開發(fā)者，而這些開發(fā)者的編程水平大概率比較強(qiáng)時(shí)，那么API的設(shè)計(jì)就可以更加貼近框架一側(cè)，這會(huì)讓這些框架的潛力發(fā)揮的更加徹底。

04
自上而下的推動(dòng)最有效

下邊講一下前端視角去推廣低代碼，可能會(huì)遇到的問題:

前端開發(fā)模式換用低代碼之后，UI及產(chǎn)品經(jīng)理如果還是按照原先對(duì)你的期待去要求實(shí)現(xiàn)效果。這肯定會(huì)造成一些難解的沖突與麻煩。他們也許會(huì)認(rèn)為這個(gè)開發(fā)最近肯定偷懶了。以往像讓某個(gè)按鈕變個(gè)顏色，換個(gè)位置這種輕而易舉就能答應(yīng)的事情，現(xiàn)在要思索很久或者直接給個(gè)此功能無法支持的回復(fù)，這顯然不符合產(chǎn)品方的利益。
前文提到，如果只是前端開發(fā)模式換用低代碼，而后端的字段約束，返回格式還是像以前那樣的隨意，肯定會(huì)造成低代碼平臺(tái)上需要處理前后端交互兼容的地方越來越多，這就導(dǎo)致可維護(hù)性大大降低。有人說這里可以用node做一個(gè)BFF層的接口格式轉(zhuǎn)換，但這種方式也只是換了個(gè)地方寫兼容代碼，治標(biāo)不治本。

所以，最理想是整個(gè)產(chǎn)研團(tuán)隊(duì)一塊推動(dòng)的方式。這樣產(chǎn)品、前端、后端、測(cè)試整個(gè)流程都對(duì)低代碼平臺(tái)有一個(gè)統(tǒng)一的功能預(yù)期，產(chǎn)品不提非標(biāo)需求，前后端不寫非標(biāo)代碼，測(cè)試不測(cè)非標(biāo)功能，這樣才能更好的發(fā)揮低代碼的價(jià)值。但是，想想好像有哪里不對(duì)勁。至于是哪里不對(duì)勁？下一段就會(huì)講到。

05
會(huì)造成失業(yè)嗎

一定會(huì)造成一部分失業(yè)。是的，筆者對(duì)這個(gè)問題表現(xiàn)的偏悲觀一些，或者說，更理性一些。針對(duì)這個(gè)問題，我也詢問過很多身邊的同行，有一部分說根本不會(huì)造成程序員失業(yè)，他們給出常見理由如下：

1、低代碼平臺(tái)是用來幫助開發(fā)者從日常繁瑣重復(fù)的工作中解放中，去做一些更有價(jià)值的事情。是一件雙贏的事情，怎么會(huì)失業(yè)呢？

2、低代碼也是需要人力去開發(fā)的，本身就會(huì)創(chuàng)造一些崗位出來，這會(huì)抵消掉由于它的流行所替代的那些HC。
3、低代碼太弱了，比如某一個(gè)細(xì)分領(lǐng)域且復(fù)雜的功能就無法實(shí)現(xiàn)。

但這里其實(shí)存在一個(gè)量上的誤解。假如團(tuán)隊(duì)有10個(gè)人，因?yàn)閾Q用低代碼之后，只需要2-3個(gè)人即可搞定日常的開發(fā)，那老板就哪怕花費(fèi)原先6個(gè)人的工資去雇傭剩下的2-3個(gè)高手程序員，也是一筆劃算的“交易”。而且，這已經(jīng)不單單是我的設(shè)想，而是朋友公司里真實(shí)發(fā)生的事情。

他們公司的技術(shù)負(fù)責(zé)人，高價(jià)請(qǐng)了兩個(gè)架構(gòu)師，負(fù)責(zé)低代碼平臺(tái)的開發(fā)、維護(hù)。后續(xù)用5、6k的低薪資去招聘大量的工作內(nèi)容就是拖拖拽拽的低代碼開發(fā)者，甚至是無任何編程經(jīng)驗(yàn)的人員，簡(jiǎn)單培訓(xùn)之后即可上崗。遇到需要寫專業(yè)代碼或者比較復(fù)雜的的場(chǎng)景，就先記錄下來，之后讓架構(gòu)師過來解決。

至于第三種觀點(diǎn)，我認(rèn)為低代碼其實(shí)很像自動(dòng)駕駛的普及。目前司機(jī)這個(gè)崗位的存在必要，還是因?yàn)楝F(xiàn)階段的自動(dòng)駕駛不夠完美。當(dāng)它應(yīng)對(duì)的場(chǎng)景越來越多，甚至超過經(jīng)驗(yàn)豐富的老司機(jī)時(shí)，那司機(jī)這個(gè)崗位就會(huì)消失了。當(dāng)然，另一方面想，這其實(shí)也是一件技術(shù)進(jìn)步帶來的好事，可以降低事故發(fā)生的幾率。

這些當(dāng)然還聽起來至少不像是近期會(huì)發(fā)生的事情。作為一名開發(fā)者，目前能做的就是，專注于一些真正有價(jià)值的事情上，努力提升自己的不可替代性。優(yōu)秀的編程思想，架構(gòu)能力永遠(yuǎn)是稀缺資源。

不看好目前的低代碼創(chuàng)業(yè)

目前的低代碼發(fā)展過程中還未出現(xiàn)一些真正的具有壁壘的技術(shù)。稍有點(diǎn)研發(fā)實(shí)力的公司都能做，而且，因?yàn)閷?duì)自己的業(yè)務(wù)相對(duì)更加了解，做出來會(huì)更適合公司的實(shí)際情況。當(dāng)然，目前提供低代碼服務(wù)的很大一部分公司，很多都是之前做企業(yè)SASS、PASS的換了個(gè)產(chǎn)品名字，他們之前的產(chǎn)品本來就有市場(chǎng)，所以低代碼只是一個(gè)幫助他們營(yíng)銷的噱頭罷了。

06
總結(jié)

低代碼一定是有發(fā)展前景的，目前在一些特定的企業(yè)oa、sass或者標(biāo)準(zhǔn)化的業(yè)務(wù)場(chǎng)景比如審批流等特定場(chǎng)景下已經(jīng)取得了不錯(cuò)的應(yīng)用。

未來已來。你相信與否已變得不再重要，重要的是當(dāng)你的老板某一天從隔壁老板口里知曉，這世上存在一種不需要寫代碼，或者只需少量程序員皆可交付應(yīng)用的開發(fā)方式時(shí)，一定會(huì)至少先讓你們?cè)囈辉?。如果真有那么一天，你剛好是CTO或者決策者，一定記得調(diào)研完幫兄弟們說一句，這玩意還有待市場(chǎng)驗(yàn)證。

文章轉(zhuǎn)載自稀土掘金，對(duì)文章觀點(diǎn)做了細(xì)微調(diào)整，如有侵權(quán)，請(qǐng)聯(lián)系刪除。
原文地址：https://juejin.cn/post/7131801252500865055
原文作者：鄭魚咚

繼續(xù)閱讀：