2020年的9月底，我離開呆了5年之久的老東家，撤離舒適區(qū)，進(jìn)入一個全新的環(huán)境。到今年的這個時候，已經(jīng)差不多是一周年了。
這一年過的非?？欤c之前很不同，每天都在忙碌著，都會遇到新的狀況，想不同的應(yīng)對策略，不像以前早上倒杯水，坐會兒，然后按部就班的工作。
每周的感覺是周一上班，明天就是周五，每日的感覺是早上上班，一眨眼就是晚上18點(diǎn)30了，又快要下班了。
在剛進(jìn)公司的第一個月，沒做什么大動作，基本是在熟悉項(xiàng)目和補(bǔ)充人員，期間也面了7、8個人，最后敲定一位候選人，10月底入職。
而在這第一個月中，我也著手編寫了一份前端基建計(jì)劃，人員到位后，就開始執(zhí)行份計(jì)劃了。
今年基本都是圍繞著基建計(jì)劃和業(yè)務(wù)展開的工作，下圖是我今年的工作思維導(dǎo)圖，列出了些比較重要的節(jié)點(diǎn)。

圍繞基建建設(shè)，在業(yè)務(wù)中尋找技術(shù)突破點(diǎn)，做到對上有交代，對下有啟發(fā)，發(fā)現(xiàn)痛點(diǎn)，解決痛點(diǎn)。
對上有交代就是低成本、高質(zhì)量、高效率、甚至超預(yù)期的完成公司的項(xiàng)目，對下有啟發(fā)就是以戰(zhàn)養(yǎng)兵，在實(shí)際工作中有成長、有收獲。

一、理解業(yè)務(wù)

業(yè)務(wù)是公司的根本，我們作為技術(shù)支持，都是在為業(yè)務(wù)服務(wù)的。因此，任何能幫助業(yè)務(wù)更快推進(jìn)的事情，都可以嘗試。
公司也會時不時的組織分享會議，來說明公司用戶群體的特征，以及季度、年度目標(biāo)等。
其實(shí)倒目前為止，自己對公司業(yè)務(wù)的理解還不是很深入，這也是我下一階段要努力改善的點(diǎn)。

1）與業(yè)務(wù)人員一對一

在剛進(jìn)公司時，對業(yè)務(wù)的理解還是比較被動的，就是需求轉(zhuǎn)到我這邊，就完成該需求，不會對業(yè)務(wù)再做進(jìn)一步的了解。
在之后，認(rèn)知發(fā)生了改變，于是主動與各個業(yè)務(wù)負(fù)責(zé)人溝通，了解他們目前碰到的最痛點(diǎn)，挖掘業(yè)務(wù)中的優(yōu)化點(diǎn)。
我將他們的訴求全部整理后，就按復(fù)雜度和迫切度排了個優(yōu)先級，組織人員，全力修復(fù)他們的痛點(diǎn)，提升他們的幸福指數(shù)。
期間我也會對他們的痛點(diǎn)做分析，理解其背后的訴求。例如后臺有個活動配置的功能，很難用，他們希望重構(gòu)，但是成本非常巨大。
在進(jìn)一步溝通后，理解了原來這個難用的功能無法預(yù)覽，每次配錯就得重做，那其實(shí)只要加個預(yù)覽功能，就能馬上滿足他們的訴求，經(jīng)濟(jì)實(shí)惠。

2）管理后臺梳理

管理后臺現(xiàn)在包含兩三百張，公司內(nèi)部沒有人全盤理解這個后臺，也沒有文檔對這個后臺的各個頁面做說明。
經(jīng)過多方了解，產(chǎn)品曽對此系統(tǒng)做過一張功能和使用人的表，只是還未讓各個小組填寫。我主動拉群，將表傳遞給各個組，邀請他們填寫好。
他們的響應(yīng)非?？?，當(dāng)天就全部完成了，非常配合。有了這張表后，就能直觀地看到誰誰負(fù)責(zé)哪一塊，有不熟悉的地方就能針對性的找人咨詢了。
QA組曽做過一張管理后臺的思維導(dǎo)圖，粒度很細(xì)，可以看到頁面中各個按鈕的說明，對我們也是一個非常好的參考。

