精品在线手机视频,国产传媒在线,在线看片免费人成视久网

2022，低代碼徹底火了，甚至火到沒有點相關經驗，都不好意思出去面試的程度，堪稱lowcode“元年”。在整個互聯網大裁員的背景下，無論你是否相信它是降本提效的利器，彷佛都不重要了。因為行業趨勢總是這般浩浩蕩蕩，是不以個人意志為轉移的。從下圖某技術峰會的分享主題中就可見一斑。

剛好筆者最近正在開發一個B端低代碼的平臺。所以，想把這段時間的感悟整理一下與大家分享一些。不過，開頭先聲明一點，本文只聊觀點與感悟，不聊具體技術細節。

01
低代碼的產生背景

互聯網產品趨于標準化

據我觀察，有相當一部分的程序員一提起低代碼就搖頭say no，表示曾經被這些低代碼平臺“傷害過”，因為產品需求一旦涉及平臺暫不支持的功能，輕則導致加班返工，重則績效堪憂，甚至丟了工作。

這是一個新事物發展初期必經的一個階段: 與現有環境水土不服。假如站在更高的角度，設想一下: 當有一天，你的老板宣布，產品經理以后提的需求一律不得超出低代碼平臺支持的能力范圍時，該作何感想。不要輕易說不可能，因為資本的本質就是追逐利潤，假如由于這些非標需求額外付出的開發成本，創造不了預期的收益，那對那些試錯成本寬容度較低的團隊而言，這些需求完全沒有存在的必要（回頭想一想，你的產品經理提的那些奇奇怪怪且上線沒幾天就又改回去的需求，你真的認為有價值嘛）。

了解點軟件外包行業的都知道，很多外包訂單都是先copy一個個的模版項目，在之上稍加改動即可交付。因為和他們對接的大部分客戶需求都很標準化。比如，客戶需要開發一個H5商城，商品、訂單、物流再加一個商品運營后臺就完全可以滿足需求了，甚至不在意UI的樣式與競品一模一樣。不過這里也不排除有定制化開發的報價相比完全套模版會高出一大截的因素，但這也至少說明這些非標需求是錦上添花的功能，根本不是剛需。

其實大廠也有這個趨勢。畢竟各廠的業務范圍越來越出現交叉的態勢，產品層面也都是互相copy，真正具有創新性的產品越來越少。C端的產品，尤其在一些大廠充分競爭或者優勢的業務領域，因為要追求UI設計、交互、產品體驗的差異性，所以相對不容易標準化。比如每年雙11的促銷各家要緊跟潮流，玩法每年都不盡相同，這種就很難標準化。但大部分的B端產品，對定制化要求不高，隨著產品形式的固化，用戶已然形成了一套約定俗成的交互習慣。

應用開發的技術棧趨于成熟

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

02
前端低代碼實現

筆者對低代碼的理解是: 可以通過配置化的低成本交互方式（主流是拖拽）加上少量的一些膠水代碼，去滿足一類應用的需求。這里筆者以發展更加成熟的B端低代碼講述，C端也是很類似，但是因為樣式、動畫等定制要求要比B端的復雜許多，所以目前前端低代碼相對成熟的應用是在B端。低代碼實現原理其實非常簡單，就是先預置豐富的原子組件，通過拖拽選擇所需組件在畫板上進行位置的編排。之后，進行一些組件屬性的設置。

最終生產出一份jsonSchema或者供開發者二次開發的“源代碼”，驅動用戶端的內容渲染。原理雖然簡單明確，但它也有一些實現難點。比如以下幾種：

一、宏觀設計

首先設計一個能夠面向不同業務場景的低代碼項目，是個不小的挑戰。比如一個公司級別的低代碼項目，目標是賦能各條業務線。這個就會有一個問題：每個業務對低代碼平臺的能力要求是不同的，除了大量可復用的功能，肯定也會有不少的定制化需求。甚至各條業務線的產品形態很不一致，有面向C端的，有面向B端的。

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

1、在公司級甚至業界推動低代碼協議統一。這樣就讓跨業務甚至業界的物料復用變得可能，阿里前端委員會為此付出了不少努力，大家有空可以了解下。

2、將低代碼架構分層。先有一個低代碼基礎架構，再用它去“生成”一個個面向具體業務場景的低代碼平臺。那么如何設計好這個“生成低代碼平臺的低代碼平臺”就成為了重中之中。這有點類似于低代碼“中臺”與“前臺”的關系。

二、實現細節

1、事件編排

下圖就是目前最常見的一種設計，可以配置點擊一個button時，要觸發哪種類型的事件，事件觸發要調用哪些函數，一般都會內置一些比較常見的函數，比如打開一個Modal框等。如果內置不滿足需求，就需要插入一些定制化的代碼。

2、狀態聯動

