2022 年年初做了一份年度計劃，給自己列了 13 條今年完成的事情，除了 1 條完全沒有啓動之外，其餘 12 條或完成，或還在進行中。
給自己還定了 5 個核心目標，除了個別需要與其他組協調的任務進度緩慢之外，大部分完成的還是蠻順利的。
下面的思維圖列舉出了今年做的一些比較重要的事情。
與 2021 年從 0-1 時的年終總結略有不同，今年就是在幹 4 件事：知識沉澱、提效保質、體驗優化和研發標準。
一、知識沉澱
知識沉澱就是將有效信息記錄在案，這個在去年就已經提出了，今年是持續精進。
今年不僅自己在維護文檔，而且還讓組內的成員也一起參與，讓他們也能自覺地補充更多的文檔。
最近還學到了個新名詞：活文檔，就是將記錄寫在事物本身中，例如代碼中的註釋、版本提交時的 message 等。
我們組今年也在進一步規範這類活文檔，減少信息障礙。
5月中旬，公司將之前存放在 wiki 中的文檔整體遷移至飛書文檔中，我對整體的目錄也做了一次細緻的歸類，便於查看。
改成飛書後，有個很大的好處，就是可以直接用手機瀏覽文檔了，文檔格式也比之前的 confluence 美觀。
1）工作文檔
工作文檔包括項目文檔、週會記錄等。
項目文檔，是在去年的基礎上，持續補充各類信息，例如項目中遇到的難點，新項目的文檔說明等。
還有對之前寫的比較模糊的資料，做了一次詳細的補充，使文檔更有用。
週會之前只是簡單的羅列工作記錄，今年製作了幾張較爲完整的表格，分門別類的記錄各種工作內容，並且會附上狀態和風險等內容。
2）計劃規範
今年補充了幾個比較大的計劃，例如北極星指標、項目遷移、性能優化、年度計劃等。
北極星指標會在後文中詳細說明，項目遷移就是 Node 服務遷移至 Go，jQuery 遷移至 Vue 等。
性能優化記錄了今年的一些優化手段，例如操作日誌表優化、導出優化、緩存圖像資源等。
今年一個比較重要的規範是通用組件的默認功能和交互，公司的大部分活動都是基於這些組件研發的。
在規範之後，就能大大 QA 在測試時的返工，很多時候一些細節就會糾纏很久。
例如點擊封禁賬號後，有時候表現會與之前 QA 所想的不同，那麼此時她就要與產品和開發覈對。
3）技術分享
技術分享在去年也提出過，並且還制訂了相應的規範，但是由於是針對技術部所有人的，所以組織一次的週期會比較久。
並且參與積極度也不是很高，所以今年 2 月份的時候就調整成全公司的人都可參與，但是參與度仍舊低迷。
再加上三月到六月，整體居家辦公，更不能舉報全公司的分享會了。所以 3 月份再做一次調整，改成團隊內的分享。
每個人都會輪到，一週一個，技術範圍不限制，這次大家都能參與進來，已經進行了 34 場，每場結束後，都會將內容留檔。
大家對此類技術分享並不排斥，都會積極準備，大部分是源碼分析和案例分享。
4）Code Review
5 月份的時候發生了幾場事故，問題雖然低級，但造成的危害卻不小，如何有效的進行規避，在當時我進行了思考。
我想到的一點就是 Code Review，大家坐下來，一起檢查下代碼的寫法，一起判斷業務邏輯是否合理，很容易就能發現那幾個事故中的問題。
今年不定期的舉辦了 15 場 Code Review，發現了很多問題，例如邏輯錯誤、理解誤差、寫法優化等。
還有很重要的一個舉措就是推廣代碼註釋，成員們普遍對註釋比較吝嗇，你自己顯而易見的寫法，別人可能難以理解。
況且好記性不如爛筆頭，註釋也能幫助自己理解比較複雜的代碼。
二、提效保質
在提升效率的同時，保障項目質量，魚和熊掌不可兼得，是我今年重點在推進的事情。
在補充人手後，我能有更多的時間抓工具化和流程化的事情。
1）工具化
要想提效，就需要有趁手的工具，今年在去年的基礎上，又增加和優化了多種工具。
BFF 平臺在去年就研發完成了，不過在組內並沒有馬上推廣開來，直到今年年初，才陸陸續續開始使用。
目前新的業務接口基本都會走此平臺，線上已有 70 多個接口在穩定運行着。
榜單活動配置化是將常用的活動做成可視化配置的形式，目的是減少開發和測試人力，將 2 天的研發時間壓縮至 2 小時。
這個配置協調了 UI 組、產品組、測試組、前端組、數據組一起，制訂出了相關規範，已成功運營了 5 場活動。
爲了提升管理後臺的開發效率，先後研發了後臺編輯器第一版和第二版，第一版組員接受度並不理想，第二版已經上線了兩個菜單。
組內成員配合運維組，研發了IP白名單管理，幫助在家辦公的同事，可以訪問公司內網，降低了進內網的門檻。
爲了規範代碼編輯，引入了 ESLint，對冗餘代碼和會存在隱患的代碼進行標註，幫助我們寫出更健壯的代碼。
開發了一款 VSCode 智能索引插件，因爲框架寫法的原因，使得路由層的代碼不能自動跳轉到服務層，因此寫了插件擴展功能。
2）流程優化
管理後臺靜態頁面的項目發佈一直被詬病，因爲發佈速度太慢了，今年和運維聯手，從 12 分鐘降低到 5 分 30 秒。
解決了我們組的心腹大患，終於可以愉快的發佈項目了，再也不用幹等了。
組內的另一個成員讓測試環境可以自動被髮布，只要將代碼合併到測試分支，就能進行發佈流程，非常方便。
在發佈流水線中，增加核心服務的單元測試，避免線上再出現服務不能訪問的重大問題。
3）前端監控
前端監控系統在去年完成了 0 到 1 的第一步，今年每個月其實都在做維護和優化，目標是讓此係統更好用，而不是一個花瓶，具體優化可參考此處。
今年幫助我們解決了不少線上問題，有的是主動發現，有的是用戶上報後，藉助該系統將問題定位。
不定期的維護包括查詢條件增加時間快捷鍵，過濾第三方庫的通信，活動頁面的通信中增加userId，優化LCP的採樣時機，白屏的計算，監控靜態資源的請求錯誤等。
前端的監控日誌爲了能與服務端日誌相關聯，特地在通信時增加全鏈路日誌唯一標識，不再讓兩端割裂。
Node 服務中有很多因 console.log() 打印出的無效日誌，今年也一併清理，清理後的日誌更加整潔清晰，查詢日誌時少了很多幹擾，日誌量也驟降幾百萬。
爲了能及時的收到線上錯誤，讓運維幫忙配置了接口狀態碼異常（500以上）的飛書告警，規則是同一個接口 1 分鐘內連續 5 次狀態異常就會發消息告警。
8 月再次聯合運維，將 一套 Node 在線監控系統部署到服務器上，實時查看服務器的性能參數了，例如內存、QPS、CPU 等。
4）招聘
招聘我覺得是個老大難的問題，從去年 11 月就開始了，陸陸續續也面了十幾個人，沒有找到合適的。
期間也將招聘信息投稿到大流量公衆號、科技週刊，還在 V 站發佈了招聘帖子。
最終轉化率最高的是 V 站的帖子，在那邊收到了幾份簡歷，最後錄用了一名，3 月份正式入職，目前也已經過了試用期。
今年要招聘兩個人，另一個人選也招了好久，遠程辦公期間發了 3 次 offer，結果有兩人來了沒幾天就走了。
另一人做了兩個多月，自己覺得沒有融入主動離職了。我們這邊不僅僅要做頁面工作，還會涉及些服務端的工作，把工作門檻提高了。
本來就是小公司，職責範圍還廣，就更加難招了。最後一個同事舉薦了他的一個同事，聊的不錯就發 offer 了，熟人好辦事。
8 月底入職，到現在也 3 個多月了，適應能力很強，幹活也利索，靠譜的很。
人員配齊後，無論是工作效率，還是工作質量，都比之前高很多，並且還能承接更多的業務需求。
三、體驗優化
體驗優化也是我今年的一個重點，不僅在易用性上下功夫，還量化了一系列的指標。
更容易讓大家看到努力優化後的成果，提供更穩定更流暢的服務給用戶，包括對外的會員和對內的員工。
大到一個模塊，小到一個按鈕，都是我們優化的對象。
1）項目改造
管理後臺是公司內大部分員工每天辦公的系統，爲了便於在手機上使用，特地對其做了響應式改造。
對項目進行 TypeScript 改造，是爲了更好的保障代碼質量，目前僅在管理後臺中小範圍的進行推廣。
爲了提升活動頁面的加載速度，對其靜態資源進行了 CDN 加速，但是在監控系統中發現，有些舊的資源還在被訪問，可能是手機緩存或 CDN 沒有刷新到。
對活動頁面的腳本也做了針對性的瘦身，分離頁面中不需要的第三方庫。並且對頁面的卡頓、白屏等問題，也都陸續進行了有效優化。
2）北極星指標
北極星指標，也叫第一關鍵指標，是指在產品的當前階段與業務/戰略相關的核心指標，一旦確立就像北極星一樣指引團隊向同一個方向前進。
因爲我們組維護着大量的 Node 服務，所以指標中就會包含多個服務端數據。其中慢響應（請求時間大於2秒）作爲我們組的北極星指標。
在量化日常工作指標後，我們組做了大量的優化工作，將對外業務的慢響應占比控制在萬分之二以內。
在過濾掉不影響用戶體驗和正常優化後的慢響應，數量從 1.307W 降至 1100 個左右。
還有一個指標是 SLA（服務水平協議）佔比（例如 99.999%），這是對網站可用性的一個保證，百分比中的 9 越多代表服務可用時間越長，越可靠，停機時間越短。
我們組也持續優化了很多報 500 的接口，基本都是因爲 null 或 undefined 引起的，例如 null.map()、undefined.toString() 等。
500 的接口在修復和過濾不影響用戶體驗的接口之後，從 2159 降至個位數，目前每天的指標數據都比較穩定。
除此之外，每個雙月還會給協作方提供一份問卷調查，給我們的表現打分，滿分 5 分，並且給予我們一定的改進建議。
3）性能監控
去年的性能監控只有幾張折線圖，使用率也比較低，今年附加了很多新功能，並且與前端監控可以更好的聯動，具體優化可參考此處。
新增的資源瀑布圖可以在出現頁面問題時，準確的瞭解到靜態資源的加載情況。
LCP、FID 和 FCP 是三個今年新增的性能指標，從更多的角度瞭解頁面性能情況。
分別統計白屏和首屏 1 秒內的數量、1-2 秒內、2-3 秒內、3-4 秒內、4+秒的數量，再用堆疊柱狀圖呈現。
在將統計的參數全部計算出來後，爲了能更直觀的發現性能瓶頸，設計了一張階段時序圖。
描繪出 TTFB、responseDocumentTime、initDomTreeTime、parseDomTime 和 loadEventTime 所佔用的時間。
四、研發標準
在去年也推進過技術的升級、統一技術棧和前後端分離，今年完成方面比去年好很多。
主要就是各個組的人員都補充後，有了更多的資源去支持這類基礎工作，不像以前都鋪在業務上。
1）技術升級
去年將 UmiJS 升級到 2.0，今年 3 月成功升級到了 3.0，不過官方今年已經推出了 4.0 的穩定版本。
服務器的 Node 環境，五年來一直是 8.7 版本，去年曾經短暫的升級到 12，但是發現了時區問題，馬上就還原了。
後面人員都鋪在業務上，也沒時間做升級，一直拖到今年 8 月，纔有機會推進升級，一舉升到 16.15。
終於可以使用一些新的 Node 功能和第三方庫了，雖然這次升級也遇到了時區問題，但是順利解決了。
2）技術棧統一
Node 的那些邊角料服務今年也沒有時間遷移至 Go，ROI（投資回報率）太低，沒人重視，一直擱置着。
6 月制訂了前端技術棧統一計劃，由我們自己組操控，之前因爲歷史原因和趕進度，將一些活動頁面通過 jQuery 實現。
現在就要將那些頁面改成 Vue，試着先遷移了 3 張常用的活動頁面，當前已經遷移完成。
3）前後端分離
前後端分離其實從我進公司就一直掛在嘴巴，但因爲客觀原因，一直無法推進。
今年 10 月初終於迎來了正式改造，先在管理後臺試點，我們提供權限和操作日誌的接口，這樣就能適配之前的驗籤和日誌邏輯。
10 月底順利上線，目前已經在服務器中穩定運行。
活動頁面的分離，也在穩步進行中，接下來就是我們出頁面，服務端出接口，首次先在常用的榜單中試點。