3）短鏈服務(wù)

短鏈服務(wù)是我主動想到的一個業(yè)務(wù)工具，在實(shí)際的業(yè)務(wù)開發(fā)中，發(fā)現(xiàn)客戶端將H5網(wǎng)頁的地址打包在客戶端內(nèi)，即若要修改的話，就得發(fā)版，很不靈活。
還有就是iOS對H5頁面的緩存非常厲害，有時候更新完頁面內(nèi)容后，無法馬上看到最新界面，非常影響用戶體驗(yàn)。
于是就想到了之前公司有一套短鏈服務(wù)，可以將原始地址包在短鏈中，維持一層映射關(guān)系，修改原始地址就能破掉iOS的緩存。
對于運(yùn)營也有好處，例如他們要做海報(bào)，在海報(bào)中有張二維碼，那只要將短鏈地址生成二維碼就行，至于原始地址，可以隨時改變。

4）榜單定時任務(wù)配置化

這又是另一個我主動出擊的業(yè)務(wù)工具，公司的大部分活動就是打榜，而打榜的內(nèi)部邏輯有規(guī)律可循。
榜單定時任務(wù)配置化由我們前端小組所有成員共同完成，各自抽象可動態(tài)配置的部分。
我主要負(fù)責(zé)數(shù)據(jù)源的讀取和定時任務(wù)的可視化，這個可視化的界面是給我們合QA人員使用的。
這套系統(tǒng)穩(wěn)定后，可大大減少開發(fā)和測試時間，每次只需做簡單的配置后，就能立馬上線。當(dāng)然，H5頁面每次都會不同。
我們與設(shè)計(jì)師約定了這類榜單活動的標(biāo)準(zhǔn)，未來只是更改頭圖等動態(tài)的部分，而大結(jié)構(gòu)和細(xì)節(jié)方面就不會有太大的調(diào)整。
我相信，未來這類活動絕對可以從5天壓縮到1天，并且也不用在半夜12點(diǎn)關(guān)注活動是否正常開啟，一切都會很穩(wěn)。
總結(jié)下這次的工作就是：面向特定場景做抽象，沉淀出最佳實(shí)踐，再通過產(chǎn)品封裝來加速整個制作過程。

二、填補(bǔ)空白

雖然公司發(fā)展了五六年，但是很多方面還依然是空白，之前的人員可以說僅僅是在完成業(yè)務(wù)，而未對其他方面有過 多的拓展，團(tuán)隊(duì)技術(shù)氛圍也不是很濃。
在今年四月份，公司的技術(shù)負(fù)責(zé)人找到我，希望我能組織技術(shù)部內(nèi)部的技術(shù)分享，我快速的撰寫了一份技術(shù)分享規(guī)范，并且在當(dāng)月由我自己舉辦了第一場分享。
期間遇到的最大阻力就是缺少講師，經(jīng)常斷更，理由就是業(yè)務(wù)來不及做無法準(zhǔn)備分享。
我還做了許多保障項(xiàng)目質(zhì)量的措施，例如推廣單元測試、E2E測試、重要項(xiàng)目開展Code Review、需求評審后制作設(shè)計(jì)方案等，當(dāng)然，做任何推廣都會遇到阻力，內(nèi)因外因都會發(fā)生。
斷斷續(xù)續(xù)還寫了各類思考，都記錄在團(tuán)隊(duì)管理分類中。

1）文檔體系化

