一、日常問題
1）協作團隊資源不足
這次公司有個五周年的慶典活動，但正好碰到兩個APP的版本發布，以及三個測試老員工離職，只進來了兩個新成員，其中一個恰好要休陪產假，那么測試組資源異常緊張。
雖然我們提前了整整一周提測，但一直到周五還有很多點沒測到。測試組甚至想到了階段測試，因為多個活動的上線時間不同，所以可以先測最先上線的活動，后面的再往后推，延遲測試，這是他們組的一個對策。
而我們前端組，可以做的就是先按照他們的測試用例，自行跑一遍，提前幫他們把一些明顯的BUG修復掉。雖然不能很深的測試，但至少可以替他們節省不少時間。
有時候就是一些很簡單的問題會拖慢整體節奏，例如數據缺失、頁面白屏、接口不通等。
打破常規，在測試環境的時候就將頁面給產品體驗，而不是等到預發才確認。
因為她可能掌握着一些我們不知道的信息，例如我們都以為頁面只會在活動開始的時候才會開放訪問，其實不然，運營會提前一天造勢，所以的話，有些操作需要加時間判斷，這是之前未考慮到的點，得修改代碼。
這樣的話，既拖慢了上線時間，也有可能造成潛在的BUG出現。雖然做了很多保障，但是周五晚上還是加了會兒班。
2）低代碼
低代碼在行業里比較流行觀點是更加易用、降低開發成本的搭建系統。其實就是面向特定場景做抽象、沉淀出最佳實踐，再通過產品封裝來加速整個制作過程。
我這邊實現低代碼的第一步，是將常用的活動功能提取出來，減少代碼的體量，增加代碼的穩定性。
例如公司常規的打榜活動，活動形式和玩法都比較固定，於是組織團隊三個成員分別將活動的三端抽象化。
我負責榜單的數據源，開發了一套針對該類型活動的定時任務，在后台可視化操作，可事實更新參數。
另外兩名成員，一個是將前端頁面中通用的部分封裝成組件，包括表單、菜單切換、埋點、分享等。
另一個是將請求接口中的邏輯封裝成幾個方法，未來只要傳幾個參數就能獲取到對應的數據，並且將一個可配的參數存儲在通用配置中，而不是硬編碼在代碼中。
這套組合拳打出來之后，可大大縮短活動的開發周期（目標是一天），也能解放測試，因為系統穩定后，就可以直接上線了，運營人員也不用半夜找我們修改BUG了。
當然還有第二步，那就是將前端頁面也做成可視化的，拖拖組件就能完成搭建。
3）規范開發流程
公司最近上線了一個新禮物，但在上線后出現了很多問題，例如新禮物的收益未計算在榜單中、新禮物出現在錯誤的類別中等等。
技術團隊內部討論后，由技術部leader牽頭，為了避免重蹈覆轍，重新制訂了一套保障研發順利進行的流程。
而在這個流程中會新增一個臨時 PM（項目經理）的角色，其職責和我之前提到的協調人差不多，這個人在項目開發過程中起着非常關鍵的作用。
這套流程分成六個部分：需求評審、技術評審、用例評審、測試驗收、提審上線和復盤總結。對於我們前端來說，提審上線這一步是不需要的。
每一部分都會有幾個清單，當完成時就把勾打上，當不存在時，就直接刪除，開發成員只要查看這份清單就能洞悉目前的開發進度。
需求評審是為了確保需求清晰無疑問，UI設計及時交付，埋點准確無誤。
技術評審是為了確保相關技術人員都參與到了技術方案的討論中，避免出現細節遺漏。
用例評審是為了確保測試用例和冒煙用例都已傳達到了相關技術人員，明確本次測試方案。
測試驗收是為了確保測試人員已在測試環境、預發環境、生產環境驗收，以及業務部門也已驗收。
提審上線是為了確保客戶端已發布應用市場和App Store。
復盤總結是為了解決掉研發過程中暴露出的問題，輸出相應的解決方案，避免再次踩坑以及提前預防此類問題或相關問題的發生。
4）結點不一致
最近遇到個比較離譜的事情，大家做項目的時候，居然對上線時間都有偏差。知道是那一天，但有的認為是0點，有的認為是10點，有的認為是20點。
之所以會有偏差，是因為產品文檔上寫的上線時間是0點，而與這個項目同時進行的還有另一個項目，上線時間是10點（也就是說，兩個項目混淆了），認為晚上20點上線，其依據的是效果圖中的活動時間。最終和產品協商后發現是20點上線，產品這個鍋得背一下，需求文檔沒有及時更新，但大家以后真的得好好對一對上線時間。
這是一個比較嚴重的信息不同步，直接導致了大家修BUG的速度有快有慢。測試在拋出BUG后，就要等待相關人員修復，一個多端聯調的BUG就會花費比較多的時間，進度緩慢，很容易出現不必要的加班。
之前的流程中曾選出一個臨時PM，而這個人是有責任來協助測試人員完成測試任務的，尤其是臨近上線的時間。最簡單直接的方式就是每隔一段時間詢問當前進度，了解卡在何處，想辦法幫助推進，協調資源。不要白天悠閑的修修補補，到了晚上突然冒出這個那個的問題，產品和運營都沒時間給他們驗收，匆匆忙忙的上線，后患無窮。
5）菜單梳理
經常會有人來問我管理后台的XX功能有沒有或怎么用，出現了XX問題，該怎么解決。
其實很多時候我也不太清楚，自己也是中途接手。最清楚的人莫過於每天都在使用的業務人員，所以首先得知道哪些人在用哪些功能。
在和產品溝通的時候了解到，她們之前特地整理過一份管理后台使用人的表格，只是內容還未填寫。
表格的橫坐標是小組，縱坐標是菜單，每個單元格都有每日、每周、每月和偶爾使用的選項。
后面拉了個群，將相關負責人邀請進來，讓他們把各自負責的部分填寫了一下。以后找功能就能快速定位到某個小組了。
測試組對管理后台也是比較了解的一個小組，因為他們也需要經常操作各類菜單。在和他們溝通時，他們提供了一張管理后台功能的思維導圖。
這是之前他們專門花了幾周時間安排一個人力做的整理，覆蓋了那期間的所有功能。由於之前管理后台是沒有產品支持的，所以也就沒有產品文檔。
有了這張思維圖后，對於我們來說，是一個非常好的參考。
無論是使用人表格還是思維導圖，都有一個比較麻煩的點，那就是需要有專人來維護。經過幾個月的發展，管理后台又新增了一大批功能，這些都還未整理進來。
后期需要討論下由哪個組來維護這些文檔。
6）邊角項目
邊角項目是指那些隱藏在角落里，讓人忽略的項目，隨着人員的流動，這些項目往往就會被埋藏起來，沒人知道還有這么一個項目存在。
一旦碰到這類項目，就需要花大量時間尋找源碼和閱讀邏輯，有時候還得重新配置發布環境，往往需要聯合運維來查找這類項目。
這類項目神秘莫測，往往無法主動將它們揪出來，因為沒有任何文檔遺留，或者在眾多文檔中輕描淡寫的記錄了一句話，很容易讓人看走眼。
最近碰到兩個這樣的項目，一個是運營說要更新官網主頁，一看到域名，就知道之前沒有維護過，找運維才定位到指向的項目。
另一個是小程序中出現了一個BUG，經過排查發現調用了一個接口，但這個接口不在平時維護的項目中，翻閱文檔，才知道原來這類接口存在於一個獨立的項目中。
這兩個項目有個共同點就是都已經斷更，前者是之前就很少維護，后者是已將大部分接口遷移到另一處。
目前唯一的手段就是補充這兩個項目的文檔，完善信息，下次再遇到就能胸有成竹了。
二、工作優化
1）代碼腐爛
這是我最近聽到的一個新詞語，所謂代碼腐爛，簡單地說是指代碼在可維護性，靈活性，可移植性，可重用性，可測試性，可理解性等質量方面變得越來越差。
代碼腐爛不是一搓而就的，都會經歷一個循序漸進的過程。聯想到我當前公司的項目，它們也正在腐爛中，而造成腐爛的原因包括維護他人遺留下的代碼，技術棧長期未更新等。
在缺少代碼規范、注釋，並且無法與之前的維護人員有效溝通時，修改當前代碼難免會不理解當時的設計思路和邏輯結構，按自己的想法去修改，可能會留下不穩定因素，而給自己埋坑。
減緩該腐爛的方法就是多加注釋，多為核心業務編撰各類文檔，制訂代碼規范統一代碼風格。多多沉淀，穩定代碼，少做少錯，例如抽象后台業務組件，定時任務參數化，通用接口等。
老舊的技術棧會限制使用新的庫、新的開發思想、甚至限制團隊成員的技術拓展，例如公司還有一個項目在使用jQuery，Node項目還基於8.7的版本，后台管理系統基於Umi 1.0 並且是個巨石應用。
減緩該腐爛的方法有多種應對策略，目前正在將jQuery技術棧遷移到Vue；Node項目正在遷移到基於14版本的新項目中；對后台管理系統進行剝離，引入微前端整合新舊兩套系統。
個人感覺代碼腐爛是一種自然趨勢，我們所能做的就是減緩腐爛的速度。
2）返回上一頁
在管理后台中身份過期后就要重新登錄，目前只會登錄到主頁，並不返回上一頁，在體驗上大打折扣。
我們的賬號會開放所有菜單，每次在系統開發階段過一天刷新頁面就要重登陸，然后再找一下菜單，這一找就得花個幾十秒甚至幾分鍾，非常浪費時間。
於是決定加此功能，首先想到的是在Server端讀取上一頁地址。
每次頁面切換，都會請求一個身份接口，於是在接口中讀取 KOA 封裝的屬性：ctx.request.headers['referer']，但事與願違，得到的卻是 undefined。
查看 HTTP 請求中的首部，發現有一個 Referrer Policy: no-referrer，也就是禁用了 referrer。搜索前端頁面，發現模板中的 meta 元素有一段聲明：
<meta name="referrer" content="no-referrer"/>
經過與同事溝通，發現他當時為了解決一個BUG才加的這段。在團隊協作開發時，切記不可貿然修改源碼，很有可能影響原有邏輯。
如此一來就不可在服務端請求，但即使我取消了這段聲明，在Server端返回上一頁，改造成本也是巨大的，只得放棄該方案。
另一個方案就是在前端頁面中增加讀取上一頁的邏輯，馬上想到的是 document.referrer，但發現每次讀取都是空字符串，很是不解。
后面再想一下，才發現后台管理系統是一個單頁應用，所以跳轉地址並不會刷新瀏覽器，也就無法通過 document.referrer 讀取上一頁了。
但既然是單頁應用，那么就會有瀏覽器的歷史記錄，我們的框架使用的是 react-router-redux，一翻文檔果然有返回上一頁的方法：goBack()。
不過又出現了新的問題，就是如果直接在瀏覽器中輸入登錄的地址，那么就沒有上一頁，默認得跳轉到主頁，得判斷出這種情況。
在該庫中沒有什么發現，后面再深入到HTML5的History對象，發現它有一個 state 屬性，記錄了歷史堆棧頂部的狀態值，若沒有就是null，這樣就能判斷了。
在實際使用中發現重登陸后，還是會跳轉到主頁，經過排查發現在回到登錄界面時並不是路由切換，而是地址跳轉，等於說是重新進入了一個頁面。
此時頁面並不存在上一頁，所以默認就會切換到主頁。
后面是在監聽全局路由切換的事件中（使用的是dva.js），通過sessionStorage緩存當前頁面的路徑，在登錄的時候切換至緩存中的路徑。
subscriptions: { setup({ dispatch, history }) { history.listen((location) => { if (location.pathname !== '/login') { sessionStorage.setItem('last_pathname', location.pathname); //緩存上一頁路徑 } }); }, },
一個看上去蠻簡單的功能，但其實真正做起來還是需要花點精力和腦力的，並且還要了解一些原理。
3）靜態頁面配置
靜態頁面是指那些只要幾張靜態圖片的頁面，沒有任何交互和跳轉，例如宣傳頁、各類政策等。
這類頁面雖然重新開發成本並不高，但是將前前后后的時間統計起來（包括開發、發布、驗收等步驟），其實也不少，半小時最起碼。
並且做好后，在驗收階段很有可能對圖片修修改改，那么就需要重新發布。最麻煩的是在休息時間要求修改，那么很難第一時間做出響應。
經過綜合考慮，還是在后台做個功能，讓運營或產品可以自行編輯和發布這類頁面，讓他們不用那么被動，大致效果如下圖所示。
就是一個標題以及動態添加圖片地址，當然也可以做出動態上傳圖片。
這是一種簡單的樓層搭建方式，如果有人力有資源的話，可以做一套可視化搭建系統，將各類運營活動集中到該系統中處理。
4）代碼發布提速
后台管理系統分為前端頁面和后端服務兩個項目，后端服務代碼發布的時間很穩定，但是前端頁面的發布時間就很冗長。
在剛接手這個項目時，發布時間在10分鍾左右。當時就和運維商量，出個解決方案來提速。
運維找到阿里雲的技術支持，但是也沒有一個好的解決方案，就這樣不了了之了。
經過幾個月的時間后，我上線了前端監控系統。這套系統需要監控項目的source map文件。於是在構建后台管理系統的腳本時，多了一步生成該文件。
由於管理系統的腳本已經非常巨大，所以構建的過程又被拉長了，代碼發布的時間也被加長。有時候甚至要20分鍾，可能還無法正確發布。
基於umi升級的這次契機，我關閉了source map文件的生成（在實際使用中，也很少用到該功能），發布時間一下子穩定在了8分鍾左右。
不過，這個時間仍然無法符合我的預期，再去和運維商量。他的意思可以打一個鏡像，不用每次都下載npm中的依賴包。
這個提議非常好，馬上就讓他幫忙弄了一下，經過了幾次調試，終於發布成功了，目前穩定在4分鍾內。
在實際使用中，卻出現了非常嚴重的問題，運維將源代碼也打包到了鏡像中，也就是說，我更新的代碼不能發布，那這樣的話，這個優化就沒有意義，只能回退到原先的樣子。
5）活動復盤
最近上線了兩個差不多的活動，在實際運營中，共出現了三個問題。雖然都不是致命的BUG，但也暴露出了不少問題。
這次的三個問題都是時間導致的，可以看出組內的成員對比較基礎的時間處理還比較模糊。
后面就抽空帶大家一起重新學習了JavaScript與時間相關的基礎概念，查缺補漏。
並且再次強調了單元測試的重要性，因為這次的幾個BUG，測試不一定能測出來。因為要與需求保持一致的話，就得修改服務器時間，與活動的截止日期保持一致，才能測出來。
但如果自己做了單元測試，那么就可以通過傳入不同的時間參數，得到不一致的結果，從而就能將問題扼殺在上線前。
當然，這次測試人員有些地方也沒到位，未來的話，是希望測試的時候，有些方面要與需求保持高度一致。
以后每次活動之后都可以做點復盤，保持好的方面，改正壞的方面。如果能在下次的活動中避免出現相同的問題，不再重蹈覆轍，那也是一種收獲。