這個相對好解決一些。阿里的formily、x-render、jsonschema-form等這些成熟方案的都能夠解決，他們之間的差異更多的是在聯動性能上，不過這也是在超長表單場景下差距才會比較明顯。

以下是阿里lowcode-engine的交互設計。

這個平臺內置的相對簡單。我接觸過的內置相對豐富的是iofod這個全場景低代碼平臺，這里為他們的開發者打個廣告。筆者還與他們的開發者加了好友，吃驚的是這么大的工作量竟然是一個人完成的，體驗下來比很多公司團隊級的產品都用心。

3、異步數據綁定

傳統的前端開發大量時間其實是花在與后端接口的對接上，這些工作在目前前端低代碼的開發模式中，一點都不會少。

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

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

03
低代碼對行業的影響

框架、類庫的作者也許會喜聞樂見

因為之前要面向不同層次的前端開發者，框架、庫的作者往往會在API設計時盡量追求友好易懂，但這種追求會在其他方面比如性能方面作出妥協。這就像尤雨溪說的那樣，框架開發有時更像是“帶著鐐銬跳舞”。很多時侯，用起來“爽”與高性能是一件不可兼得的事情，編程語言的發展就是一例，java、python、js等這些高級語言的流行，本質就是通過犧牲一部分的性能，從而提升普通開發者的編程體驗。如果未來的前端框架，只面向低代碼平臺的開發者，而這些開發者的編程水平大概率比較強時，那么API的設計就可以更加貼近框架一側，這會讓這些框架的潛力發揮的更加徹底。

04
自上而下的推動最有效

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

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

所以，最理想是整個產研團隊一塊推動的方式。這樣產品、前端、后端、測試整個流程都對低代碼平臺有一個統一的功能預期，產品不提非標需求，前后端不寫非標代碼，測試不測非標功能，這樣才能更好的發揮低代碼的價值。但是，想想好像有哪里不對勁。至于是哪里不對勁？下一段就會講到。

05
會造成失業嗎

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

1、低代碼平臺是用來幫助開發者從日常繁瑣重復的工作中解放中，去做一些更有價值的事情。是一件雙贏的事情，怎么會失業呢？

2、低代碼也是需要人力去開發的，本身就會創造一些崗位出來，這會抵消掉由于它的流行所替代的那些HC。
3、低代碼太弱了，比如某一個細分領域且復雜的功能就無法實現。

但這里其實存在一個量上的誤解。假如團隊有10個人，因為換用低代碼之后，只需要2-3個人即可搞定日常的開發，那老板就哪怕花費原先6個人的工資去雇傭剩下的2-3個高手程序員，也是一筆劃算的“交易”。而且，這已經不單單是我的設想，而是朋友公司里真實發生的事情。

他們公司的技術負責人，高價請了兩個架構師，負責低代碼平臺的開發、維護。后續用5、6k的低薪資去招聘大量的工作內容就是拖拖拽拽的低代碼開發者，甚至是無任何編程經驗的人員，簡單培訓之后即可上崗。遇到需要寫專業代碼或者比較復雜的的場景，就先記錄下來，之后讓架構師過來解決。

至于第三種觀點，我認為低代碼其實很像自動駕駛的普及。目前司機這個崗位的存在必要，還是因為現階段的自動駕駛不夠完美。當它應對的場景越來越多，甚至超過經驗豐富的老司機時，那司機這個崗位就會消失了。當然，另一方面想，這其實也是一件技術進步帶來的好事，可以降低事故發生的幾率。

這些當然還聽起來至少不像是近期會發生的事情。作為一名開發者，目前能做的就是，專注于一些真正有價值的事情上，努力提升自己的不可替代性。優秀的編程思想，架構能力永遠是稀缺資源。

不看好目前的低代碼創業

目前的低代碼發展過程中還未出現一些真正的具有壁壘的技術。稍有點研發實力的公司都能做，而且，因為對自己的業務相對更加了解，做出來會更適合公司的實際情況。當然，目前提供低代碼服務的很大一部分公司，很多都是之前做企業SASS、PASS的換了個產品名字，他們之前的產品本來就有市場，所以低代碼只是一個幫助他們營銷的噱頭罷了。

06
總結

低代碼一定是有發展前景的，目前在一些特定的企業oa、sass或者標準化的業務場景比如審批流等特定場景下已經取得了不錯的應用。

未來已來。你相信與否已變得不再重要，重要的是當你的老板某一天從隔壁老板口里知曉，這世上存在一種不需要寫代碼，或者只需少量程序員皆可交付應用的開發方式時，一定會至少先讓你們試一試。如果真有那么一天，你剛好是CTO或者決策者，一定記得調研完幫兄弟們說一句，這玩意還有待市場驗證。

文章轉載自稀土掘金，對文章觀點做了細微調整，如有侵權，請聯系刪除。
原文地址：https://juejin.cn/post/7131801252500865055
原文作者：鄭魚咚

繼續閱讀：