文檔匱乏，這是我進(jìn)公司的第一印象，剛進(jìn)公司的那幾個月，我就開始著手搭建文檔體系，一直到現(xiàn)在還在補(bǔ)充中，這是一個長期的工作。
剛進(jìn)來，就有一個小伙要離職了，我讓他在走之前補(bǔ)充了各個項(xiàng)目的文檔，因?yàn)樗莻€老員工，都比較熟悉。
我在此基礎(chǔ)上，又分別新增了規(guī)范、業(yè)務(wù)邏輯、技術(shù)文檔、疑難雜癥等欄目，規(guī)范包括代碼規(guī)范、協(xié)作規(guī)范、開發(fā)流程等規(guī)范。
開啟周會制度，每周五早上小組成員在一起開個短會，信息同步，溝通問題，大家都彼此都能有更進(jìn)一步的了解。
在會議中將探討本周遇到的各類問題，以及解決策略，近期公司動向也會與成員同步，自己也會時不時的強(qiáng)調(diào)文檔的重要性。
在自己的影響下，組內(nèi)成員也在慢慢完善各類文檔，也會有意識的去補(bǔ)充沒有的文檔，并且去將開發(fā)過程中遇到的問題做單獨(dú)記錄，匯總到各個項(xiàng)目的疑難雜癥中。
自己平時喜歡瀏覽各種技術(shù)分享，看到好玩好用的庫，例如Serverless，tailwind.css等，或各類思想，例如代碼腐爛、低代碼等。
或各種基礎(chǔ)概念，例如二進(jìn)制、文件下載、加密等，都會在每周的例會中與組員分享，
周會的內(nèi)容會記錄在WIKI中存檔，陸陸續(xù)續(xù)也記錄了許多內(nèi)容。

2）工具

工具主要是為我們開發(fā)自己所服務(wù)的，這些工具可以幫助我們提升工作效率。
首先是MongoDB查詢工具，在遺留項(xiàng)目中，有一部分的數(shù)據(jù)存儲在MongoDB中，但是沒有很好的可視化界面查看遠(yuǎn)程的MongoDB，于是就自己動手做了一個，省得每次都登錄服務(wù)器查看。
然后是Redis工具，一樣的問題，為了便于查看緩存數(shù)據(jù)而制作的工具，包括查詢和刪除功能。QA在測試活動或功能時，可以方便的觀察緩存的變化，以及測試完后不用叫我們幫忙清理數(shù)據(jù)了。
接著是接口日志查詢工具，能在各種環(huán)境中查看到數(shù)據(jù)庫查詢和內(nèi)部接口調(diào)用日志，有助于我們快速定位接口的問題。
再是腳本執(zhí)行工具，為那些臨時處理數(shù)據(jù)的腳本提供一個統(tǒng)一入口，不用再上傳腳本到服務(wù)器中執(zhí)行，只要將代碼放到執(zhí)行接口中，就能完成腳本邏輯。
還有一個通用配置工具，將一些可變的常量存在數(shù)據(jù)庫中，可隨時讀寫，我們已經(jīng)將活動中可配的參數(shù)（例如開始時間、結(jié)束時間等）都寫在其中，便于QA測試的時候修改。
最近還制作了一款BFF聚合系統(tǒng)，抽象數(shù)據(jù)層，縮小文檔編輯和接口調(diào)試的門檻。
這些都是有界面的工具，還有一類是存在于代碼中的工具，例如通用接口，抽象出的這套增刪改查的接口，能避免在 Router 和 Service 兩層中新增不必要的文件，還能做臨時的業(yè)務(wù)調(diào)試。

3）物料庫

物料庫的研發(fā)也是在我進(jìn)公司后，就馬上啟動了。因?yàn)槲锪蠋斓挠袩o會非常影響我們這邊的日常開發(fā)效率。
我每個雙月都會訂一個OKR， 那就是整理10個組件，大家都很給力，組件在持續(xù)的增加中，并且都做了配套的H5演示頁面。
我們的物料庫包括業(yè)務(wù)組件、JSBridge組件、模板組件等，其中模板組件專用于后臺管理系統(tǒng)。
組內(nèi)的小伙伴會將各類業(yè)務(wù)組件封裝（包括榜單、支付等）并配置說明文檔以及演示網(wǎng)頁，為了與客戶端調(diào)試JSBridge，組員自己還新建了一張頁面專門為客戶端服務(wù)。
在我到公司的第一個月就發(fā)現(xiàn)后臺管理系統(tǒng)的研發(fā)占據(jù)著我們組大量的時間，而每次開發(fā)都會建文件、加權(quán)限、加接口等方面，尤其頁面布局占據(jù)著大頭。
之后整理發(fā)現(xiàn)，幾種常規(guī)的布局大概占總頁面數(shù)的80%以上，只有很小一部分的頁面需要專門定制，那么就能抽象出常規(guī)布局中包含的組件。
模板組件呼之欲出，經(jīng)過一周多時間的調(diào)試，在組內(nèi)開始推廣。在開發(fā)這套組件的時候，預(yù)留了許多回調(diào)，可根據(jù)不同場景做自定義的邏輯。
在模板組件上線后，就將頁面的開發(fā)從3天降低至1天以內(nèi)，有些簡單頁面兩三個小時就能布局完成。

