一、日常問題
1）遺留項目
經常在工作時被人小窗，這里的計算有問題，那里的表格沒內容了等等，一開始肯定是懵逼狀態，然后是根據症狀一步步的摸索代碼邏輯。
對於正在維護的項目，很容易定位問題，但對於那些已經無人維護的項目，定位起來就比較困難了。
必須先確定數據源來自哪個組，可能是服務端，也可能是大數據端，還可能是以前的 Node 端（公司之前的后端采用的是Node.js，后面在慢慢遷移成 Go 語言）。
然后根據數據庫表在幾個項目中搜索，沒有的話再提給隔壁組，這樣一來一回異常費時費力。
后面自己思考了一下，其實自己可以主動出擊，既然都需要借助數據庫來反推，那何不將自己組維護的表羅列出來，並且標注影響的業務。
讓大數據組也配合羅列出他們在維護的表，這樣就能很快的縮小范圍，准確定位出由誰來修復該問題。
除了補充數據庫表之外，還可以主動將那幾個沒人管的 Node 服務拉到本地，為了節約時間，可以只閱讀那幾個正在跑的定時任務。
只要知道了定時任務的功能，那么也可以快速定位問題源，只不過修改的話成本會比較高，一般都只是重啟服務而已。
2）梳理痛點
此處的痛點是指業務部門的痛點，這些問題不解決很影響他們日常工作的用戶體驗。
與各個業務組的負責人一對一的當面談，歸納出幾個他們當前迫切想要改善的點。
交談下來有些比較好改，花點時間就能修復。但有些就比較吃力，要改的代價會比較大。
首先是文檔缺乏，當前的使用方式可能之前就是這么設計的，若要修改，就得補全相關文檔，既能提升開發質量，也能讓測試人員更有針對性地工作。
其次是這些功能的使用頻率並不高，但要完善就得投入較多的人力資源，而當前的人力資源非常緊張。
后面認真思考下來，在理解了他們的核心訴求后，發現這類功能也並不一定要通過重構的方式來完善，其實開放個小按鈕可能就能滿足他們的要求。
例如有個活動模板功能的優化，運營人員希望他們能在增加或修改模塊內容的時候就能實時看到頁面效果，那加個預覽按鈕就能解決他們的訴求，也不必花大力氣來完善文檔。
3）定時任務的遷移
線上的定時任務還在原先的一台服務器上，而現在我們這邊所有的服務都遷移到了阿里雲的容器服務中。
在原先的服務器上無法通過 SVC 的方式調用內部接口，只能通過域名轉發來調用，很不方便。並且發布系統也是單獨的一套。
為了統一環境和發布系統，同時降低服務器成本，需要將定時任務遷移出來。
但是定時任務在運行時只能有一套在線上，所以要非常謹慎的遷移，尤其是一些重要的定時任務，保證不能出錯。
第一步是羅列定時任務的功能和影響的緩存與數據庫，以及觸發的時間點，這些也是給測試參考的。
第二步是將廢棄的定時任務單獨標注，這些任務就可略過不必測試。
第三步是補全重要的定時任務的業務邏輯，以及數據庫SQL查詢語句，方便測試。
在做好這些准備后，就開始與測試人員對接，期間碰到最多的是缺乏數據的問題。
要么查到相關表，從線上數據庫中拉取一些，或者按照對邏輯的理解自己構造，亦或者忽略一些不重要的定時任務直接放到線上觀察結果。
4）密碼定期更新
后台管理系統對密碼做了80天有效期的設置，一周會有個一人因為沒有更新密碼而使得自己無法進入到后台，需要我們手動介入為其更新。
平時工作日還能及時響應，萬一是休息日，那就要影響工作。
如果一次兩次也就算了，經常性的話就得想個辦法，讓他們主動去更新。后面發現是提示不夠醒目，而且提示會在幾秒后自動消失。
為此，更新了后台邏輯，在密碼失效還有5天的時候，開始彈警告，並且延遲 6 分鍾后再消失，然后再自動出現修改密碼的彈出。
5）爭議區域
這邊的前端和后端的界線比較模糊，因為前端也會通過 Node.js 來操作數據庫和緩存，例如微信服務、管理后台的接口等都是前端自己完成的。
賦予前端這些權限有利也有弊，有利的地方就是更加自由，可以不依賴后端，要做什么自己動手，例如做些前端的基礎支撐服務，可以有效避免溝通成本，自己設計自己編寫，一條龍。
有弊的地方就是工作量上去了，並且和后端扯皮的頻次也高了，因為大家都會站在各自的角度來維護各自的利益。
之前就有個需求，后端覺得我們直接調用他們的 redis 緩存自己計算就能得出結果，但我覺得我們這邊不應該過多的介入他們的業務。
就這樣爭論不休，最后各自退一步，他們給到我們需要的數據狀態，然后我們自己來計算。
為了避免這種不必要的爭論，每次需求評審完后，就要與后端划分好各自負責的功能。
6）redis
在上線監控系統后，redis占的內存穩步飆升，使用 info 命令查看內存情況，發現 used_memory_human 已經達到了 20.65G，一個月內擴容了兩次。
運維找到我，要我排查一下這個異常，於是我先在連接redis服務器中，帶上 --bigkeys 參數。
redis-cli -h ***.rds.aliyuncs.com -p 6379 --bigkeys
在控制台會掃描出成員比較多和占內存比較大的 key，挑選了幾個與監控系統的任務隊列有關的 key，例如 q:jobs:failed 占了 450462588 字節，大約 430M。
memory usage q:jobs:failed
(integer) 450462588
主要是 q:job:* 中的任務信息比較占內存，其中有很多狀態是 failed 和 complete 的任務，對於我來說這些已經不需要了，開始編寫代碼去除。
由於 q:job:* 大概有500多W個任務，所以不能直接用 keys 命令，得改成 scan 掃描，5000個一掃。
每次 scan 得到的返回值是個數組，數組的第一個值是下一個位置，當為字符串 0 時，說明掃描完成，第二個值是個由 key 組成的數組。例如：
[ "1732", [ "q:job:123", "q:job:876", "q:job:768:log", "q:job:34569", "q:job:23454" ] ]
在將這些數據刪除后，一下子就瘦身了，減到了 3.95G，效果顯著。但是 mem_fragmentation_ratio（內存碎片率）指標卻達到了 4.25，大於 1.5 就屬於不合理范疇了。
把 activedefrag 配置項設置為 yes（命令如下），redis 就會在最合適（例如CPU較為空閑時）的時間自動清理內存碎片。
config set activedefrag yes
7）一個坑
后台管理系統有一個推送公眾號通知的功能，但是經常不穩定，后面做了次更新，並上傳到線上，觀察下來還是有問題。
並且在項目中還看不到設的日志，非常奇怪，請求好像憑空消失了。
后面經過排查發現是任務隊列的問題，任務隊列是在api項目中，而api項目又分離出了一個支付服務。
在支付服務中也包含任務隊列的接收邏輯，當推送任務被支付服務接收后，由於代碼還是老的，所以就會仍然運行錯誤邏輯。
這是一個非常老的服務，已經有幾年沒動過了，出現這個問題讓人猝不及防。
二、工作優化
1）團隊規范
在查看之前的代碼時，有些命名很耐人詢問，並且缺少注釋，這就導致在定位問題時困難重重，前人給后人設置了重重阻礙。
像之前遇到個問題，就是數據庫表中有個字段，它的值是1、2、3等數字，由於沒有注釋，根本無法知其含義。
於是反推代碼，希望代碼中有合適的注釋，但很遺憾，也沒有，詢問服務端，得到的回答也很讓人失望，他們也沒有注釋。
這樣來來回回的查甚是繁瑣，於是根據網上的資料，整理出了一套適合自己團隊的《前端代碼規范》。
着重規范了注釋的書寫（包括代碼和數據庫），以及命名的方式（包括 JavaScript 的變量和 CSS 的類），圖像的尺寸等。
平時自己也會關注組員的效率問題，發現經常在與其他組協作時發生一些不必要的時間開銷，降低了開發效率。
例如拿到的設計稿和產品的原型圖有差異，組員在未經確認的情況下就直接開發，在給產品驗收時就被退了回來，重新修改。
很多其實都是些小事情，只不過日積月累之后，消耗的時間是非常可觀的。
為了避免這種場景的發生，編寫了《團隊協作流程規范》，規范了與設計、產品、測試、服務端等各個組的協作流程。
這些規范隨着時間的推移會一直做更新，做到與時俱進。
2）時間預估
我們公司在預估時間方面還是比較充足的，不過有時候還是會出現誤差的情況，這樣就不得不加班來彌補了。
雖然這種情況並不是很多，但還是覺得可以優化一下預估時間的計算方式。
后面思考了一下，影響開發進度的因素，除了不斷的加需求之外，就是救火時間。
所謂救火其實是指計划外的工作，也許是一個難纏的 BUG，也許是已上線項目的功能修改等等。
這些工作就像泥潭一樣，有時候就會讓自己深陷其中，不能自拔。
因此，在周會的時候，就要求組員統計一下每周的救火時長，以小時作單位。
統計幾周后，計算平均值，以后估時間時可將該時間也加上，從而能更科學的為自己預估開發時間。
當然，能這么做的前提條件是項目工期並不緊，需求也並不是很急切的要上。
3）瀏覽日志
Node的項目都會將日志上傳到阿里雲上，妥善利用好日志功能，可以起到意想不到的作用。
例如之前公司小程序的運營說打開評論會莫名其妙的彈出一個錯誤提示，但是頁面上面又沒有發現任何異常，說是偶現的，丟給我們之后。
我們也沒有立刻查找，而是先完成緊急的需求。接下來的一天在查看日志中記錄的 500 的通信時，發現有個請求出現的頻率特別多。
於是在項目中查找，沒有發現這個接口的代碼，反查調用該接口的項目，發現正是公司的小程序。
恍然大悟，原來報錯是因為請求了這個不存在的接口導致的。所以的話，經常瀏覽后台日志，會有很多新發現。
之前還發現有個錯誤發生的頻率特別多，一查原來是因為變量的值是 undefined，還用其調用某個方法導致的隱蔽的BUG，立刻將其修復，提升代碼健壯性。
針對H5的監控系統也在后面陸續上線，對前端有了一個更加立體化的監控體系。
4）項目無死角
線上的頁面出問題時，發現問題的人首先找的人都會是我，因為我是前端 leader，所以我需要對目前的所有項目都得有所了解。
在必要時，得自己動手修改代碼，最小化公司的損失。
工作日白天一旦出現 BUG，找到相關開發人員，都能做到及時響應，但麻煩的就是下班后和周末。
大家都不能做到馬上響應，當我看到后，我會想辦法自己解決，不是很喜歡在休息時間麻煩自己的團隊成員修改代碼。
一是因為第一時間不一定能聯系上，避免時間的浪費，二是因為在還沒弄清楚問題緣由的時候就去打擾團隊成員會有點讓人摸不着頭腦，更顯得不夠專業。
為了能做到第二點，那么對項目就得很熟悉，盡量做到無死角。
像前幾天晚上 21 點，發現了一個在iOS上的比較嚴重的問題（安卓正常），我馬上打開那個項目，查看了問題模塊，並且定位到了錯誤位置，分析問題最后做了修復。
在發布代碼時有些不明確的地方（以免代碼發布發生新的問題），聯系自己團隊的成員，但沒有快速響應。
好在平時積累的說明文檔發揮了重要作用，說明文檔中詳細記載了發布的幾個重要步驟。
有不明確的地方，就說明自己在項目中還有很明顯的死角，那么接下來就得想方設法的避免，消滅所有的明顯死角，當然，是無法避免所有的。
5）Node服務升級
一開始將Node服務直接升級到版本12，馬上就報各種錯誤，容器也無法啟動，后面根據錯誤去查找，有個黑人老伙說可以降級到10.14.2來避開這個錯誤。
於是馬上降級到10.14.2，測試環境的代碼發布成功，然后發布到預發環境，邀請業務人員也進來體驗，觀察使用情況。
當都穩定后，最后上正式環境完成升級。
雖然沒有出現明顯的報錯和頁面奔潰，但是卻發生了隱蔽的錯誤，時區發生了問題，在使用 moment.js 庫的時候有些操作會自動加 8 小時，而有些卻會減 8 小時。
有點無厘頭，由於公司的測試資源有限，沒有做完整的回歸測試（也很難做，幾百個頁面了），直接上線無疑會有巨大的風險，綜合考慮后，暫時放棄升級，換一種方式做技術升級。
6）技術分享
為了提升團隊技術氛圍，在參考了網上的資料后，整理並制訂了一套技術分享機制。（目前已進行了3期）
准則：所有的分享都有意義。
目的
- 提供一個團隊內部溝通、交流、學習、分享的平台。
- 技術資料的沉淀，形成公司技術價值。
- 技術落地到實際項目中，讓大家熱愛技術，工作中充滿主動。
形式：演講和茶話會兩種，可在會上准備零食、飲料、瓜子、水果。
時間：每次 40分鍾-60分鍾，兩周一次，周三下午18:00-19:00時間段，一般周三比較空閑，參與度能更高點。
主題
- 新增一個話題圈，了解當前大家感興趣的點，包含技術或非技術兩種。
- 每季度做次規划，從團隊管理、技術弱點、希望提高的方面、產品下一步的技術和框架等，從中選出素材。
講師（分享人）
- 技術團隊各組別輪流做分享。
- 每次分享會需決定下一個分享人。
- 講師需要有一到兩周的准備時間，提前預告，分享大綱或PPT內容，讓聽眾有所准備。
- 在結尾可預留幾分鍾答疑時間（可有獎競答），調動大家的積極性，讓聽眾參與進來。
- 每位分享人可獲得一份小禮物～
內容
建議不要分享XXX的安裝、XXX入門實戰等營養價值比較低的主題。分享可以由淺入深，分多期，但要保證全面和深入，能讓大家真正得到提升。
要分享的內容最好從搜集的主題中選取，因為這些是大家比較感興趣的，參與度會高點。包括但不局限於下面這些：
- 項目的技術產出、工作經驗等總結，例如疑難雜症的調試、閱讀筆記。
- 行業最新技術、流行框架 ，例如 Flutter。
- 跨團隊交流，例如 QA 可分享一些測試方法、自動化自測框架等。
- 對某一個技術點的深入分析，能引入到實際項目中就最好了。
收尾
- 所有分享的資料都要在 WIKI 進行沉淀，保存位置：該頁面下建立子頁面。
- 每個季度讓大家投票，評選出對自己最有價值的分享，評選出“初生星球季度技術部最佳講師“，獎勵200元天貓卡or京東卡一張。
誤區：懂得不多或講得不好，擔心被人嘲諷。
- 如果別人不懂，但是感興趣，那你的分享可以幫助他入門。
- 如果別人也懂，那你的分享可互相促進，共同進步。
- 如果別人的理解更加深刻，那你可借此機會好好討教。