去年的9月底，我離開呆了5年之久的老東家，撤離舒適區，進入一個全新的環境。到今年的這個時候，已經差不多是一周年了。
這一年過的非常快，與之前很不同，每天都在忙碌着，都會遇到新的狀況，想不同的應對策略，不像以前早上倒杯水，坐會兒，然后按部就班的工作。
每周的感覺是周一上班，明天就是周五，每日的感覺是早上上班，一眨眼就是晚上18點30了，又快要下班了。
在剛進公司的第一個月，沒做什么大動作，基本是在熟悉項目和補充人員，期間也面了7、8個人，最后敲定一位候選人，10月底入職。
而在這第一個月中，我也着手編寫了一份前端基建計划，人員到位后，就開始執行份計划了。
今年基本都是圍繞着基建計划和業務展開的工作，下圖是我今年的工作思維導圖，列出了些比較重要的節點。
圍繞基建建設，在業務中尋找技術突破點，做到對上有交代，對下有啟發，發現痛點，解決痛點。
對上有交代就是低成本、高質量、高效率、甚至超預期的完成公司的項目，對下有啟發就是以戰養兵，在實際工作中有成長、有收獲。
一、理解業務
業務是公司的根本，我們作為技術支持，都是在為業務服務的。因此，任何能幫助業務更快推進的事情，都可以嘗試。
公司也會時不時的組織分享會議，來說明公司用戶群體的特征，以及季度、年度目標等。
其實倒目前為止，自己對公司業務的理解還不是很深入，這也是我下一階段要努力改善的點。
1）與業務人員一對一
在剛進公司時，對業務的理解還是比較被動的，就是需求轉到我這邊，就完成該需求，不會對業務再做進一步的了解。
在之后，認知發生了改變，於是主動與各個業務負責人溝通，了解他們目前碰到的最痛點，挖掘業務中的優化點。
我將他們的訴求全部整理后，就按復雜度和迫切度排了個優先級，組織人員，全力修復他們的痛點，提升他們的幸福指數。
期間我也會對他們的痛點做分析，理解其背后的訴求。例如后台有個活動配置的功能，很難用，他們希望重構，但是成本非常巨大。
在進一步溝通后，理解了原來這個難用的功能無法預覽，每次配錯就得重做，那其實只要加個預覽功能，就能馬上滿足他們的訴求，經濟實惠。
2）管理后台梳理
管理后台現在包含兩三百張，公司內部沒有人全盤理解這個后台，也沒有文檔對這個后台的各個頁面做說明。
經過多方了解，產品曽對此系統做過一張功能和使用人的表，只是還未讓各個小組填寫。我主動拉群，將表傳遞給各個組，邀請他們填寫好。
他們的響應非常快，當天就全部完成了，非常配合。有了這張表后，就能直觀地看到誰誰負責哪一塊，有不熟悉的地方就能針對性的找人咨詢了。
QA組曽做過一張管理后台的思維導圖，粒度很細，可以看到頁面中各個按鈕的說明，對我們也是一個非常好的參考。
3）短鏈服務
短鏈服務是我主動想到的一個業務工具，在實際的業務開發中，發現客戶端將H5網頁的地址打包在客戶端內，即若要修改的話，就得發版，很不靈活。
還有就是iOS對H5頁面的緩存非常厲害，有時候更新完頁面內容后，無法馬上看到最新界面，非常影響用戶體驗。
於是就想到了之前公司有一套短鏈服務，可以將原始地址包在短鏈中，維持一層映射關系，修改原始地址就能破掉iOS的緩存。
對於運營也有好處，例如他們要做海報，在海報中有張二維碼，那只要將短鏈地址生成二維碼就行，至於原始地址，可以隨時改變。
4）榜單定時任務配置化
這又是另一個我主動出擊的業務工具，公司的大部分活動就是打榜，而打榜的內部邏輯有規律可循。
榜單定時任務配置化由我們前端小組所有成員共同完成，各自抽象可動態配置的部分。
我主要負責數據源的讀取和定時任務的可視化，這個可視化的界面是給我們合QA人員使用的。
這套系統穩定后，可大大減少開發和測試時間，每次只需做簡單的配置后，就能立馬上線。當然，H5頁面每次都會不同。
我們與設計師約定了這類榜單活動的標准，未來只是更改頭圖等動態的部分，而大結構和細節方面就不會有太大的調整。
我相信，未來這類活動絕對可以從5天壓縮到1天，並且也不用在半夜12點關注活動是否正常開啟，一切都會很穩。
總結下這次的工作就是：面向特定場景做抽象，沉淀出最佳實踐，再通過產品封裝來加速整個制作過程。
二、填補空白
雖然公司發展了五六年，但是很多方面還依然是空白，之前的人員可以說僅僅是在完成業務，而未對其他方面有過多的拓展，團隊技術氛圍也不是很濃。
在今年四月份，公司的技術負責人找到我，希望我能組織技術部內部的技術分享，我快速的撰寫了一份技術分享規范，並且在當月由我自己舉辦了第一場分享。
期間遇到的最大阻力就是缺少講師，經常斷更，理由就是業務來不及做無法准備分享。
我還做了許多保障項目質量的措施，例如推廣單元測試、E2E測試、重要項目開展Code Review、需求評審后制作設計方案等，當然，做任何推廣都會遇到阻力，內因外因都會發生。
斷斷續續還寫了各類思考，都記錄在團隊管理分類中。
1）文檔體系化
文檔匱乏，這是我進公司的第一印象，剛進公司的那幾個月，我就開始着手搭建文檔體系，一直到現在還在補充中，這是一個長期的工作。
剛進來，就有一個小伙要離職了，我讓他在走之前補充了各個項目的文檔，因為他是個老員工，都比較熟悉。
我在此基礎上，又分別新增了規范、業務邏輯、技術文檔、疑難雜症等欄目，規范包括代碼規范、協作規范、開發流程等規范。
開啟周會制度，每周五早上小組成員在一起開個短會，信息同步，溝通問題，大家都彼此都能有更進一步的了解。
在會議中將探討本周遇到的各類問題，以及解決策略，近期公司動向也會與成員同步，自己也會時不時的強調文檔的重要性。
在自己的影響下，組內成員也在慢慢完善各類文檔，也會有意識的去補充沒有的文檔，並且去將開發過程中遇到的問題做單獨記錄，匯總到各個項目的疑難雜症中。
自己平時喜歡瀏覽各種技術分享，看到好玩好用的庫，例如Serverless，tailwind.css等，或各類思想，例如代碼腐爛、低代碼等。
或各種基礎概念，例如二進制、文件下載、加密等，都會在每周的例會中與組員分享，
周會的內容會記錄在WIKI中存檔，陸陸續續也記錄了許多內容。
2）工具
工具主要是為我們開發自己所服務的，這些工具可以幫助我們提升工作效率。
首先是MongoDB查詢工具，在遺留項目中，有一部分的數據存儲在MongoDB中，但是沒有很好的可視化界面查看遠程的MongoDB，於是就自己動手做了一個，省得每次都登錄服務器查看。
然后是Redis工具，一樣的問題，為了便於查看緩存數據而制作的工具，包括查詢和刪除功能。QA在測試活動或功能時，可以方便的觀察緩存的變化，以及測試完后不用叫我們幫忙清理數據了。
接着是接口日志查詢工具，能在各種環境中查看到數據庫查詢和內部接口調用日志，有助於我們快速定位接口的問題。
再是腳本執行工具，為那些臨時處理數據的腳本提供一個統一入口，不用再上傳腳本到服務器中執行，只要將代碼放到執行接口中，就能完成腳本邏輯。
還有一個通用配置工具，將一些可變的常量存在數據庫中，可隨時讀寫，我們已經將活動中可配的參數（例如開始時間、結束時間等）都寫在其中，便於QA測試的時候修改。
最近還制作了一款BFF聚合系統，抽象數據層，縮小文檔編輯和接口調試的門檻。
這些都是有界面的工具，還有一類是存在於代碼中的工具，例如通用接口，抽象出的這套增刪改查的接口，能避免在 Router 和 Service 兩層中新增不必要的文件，還能做臨時的業務調試。
3）物料庫
物料庫的研發也是在我進公司后，就馬上啟動了。因為物料庫的有無會非常影響我們這邊的日常開發效率。
我每個雙月都會訂一個OKR， 那就是整理10個組件，大家都很給力，組件在持續的增加中，並且都做了配套的H5演示頁面。
我們的物料庫包括業務組件、JSBridge組件、模板組件等，其中模板組件專用於后台管理系統。
組內的小伙伴會將各類業務組件封裝（包括榜單、支付等）並配置說明文檔以及演示網頁，為了與客戶端調試JSBridge，組員自己還新建了一張頁面專門為客戶端服務。
在我到公司的第一個月就發現后台管理系統的研發占據着我們組大量的時間，而每次開發都會建文件、加權限、加接口等方面，尤其頁面布局占據着大頭。
之后整理發現，幾種常規的布局大概占總頁面數的80%以上，只有很小一部分的頁面需要專門定制，那么就能抽象出常規布局中包含的組件。
模板組件呼之欲出，經過一周多時間的調試，在組內開始推廣。在開發這套組件的時候，預留了許多回調，可根據不同場景做自定義的邏輯。
在模板組件上線后，就將頁面的開發從3天降低至1天以內，有些簡單頁面兩三個小時就能布局完成。
4）監控系統
監控系統是我在進入公司后，就開始研發了，其實在很早之前我就想做這么一套系統了，曾研發過一套采集的JS腳本，但一直沒有機會做，這次正好有這個契機，就馬上開干了。
監控系統從正式開發，到上線穩定，前前后后大約花了2個月，主要中間在斷斷續續的維護着。
監控系統的意義非常重大，因為它填補了前端頁面監控的一個空白，對前端有了一個更加立體化的監控體系。
在之前，當線上頁面出現異常時，若無監控，基本都是兩眼一抹黑。但現在，可以了解當時頁面中的請求數據，接口的響應，還能搜集到頁面的錯誤信息，是否白屏等各類數據。
我們自己也從這套監控系統中發現了許多可優化的點，例如有個活動的504響應非常多，經過排查后發現是不合理的多次請求導致的，馬上針對性的優化。
504 請求從 1500 個左右降低到 200 個左右，減少了整整 7.5 倍，還有個驚喜的結果就是日志量一下子減少了 50W 條，節省了很多帶寬。
在開發這套系統時，也遇到了不小的阻力，其中有一個問題是內存泄漏，在特定時間段（12~14，21~22，23~02）CPU飆升至70%。
原因就是會不斷的生成閉包，無法釋放內存，斷斷續續也查了一兩周的時間。
還遇到了一個慢查詢的問題，就是日志的檢索，我必須支持關鍵字模糊查詢，但是日志表的數據量很容易達到千萬級。
對MySQL加了全文索引，也無濟於事，最終將所有數據同步到了ElasticSearch中，才解決了搜索的問題。
該系統目前覆蓋了H5和小程序兩個端， 每日的數據量在90W條左右，其中88%是通信記錄，每條記錄在750字節左右，每日的數據量在645M左右。
每天凌晨都會有一個定時任務，計算各類指標，包括錯誤數、504請求數、通信數等。
監控系統還有很多不完善的地方，其中告警這塊非常有待加強，目前只是做了能通過飛書告警指定用戶的功能，但各類規則都還未添加。
5）性能優化
性能優化是一個永恆的主題，在做監控系統時，順便也將各類性能參數搜集起來，重要的參數包括白屏、首屏、加載總時間等。
在后台會做一些折線圖，橫坐標為小時或分，縱坐標是參數時間（以秒為單位），可直觀地觀察到網頁的性能狀況。
並且若在實踐某個優化手段，那么就能以此系統中的數據為參照，查看前后的變化了。
在一次的偶然的機會中，了解到了預請求的技術，於是為了提升網頁的打開速度，說服客戶端加上了這個功能。
未來所有的活動，都會將預請求作為標配。性能優化是一個持續的過程，未來我們還會不斷的實踐各種其他優化手段。
6）服務升級或遷移
服務升級一方面是為了延緩代碼的腐爛，另一方面也是為了能享受新技術帶來的新體驗。
剛進公司就發現共存着好多個技術棧，有jQuery、React、Vue等，還遺留了許多祖傳代碼。
祖傳代碼中有許多坑，剛接手的時候經常會疲於填坑，不過后面慢慢就穩定了，代碼熟悉后，填坑也能更加的得心應手，之前還特地發篇文章吐槽了一下踩坑的一些場景。
jQuery這塊是最老舊的代碼，本來想制訂一份遷移計划，但發現成本巨大，並且很多項目都不太會維護了，穩定運行着。
多方面考慮后，放棄了大規模的遷移，只是不在做新增，只做存量維護。
React和Vue是針對兩個完全不同的場景，PC端的管理后台和移動端的活動，各自都有各自的沉淀，所以也就沒有強制統一了。
后台管理系統依托的是umi 1.X版本，三年前的版本，很多新功能都無法使用，本來想升級到最新版，但變化太大，於是就折中升級到了umi 2.X版本。
Node服務目前使用的Node版本是8.X，已經遠遠低於目前的主流版本，本來是想一口氣升級到10，但發生了奇怪的時區問題，又回退到了8。
之后另辟蹊徑，新建了依托egg.js框架的新項目，采用TypeScript語法，Node版本是12，既滿足了Node升級，也能體驗當今流行的TypeScript所帶來的便利。
在公司呆了兩個月后，發現定時任務的代碼還放在一台非常老舊的服務器中，當時所有的服務都已經遷移到阿里雲中了，之前的人都覺得遷移風險很大，所以一直拖着。
經過權衡利弊后，還是決定遷移，統一服務器環境，運維也好維護。一頓分析后，發現其實最重要的是兩個結算的定時任務，只要這兩個正常，其他都不是問題。
在與QA緊密的配合后，終於在某一天的早晨遷移到了阿里雲服務器，一切正常，在之后的開發過程中，還新增了一個預發的定時任務環境。
隨着管理后台不斷的膨脹，它已變成了一個巨石應用，發一次代碼，慢的時候都要十幾分鍾，雖然期間曾做過幾次發布優化，但都失敗了。
為了抑制它的快速膨脹，我想到了微前端，之前的umi升級，也是為拆分做准備的，選擇的微前端框架是qiankun，同為一個小組的開源產品，應該更容易搭配。