4）監(jiān)控系統(tǒng)

監(jiān)控系統(tǒng)是我在進(jìn)入公司后，就開始研發(fā)了，其實(shí)在很早之前我就想做這么一套系統(tǒng)了，曾研發(fā)過一套采集的JS腳本，但一直沒有機(jī)會做，這次正好有這個契機(jī)，就馬上開干了。
監(jiān)控系統(tǒng)從正式開發(fā)，到上線穩(wěn)定，前前后后大約花了2個月，主要中間在斷斷續(xù)續(xù)的維護(hù)著。
監(jiān)控系統(tǒng)的意義非常重大，因?yàn)樗钛a(bǔ)了前端頁面監(jiān)控的一個空白，對前端有了一個更加立體化的監(jiān)控體系。
在之前，當(dāng)線上頁面出現(xiàn)異常時，若無監(jiān)控，基本都是兩眼一抹黑。但現(xiàn)在，可以了解當(dāng)時頁面中的請求數(shù)據(jù)，接口的響應(yīng)，還能搜集到頁面的錯誤信息，是否白屏等各類數(shù)據(jù)。
我們自己也從這套監(jiān)控系統(tǒng)中發(fā)現(xiàn)了許多可優(yōu)化的點(diǎn)，例如有個活動的504響應(yīng)非常多，經(jīng)過排查后發(fā)現(xiàn)是不合理的多次請求導(dǎo)致的，馬上針對性的優(yōu)化。
504 請求從 1500 個左右降低到 200 個左右，減少了整整 7.5 倍，還有個驚喜的結(jié)果就是日志量一下子減少了 50W 條，節(jié)省了很多帶寬。
在開發(fā)這套系統(tǒng)時，也遇到了不小的阻力，其中有一個問題是內(nèi)存泄漏，在特定時間段（12~14，21~22，23~02）CPU飆升至70%。
原因就是會不斷的生成閉包，無法釋放內(nèi)存，斷斷續(xù)續(xù)也查了一兩周的時間。
還遇到了一個慢查詢的問題，就是日志的檢索，我必須支持關(guān)鍵字模糊查詢，但是日志表的數(shù)據(jù)量很容易達(dá)到千萬級。
對MySQL加了全文索引，也無濟(jì)于事，最終將所有數(shù)據(jù)同步到了ElasticSearch中，才解決了搜索的問題。
該系統(tǒng)目前覆蓋了H5和小程序兩個端， 每日的數(shù)據(jù)量在90W條左右，其中88%是通信記錄，每條記錄在750字節(jié)左右，每日的數(shù)據(jù)量在645M左右。
每天凌晨都會有一個定時任務(wù)，計(jì)算各類指標(biāo)，包括錯誤數(shù)、504請求數(shù)、通信數(shù)等。
監(jiān)控系統(tǒng)還有很多不完善的地方，其中告警這塊非常有待加強(qiáng)，目前只是做了能通過飛書告警指定用戶的功能，但各類規(guī)則都還未添加。

5）性能優(yōu)化

性能優(yōu)化是一個永恒的主題，在做監(jiān)控系統(tǒng)時，順便也將各類性能參數(shù)搜集起來，重要的參數(shù)包括白屏、首屏、加載總時間等。
在后臺會做一些折線圖，橫坐標(biāo)為小時或分，縱坐標(biāo)是參數(shù)時間（以秒為單位），可直觀地觀察到網(wǎng)頁的性能狀況。
并且若在實(shí)踐某個優(yōu)化手段，那么就能以此系統(tǒng)中的數(shù)據(jù)為參照，查看前后的變化了。
在一次的偶然的機(jī)會中，了解到了預(yù)請求的技術(shù)，于是為了提升網(wǎng)頁的打開速度，說服客戶端加上了這個功能。
未來所有的活動，都會將預(yù)請求作為標(biāo)配。性能優(yōu)化是一個持續(xù)的過程，未來我們還會不斷的實(shí)踐各種其他優(yōu)化手段。

