字節(jié)三年，談?wù)勔痪€團(tuán)隊(duì)如何搞工程化
共 9845字，需瀏覽 20分鐘
·
2024-05-06 09:15
點(diǎn)擊上方 前端Q，關(guān)注公眾號(hào)
回復(fù)加群，加入前端Q技術(shù)交流群
作者所在的團(tuán)隊(duì)叫 “Cuckoo FE” （Cuckoo：布谷鳥，多數(shù)種類為灰褐或褐色，喙強(qiáng)壯而稍向下彎，一只幼鳥一天能吃39只蚱蜢），寓意樸實(shí)能干，下文中工程化實(shí)踐各類體系也是以Cuckoo開頭。
目前前端團(tuán)隊(duì)成員接近20人，歸屬字節(jié)商業(yè)化業(yè)務(wù)中臺(tái)，承擔(dān)海外商業(yè)化交易流程建設(shè)，為字節(jié)內(nèi)部出海產(chǎn)品提供商業(yè)變現(xiàn)能力，整體技術(shù)方向以PC中臺(tái)為主（90%+），另外包含部分移動(dòng)端項(xiàng)目。
原文：https://juejin.cn/post/7311596602249134106
作者：Range
從一個(gè)故事說起
小馬加入公司不久，最近剛接手一個(gè)新需求。憑借以往經(jīng)驗(yàn)，這是一個(gè)small case，很快的給了排期，準(zhǔn)備開干。沒多久，他就向他的mentor提了第一個(gè)問題：“怎么創(chuàng)建項(xiàng)目？”，mentor很快就丟過來一個(gè)倉(cāng)庫(kù)，并回復(fù)道“你拿著這個(gè)項(xiàng)目去copy下改改”。小馬愣了一下，不敢多問，立馬開始操作，一頓CV猛如虎，項(xiàng)目終于跑起來，心想“快了，只要項(xiàng)目跑起來就快了”。接著小馬在開發(fā)過程中遇到一個(gè)比較通用的功能，又問mentor有沒有類似組件，沒多久mentor又丟過來一個(gè)倉(cāng)庫(kù)，并在鏈接下評(píng)論：“你在xx文件下找找xx組件，應(yīng)該修改修改就能用”，小馬又把項(xiàng)目跑起來了，細(xì)研究了源碼，果然能用，很開心又解決了一個(gè)問題。這樣類似問題一個(gè)接一個(gè)，mentor也都能很快的給出答復(fù)。時(shí)間很快，在mentor的加持下到了聯(lián)調(diào)那一天，小馬心里長(zhǎng)舒一口氣“終于可以用真實(shí)數(shù)據(jù)跑一把了”，結(jié)果在瀏覽器刷新的那一刻，頁面白了，雖然屏幕有點(diǎn)臟，但顯的格外的白，這終究還是沒有超出預(yù)期啊。這一調(diào)又是一堆問題，要么是成功碼不對(duì)，要么是該有的字段沒有，有了結(jié)構(gòu)也不對(duì)，小馬跑過去問后端怎么回事，后端回道“你應(yīng)該沒看最新文檔”，小馬打開文檔對(duì)比了下：“嗯，是已經(jīng)有很多不一樣的了，但和現(xiàn)在的接口返回好像也不完全一樣吧”，最終小馬還是選擇了相信接口返回的json。又是一頓折騰準(zhǔn)備提測(cè)，小馬又問mentor“怎么部署啊？”，mentor毫無意外的又丟過來一個(gè)文檔，好一點(diǎn)的是這次只有一個(gè)文檔，應(yīng)該比較簡(jiǎn)單，點(diǎn)開的一瞬間又繃不住了，里面是一堆文檔的鏈接，有什么編譯的、部署的、環(huán)境配置的、權(quán)限配置的、流水線校驗(yàn)等等。此時(shí)小馬已經(jīng)瀕臨崩潰，但也只能硬著頭皮挨個(gè)看，挨個(gè)對(duì)接，但總有地方報(bào)錯(cuò)。去查文檔，但文檔點(diǎn)開總有其它文檔，點(diǎn)不完，有時(shí)還會(huì)有好幾篇相同的文檔，但說法卻不盡相同（小馬心里苦啊，他要的只是一個(gè)button，輕輕一點(diǎn)就能部署罷了）。作為新同學(xué)，小馬只能一遍又一遍的問自己的mentor。
終于經(jīng)過小馬幾天持續(xù)奮戰(zhàn)下，mentor也很給力，項(xiàng)目完成了提測(cè)，雖然晚了幾天，mentor拍了拍肩膀鼓勵(lì)道“沒事，你還不熟悉，后面就會(huì)變好”，小馬心里也很慶幸“能遇到這么好的mentor，不然一行代碼也寫不了”，但回頭望著工作桌面滿屏的文件夾，又總感覺哪里不對(duì)。
小編同學(xué)加入字節(jié)3年半，所在的團(tuán)隊(duì)從開始的幾個(gè)人到現(xiàn)在的接近20個(gè)人，團(tuán)隊(duì)成長(zhǎng)過程中也遇了一些和小馬類似的問題：研發(fā)資產(chǎn)沉淀不足、規(guī)范不統(tǒng)一、文檔缺失、不正確，dev ops 流程不順暢等等，我們答案是“做好團(tuán)隊(duì)工程化體系建設(shè)”。但作為業(yè)務(wù)團(tuán)隊(duì)，一切以業(yè)務(wù)為優(yōu)先，沒有足夠的人力投入的工程化等基建上怎么辦？所以我們建設(shè)的重心有兩點(diǎn)：
一，業(yè)務(wù)團(tuán)隊(duì)要做好與公司基建、社區(qū)沉淀的連接，盡量利用已有的解決方案快速融合到自己的團(tuán)隊(duì)，不做底層的重復(fù)建設(shè)。
二、做好團(tuán)隊(duì)上層沉淀，圍繞團(tuán)隊(duì)內(nèi)部個(gè)性化訴求打造高效解決方案。
接下來就一起看看在工程化上我們到底做了哪些事情吧，同時(shí)也打個(gè)小廣告，我們準(zhǔn)備把這些技術(shù)建設(shè)寫成系列文章（系列主題見下圖）分享給大家，歡迎和大家一起交流。
什么是工程化
前端工程化定義
前端工程化作為軟件細(xì)分領(lǐng)域中的一種技術(shù)理念目前并沒有明確的定義，它是在15年webpack誕生后開始被越來越多人提及，從開始的打包工具到現(xiàn)在的各類開箱即用解決方案，能力邊界在不斷擴(kuò)展。目前社區(qū)內(nèi)基本的共識(shí)是以降低成本、提高效率和質(zhì)量為目標(biāo)，以流程、工具、規(guī)范為手段的實(shí)踐體系。它是基于實(shí)踐的一系列解決方案，而非單獨(dú)某種問題的答案，用一句話概括即前端領(lǐng)域內(nèi)一站式解決方案。
工程化的發(fā)展歷程
工程化源于實(shí)踐，每個(gè)時(shí)期要解決的問題不同，按照解決問題層級(jí)大概可以分為以下幾個(gè)階段：
1.0 頁面動(dòng)態(tài)化， 這個(gè)階段標(biāo)志前端領(lǐng)域興起，從最開始的簡(jiǎn)單腳本到以JQuery為代表的各類工具庫(kù)百花齊放。
2.0 模塊化階段， 這個(gè)階段主要解決大型應(yīng)用的開發(fā)難度以及開發(fā)效率問題 。 產(chǎn)品代表有國(guó)內(nèi)一線互聯(lián)網(wǎng)的一系列大型應(yīng)用如淘寶網(wǎng)，技術(shù)則有webpack為代表的構(gòu)建工具以及React 、Vue、Angular為代表應(yīng)用各類應(yīng)用框架。
3.0跨平臺(tái)大前端階段，這個(gè)階段重新定義了前端，前端領(lǐng)域也有了這樣一個(gè)偉大的宏愿：一切能用前端實(shí)現(xiàn)的終將都會(huì)用前端實(shí)現(xiàn)。比較有代表性的產(chǎn)品有小程序、臉書，在線excel等一系列跨端產(chǎn)品，技術(shù)代表有ReactNative、Flutter、Electron等各類跨平臺(tái)開發(fā)框架。
4.0alpha智能化階段，隨著AIGC的興起，輔助開發(fā)，輔助應(yīng)用生成已經(jīng)初顯趨勢(shì)，同時(shí)AI進(jìn)化的速度是指數(shù)級(jí)別的，AI+的智能前端時(shí)代未來充滿想象力。
現(xiàn)在我們已經(jīng)知道了工程化是什么，接下來來看下具體的實(shí)踐吧。
工程化實(shí)踐
作為一個(gè)橫向支撐團(tuán)隊(duì)我們面對(duì)的主要挑戰(zhàn)有：
快速響應(yīng)：業(yè)務(wù)發(fā)展較快，不同方向變現(xiàn)訴求強(qiáng)烈，需要具備能同時(shí)支持多條業(yè)務(wù)線能力。
業(yè)務(wù)復(fù)雜高： 面對(duì)業(yè)務(wù)形態(tài)多樣，國(guó)家、用戶群體各不相同，個(gè)性化差異大，整體業(yè)務(wù)復(fù)雜度較高。
質(zhì)量線就是生命線： 主要和錢打交道，任何一個(gè)不起眼的問題都有可能給用戶及公司帶來難以估量的損失。
面對(duì)這些問題已經(jīng)不是單純不斷加人就能解決的（ps：人也不好加，不是你想加就能加...），為了解決這些問題，我們團(tuán)隊(duì)從規(guī)范統(tǒng)一、研發(fā)資產(chǎn)沉淀、系統(tǒng)解決方案、創(chuàng)新應(yīng)用逐步建設(shè)自己的工程化體系（詳見下圖），通過這些技術(shù)體系建設(shè)來不斷提高研發(fā)團(tuán)隊(duì)的上限，這其中最最重要（小馬表示真的很重要）的一件事就是“團(tuán)隊(duì)規(guī)范建設(shè)”。
規(guī)范建設(shè)
為什么要做規(guī)范統(tǒng)一
團(tuán)隊(duì)剛成立時(shí)，人不多，業(yè)務(wù)發(fā)展速度非常快，團(tuán)隊(duì)重心是“敏捷”，各個(gè)小團(tuán)隊(duì)各自為戰(zhàn)，怎么快怎么來，缺少最基本的規(guī)范。但當(dāng)業(yè)務(wù)跑了一段時(shí)間后，團(tuán)隊(duì)已經(jīng)“敏捷”不起來了，跟不上業(yè)務(wù)的速度了，我們開始著手做一些基建幫助大家提效，但此時(shí)已經(jīng)不好下手，各個(gè)小組用的框架、組件都不相同，只能先從規(guī)范統(tǒng)一開始做起。
有哪些規(guī)范
按照規(guī)范作用劃分主要有：流程規(guī)范、編碼規(guī)范、業(yè)務(wù)規(guī)范
如何推動(dòng)規(guī)范統(tǒng)一
制定規(guī)范比較容易，但要落地卻很難，因?yàn)樾枰獙?duì)大家有種種約束，如果處理不當(dāng)容易造成團(tuán)隊(duì)反噬，所以我們采用策略是輕拿快放。推進(jìn)要溫柔，多和團(tuán)隊(duì)同學(xué)提前溝通，多聽取建議，落地要干脆， 對(duì)于已經(jīng)達(dá)成一致結(jié)論，要結(jié)合工具和流程快速落地，階段reivew落地情況。具體推進(jìn)過程一般遵循以下三條原則：
規(guī)范制定流程標(biāo)準(zhǔn)化， 一般先由規(guī)范發(fā)起人發(fā)起提案（以社區(qū)或公司已有規(guī)范為模版）-> 團(tuán)隊(duì)評(píng)審->公示（一到兩周）->修改->發(fā)布正式版本
落地過程漸進(jìn)化， 規(guī)范落地以增量項(xiàng)目?jī)?yōu)先，規(guī)范從嚴(yán)，存量活躍項(xiàng)目（最近雙月有無迭代）漸進(jìn)接入，非活躍項(xiàng)目最后接入或不接入。
執(zhí)行過程工具化、運(yùn)營(yíng)化，對(duì)編碼類規(guī)范進(jìn)行卡點(diǎn)工具建設(shè)，結(jié)合發(fā)布流水線中進(jìn)行規(guī)范檢測(cè)攔截，搭建數(shù)據(jù)大盤，掌控落地情況。非編碼類規(guī)范要保持前高后低的運(yùn)營(yíng)策略，落地前期（1-2個(gè)月）保持高頻review，中后期力度遞減，定期組織bad case 學(xué)習(xí)。
通過這一系列的規(guī)范建設(shè)，已經(jīng)能解決我們研發(fā)過程中很多問題了，我們也在其中發(fā)現(xiàn)一個(gè)道理：真正的“敏捷”不是快，追求快的結(jié)果也不一定是快，一切還是需要遵循事物發(fā)展的客觀規(guī)律“做大做強(qiáng)必須先夯實(shí)基礎(chǔ)”。
團(tuán)隊(duì)規(guī)范建設(shè)中非常重要的一環(huán)就是“統(tǒng)一技術(shù)選型”，又該如何做呢？
基建建設(shè)
統(tǒng)一技術(shù)選型
目前底層框架技術(shù)選型難度越來越低，各類框架已經(jīng)越來越趨同，對(duì)應(yīng)社區(qū)發(fā)展也都很成熟，現(xiàn)在選擇更多是基于團(tuán)隊(duì)自身沉淀考慮。我們團(tuán)隊(duì)早期沉淀以React為主，所以我們團(tuán)隊(duì)一開始的技術(shù)選型就是圍繞React，主要經(jīng)歷三個(gè)階段：自研框架->擁抱社區(qū)->回歸公司基建：
-
react全家桶+自定義工程模版+webpack+自定義插件。優(yōu)點(diǎn)：定制化程度高;缺點(diǎn)：人力投入大，不能穩(wěn)定迭代，穩(wěn)定性和擴(kuò)展性不足； -
React 全家桶+ Umi+自定義插件。優(yōu)點(diǎn)：成熟的解決方案，可靠性很高。缺點(diǎn)：不同插件各個(gè)團(tuán)隊(duì)重復(fù)建設(shè)如：容災(zāi)插件。 -
React 全家桶+Eden（字節(jié)內(nèi)部自研）+monorepo。優(yōu)點(diǎn)：成熟的解決方案，相對(duì)定制化，針對(duì)公布內(nèi)部共性問題，提供了統(tǒng)一解決方案。
我們團(tuán)隊(duì)在第三階段技改時(shí)，當(dāng)時(shí)團(tuán)隊(duì)內(nèi)部的倉(cāng)庫(kù)已經(jīng)超過100個(gè)，活躍迭代的倉(cāng)庫(kù)在40+，其中一個(gè)全棧項(xiàng)目有15個(gè)倉(cāng)庫(kù)，當(dāng)時(shí)維護(hù)成本很高，過于分散的倉(cāng)庫(kù)也不利于團(tuán)隊(duì)技術(shù)沉淀及改造，所以我們按照業(yè)務(wù)分類最終合并成了6個(gè)monorepo倉(cāng)庫(kù)。
研發(fā)物料沉淀
研發(fā)物料（組件、模塊、設(shè)計(jì)資源等）沉淀是一個(gè)團(tuán)隊(duì)最有效的效率提升手段，我們先后完成了組件、物料庫(kù)、系統(tǒng)最佳實(shí)踐三個(gè)維度的沉淀。
組件：作為業(yè)務(wù)團(tuán)隊(duì)，我們團(tuán)隊(duì)組件建設(shè)重心是業(yè)務(wù)組件及領(lǐng)域組件（微應(yīng)用組件，包含業(yè)務(wù)數(shù)據(jù)、權(quán)限等，如購(gòu)物車），基礎(chǔ)組件庫(kù)我們則是基于社區(qū)開源組件antd結(jié)合團(tuán)隊(duì)設(shè)計(jì)規(guī)范進(jìn)行的二次開發(fā)。目前我們沉淀了30+的業(yè)務(wù)組件，5+領(lǐng)域組件。
物料庫(kù)： 同部門共建物料庫(kù)，包含組件、工具函數(shù)、區(qū)塊等代碼資源。
最佳實(shí)踐: 系統(tǒng)級(jí)別的解決方案，針對(duì)常用業(yè)務(wù)場(chǎng)景進(jìn)行案例沉淀 ，設(shè)計(jì)、PM可以快速?gòu)闹姓业较鄳?yīng)資源參考，研發(fā)可以配合cli將代碼下載到工程中。
中臺(tái)渲染引擎
在完成設(shè)計(jì)規(guī)范統(tǒng)一和物料沉淀后效率已經(jīng)有很大提升，但頁面配置化才是中臺(tái)效率的終極核彈。我們得益設(shè)計(jì)范統(tǒng)一和組件沉淀，自建了交易業(yè)務(wù)場(chǎng)景下的渲染引擎，實(shí)現(xiàn)了90%+ 頁面配置化（頁面展示、低復(fù)雜度的邏輯由配置生成，復(fù)雜的業(yè)務(wù)邏輯額要外編碼），開發(fā)效率提升60%左右，通常一周的開發(fā)量可以縮短到2pd左右。
interface PageDSL {
label: string
field: string
widget: Component
widgetProps: {
watch: ['others']
callback: (info) => {},
...
},
formItemProps: { //表單描述
span: number
initialValue?: any
tooltip?: React.ReactNode;
fieldKey?: React.Key | React.Key[]
...
}
textOptions: { // 表格、詳情描述
type: string
span: number
render?: ColumnType<R>['render'] | 'ellipsis' | 'date' | 'time' | 'amount',
...
}
}
當(dāng)然頁面配置化并不是銀彈，并不能解決所有問題，我們目前主要還是依靠它來做頁面的渲染，以及低復(fù)雜度業(yè)務(wù)邏輯配置，對(duì)于復(fù)雜業(yè)務(wù)我們還是需要配合編碼實(shí)現(xiàn)，而且我們也認(rèn)為應(yīng)該用編碼實(shí)現(xiàn)，主要原因有兩點(diǎn)：
與當(dāng)前團(tuán)隊(duì)能力不匹配：業(yè)務(wù)系統(tǒng)過于復(fù)雜，開發(fā)完全配置化的系統(tǒng)成本和能力要求很高，目前當(dāng)前團(tuán)隊(duì)是無法完成。
完全配置化不代表的效率的提升：復(fù)雜業(yè)務(wù)導(dǎo)致配置過于復(fù)雜，成本高、難度大，如果疊加業(yè)務(wù)迭代快，成本會(huì)陡增，并不會(huì)比編碼快。畢竟業(yè)務(wù)邏輯的配置，其理解成本、維護(hù)成本要遠(yuǎn)遠(yuǎn)高于直觀的代碼。
腳手架建設(shè)
模版-快速創(chuàng)建能力：結(jié)合自己的業(yè)務(wù)特點(diǎn)沉淀了多套工程模版，核心能力是通過命令快速創(chuàng)建項(xiàng)目、頁面、模塊。
ProCode：得益于渲染引擎的建設(shè)，我們通常的開發(fā)流程為開發(fā)物料->DSL配置->特殊業(yè)務(wù)邏輯開發(fā)，其中DSL的配置約占開發(fā)時(shí)間30%，這段代碼結(jié)構(gòu)高度類似，我們最后通過ProCode來生成這份配置，減少開發(fā)時(shí)間。生成代碼的過程為：讀取swagger接口定義->生成基礎(chǔ)配置->設(shè)計(jì)稿圖片識(shí)別生成頁面配置->模版編譯+ATS生成頁面代碼->本地應(yīng)用更新。
在實(shí)踐過程中圖片識(shí)別過程比較困難，先通過oci識(shí)別頁面有哪些字段，再通過大模型MobileNetV2 來標(biāo)注組件類型，但效果不明顯，生成配置錯(cuò)誤多，粒度也不夠細(xì)，所以我們引入配置預(yù)覽流程，最后由人工去兜底這份配置。由于目前收益沒有到達(dá)預(yù)期，我們也在嘗試由前端編寫Figma組件，為研發(fā)提供組件及頁面區(qū)塊信息，再通過組件中的文本信息去匹配接口字段（和后端約定每個(gè)字段上注釋帶有字段名稱信息），生成更準(zhǔn)確的DSL。
質(zhì)量平臺(tái)建設(shè)
質(zhì)量建設(shè)是工程化中繞不開的話題，我們?cè)诼L(zhǎng)建設(shè)過程中走了不少?gòu)澛罚?jiǎn)單概括下可以分為三個(gè)階段：
分散治理，頭疼醫(yī)頭，腳疼醫(yī)腳：初期我們的主要精力對(duì)一些突出問題進(jìn)行專項(xiàng)治理，這些治理工作更多是一次性，一段時(shí)間后又會(huì)裂化，且質(zhì)量建設(shè)是多維度，很難通過一兩個(gè)維度的建設(shè)來評(píng)價(jià)總體的建設(shè)效果，缺少全局視野的情報(bào)。
集中治理，搭建前端視角的質(zhì)量大盤： 通過性能建設(shè)、監(jiān)控報(bào)警等一系列專項(xiàng)建設(shè)，我們搭建了前端視角的質(zhì)量看板，但由于功能和視野比較單一，主要是前端同學(xué)在用，對(duì)業(yè)務(wù)反哺不夠。
聯(lián)合治理，搭建全場(chǎng)景業(yè)務(wù)治理平臺(tái)：聯(lián)合前端、后端、QA、PM、數(shù)據(jù)團(tuán)隊(duì)按照業(yè)務(wù)線維度搭建統(tǒng)一的治理平臺(tái)，將各方質(zhì)量建設(shè)做到入口統(tǒng)一、數(shù)據(jù)口徑統(tǒng)一、目標(biāo)統(tǒng)一。
工作臺(tái)
我們?cè)诮鉀Q完研發(fā)資產(chǎn)的重點(diǎn)問題后，開始著手解決一些研發(fā)流程上痛點(diǎn)：
資產(chǎn)管理難：團(tuán)隊(duì)100多個(gè)項(xiàng)目，每個(gè)項(xiàng)目有n條關(guān)聯(lián)信息，靠文檔、人去管理非常難（小馬表示看文檔很累！！！）
開發(fā)流程不夠順暢：開發(fā)一個(gè)項(xiàng)目到上線，需要打開N個(gè)平臺(tái)，過程割裂，學(xué)習(xí)成本高。
項(xiàng)目治理難：團(tuán)隊(duì)內(nèi)的合規(guī)、優(yōu)化等技術(shù)改造專項(xiàng)很多，通過人力one by one去改，周期長(zhǎng)，成本高、過程難把控。
我們通過自建研發(fā)工作臺(tái)較好的解決了這些問題，它的主要功能有：
研發(fā)資產(chǎn)數(shù)據(jù)化、可視化管理： 開發(fā)項(xiàng)目和工作臺(tái)共用一套數(shù)據(jù)源（項(xiàng)目所有依賴為一條數(shù)據(jù)），保證項(xiàng)目實(shí)時(shí)最新，擺脫文檔管理陷阱，并通過數(shù)據(jù)可視化的提高管理效率。
研發(fā)流程全聯(lián)接： 通過工作臺(tái)將研發(fā)人員、研發(fā)工具（vscode）、公司基建、團(tuán)隊(duì)沉淀等整合，具備研發(fā)全流程能力，包含倉(cāng)庫(kù)及項(xiàng)目創(chuàng)建、項(xiàng)目開發(fā)、部署、監(jiān)控、多語言管理、業(yè)務(wù)埋點(diǎn)管理、自動(dòng)化測(cè)試、流水線任務(wù)等能力，實(shí)現(xiàn)了all in one platform。
智能治理： 團(tuán)隊(duì)內(nèi)的技術(shù)專項(xiàng)通過創(chuàng)建治理任務(wù)結(jié)合治理腳本實(shí)現(xiàn)自動(dòng)治理，治理過程流程化，進(jìn)度可追蹤 。 舉個(gè)容災(zāi)的例子：由任務(wù)發(fā)起人開發(fā)完容災(zāi)功能調(diào)用治理插件能力（文件操作、git操作、通知、自動(dòng)化測(cè)試等能力），將代碼用AST的方式寫入到所有業(yè)務(wù)git倉(cāng)庫(kù)中，并生成commit，同時(shí)工作臺(tái)會(huì)生成治理任務(wù)并推送給業(yè)務(wù)同學(xué)，業(yè)務(wù)同學(xué)在工作臺(tái)收到任務(wù)通知后驗(yàn)收功能，通過后合并代碼，任務(wù)進(jìn)度更新，此時(shí)就完成了單個(gè)項(xiàng)目治理，整體進(jìn)度也會(huì)在專項(xiàng)群里自動(dòng)定期同步，催辦進(jìn)度較慢的業(yè)務(wù)方。
創(chuàng)新應(yīng)用
上述建設(shè)更多是研發(fā)視角的，那么用戶視角又有哪些呢？技術(shù)直接下沉到用戶側(cè)主要有兩塊：
首頁搭建： 在渲染引擎的沉淀上建設(shè)搭建引擎，讓用戶可以通過拖拽，生成自己想要的首頁，實(shí)現(xiàn)了千人千面的效果。生成應(yīng)用過程可以總結(jié)為以下公式：
Dashboard = Layout(widget_1, widget_2, widget_n, ...)
Widget = Datasource + View + [Filter + ServiceAPI]
模版服務(wù)： 讓業(yè)務(wù)方可以自己配置郵件、合同等各類模版，擺脫了對(duì)研發(fā)的直接依賴，提升業(yè)務(wù)方工作效率。
團(tuán)隊(duì)技術(shù)品牌建設(shè)
為了讓團(tuán)隊(duì)中的技術(shù)建設(shè)能夠持續(xù)傳承下去，圍繞中臺(tái)、node、移動(dòng)端技術(shù)方向建設(shè)了內(nèi)部的技術(shù)品牌站點(diǎn)。
總結(jié)
本文主要講了這幾年一個(gè)一線團(tuán)隊(duì)所遇到過的問題以及從規(guī)范建設(shè)到實(shí)踐落地的具體過程，全部是一些內(nèi)部的沉淀，后續(xù)也會(huì)按照模塊展開講講。也希望能和大家一起交流下各自團(tuán)隊(duì)遇到問題以及解決方案，互相學(xué)習(xí)。
最后再補(bǔ)充下這幾年做基建的一些個(gè)人感受，概括來說就是兩個(gè)字“難”和“值”。“難”的點(diǎn)一方面是業(yè)務(wù)壓力大，很難有整塊時(shí)間，另一方面公司基建比較成熟，輪子容易造重復(fù)了。“值”的點(diǎn)在于沉淀了一些有價(jià)值的東西，提升了團(tuán)隊(duì)效率、質(zhì)量，團(tuán)隊(duì)也在這些基礎(chǔ)上逐步完成了整個(gè)基建的統(tǒng)一。同時(shí)我們?cè)诮ㄔO(shè)過程中也總結(jié)了一些經(jīng)驗(yàn)，這里和大家分享下：
保持定力，持續(xù)投入： 建設(shè)過程中短期可能會(huì)遇到各類困難（研發(fā)同學(xué)壓力大、業(yè)務(wù)很急），但要保持信念，長(zhǎng)期看這種投入值得，且時(shí)間越久收益也越大。如果遇到是特別特別難的時(shí)候，慢一點(diǎn)也沒關(guān)系，也不要停下來。
敢于嘗試，拿得起放得下：短期一些不明確的方向不要怕錯(cuò)，少量投入，快速驗(yàn)證，方向不正確時(shí)能果斷止損。
以結(jié)果為導(dǎo)向， 不自嗨 ： 建設(shè)過程中關(guān)注實(shí)際業(yè)務(wù)收益，多聽取各方建議，避免陷入“我認(rèn)為很有用”的思維怪圈。
往期推薦
最后
歡迎加我微信，拉你進(jìn)技術(shù)群，長(zhǎng)期交流學(xué)習(xí)...
歡迎關(guān)注「前端Q」,認(rèn)真學(xué)前端，做個(gè)專業(yè)的技術(shù)人...