6）服務(wù)升級或遷移

服務(wù)升級一方面是為了延緩代碼的腐爛，另一方面也是為了能享受新技術(shù)帶來的新體驗(yàn)。
剛進(jìn)公司就發(fā)現(xiàn)共存著好多個技術(shù)棧，有jQuery、React、Vue等，還遺留了許多祖?zhèn)鞔a。
祖?zhèn)鞔a中有許多坑，剛接手的時候經(jīng)常會疲于填坑，不過后面慢慢就穩(wěn)定了，代碼熟悉后，填坑也能更加的得心應(yīng)手，之前還特地發(fā)篇文章吐槽了一下踩坑的一些場景。
jQuery這塊是最老舊的代碼，本來想制訂一份遷移計(jì)劃，但發(fā)現(xiàn)成本巨大，并且很多項(xiàng)目都不太會維護(hù)了，穩(wěn)定運(yùn)行著。
多方面考慮后，放棄了大規(guī)模的遷移，只是不在做新增，只做存量維護(hù)。
React和Vue是針對兩個完全不同的場景，PC端的管理后臺和移動端的活動，各自都有各自的沉淀，所以也就沒有強(qiáng)制統(tǒng)一了。
后臺管理系統(tǒng)依托的是umi 1.X版本，三年前的版本，很多新功能都無法使用，本來想升級到最新版，但變化太大，于是就折中升級到了umi 2.X版本。
Node服務(wù)目前使用的Node版本是8.X，已經(jīng)遠(yuǎn)遠(yuǎn)低于目前的主流版本，本來是想一口氣升級到10，但發(fā)生了奇怪的時區(qū)問題，又回退到了8。
之后另辟蹊徑，新建了依托egg.js框架的新項(xiàng)目，采用TypeScript語法，Node版本是12，既滿足了Node升級，也能體驗(yàn)當(dāng)今流行的TypeScript所帶來的便利。
在公司呆了兩個月后，發(fā)現(xiàn)定時任務(wù)的代碼還放在一臺非常老舊的服務(wù)器中，當(dāng)時所有的服務(wù)都已經(jīng)遷移到阿里云中了，之前的人都覺得遷移風(fēng)險很大，所以一直拖著。
經(jīng)過權(quán)衡利弊后，還是決定遷移，統(tǒng)一服務(wù)器環(huán)境，運(yùn)維也好維護(hù)。一頓分析后，發(fā)現(xiàn)其實(shí)最重要的是兩個結(jié)算的定時任務(wù)，只要這兩個正常，其他都不是問題。
在與QA緊密的配合后，終于在某一天的早晨遷移到了阿里云服務(wù)器，一切正常，在之后的開發(fā)過程中，還新增了一個預(yù)發(fā)的定時任務(wù)環(huán)境。
隨著管理后臺不斷的膨脹，它已變成了一個巨石應(yīng)用，發(fā)一次代碼，慢的時候都要十幾分鐘，雖然期間曾做過幾次發(fā)布優(yōu)化，但都失敗了。
為了抑制它的快速膨脹，我想到了微前端，之前的umi升級，也是為拆分做準(zhǔn)備的，選擇的微前端框架是qiankun，同為一個小組的開源產(chǎn)品，應(yīng)該更容易搭配。

別忘了第三十七屆|前端 TS 專場，關(guān)鍵詞：原理解析/玩法套路/踩坑經(jīng)驗(yàn)/架構(gòu)實(shí)踐/面試考點(diǎn) ，2-26(本周六) 全天直播，6 位講師(淘寶/百度/TSRPC/美團(tuán)/觀遠(yuǎn)數(shù)據(jù) 等等)，點(diǎn)我上車?? zaozao.run/conf/c37

每屆大會都有全程錄播，會在大會結(jié)束后 24 小時內(nèi) 錄播/PPT 向報(bào)名用戶開放。

所有往期都有全程錄播和 PPT，可以購買年票一次性解鎖全部

??更多活動?