帶團隊後的平常（三）

1、平常問題

1）BUG反饋

　　參與制訂業務方的BUG規範，業務方最近投訴咱們技術部，在飛書羣中提出BUG後，技術部沒有人響應，認爲咱們的態度太冷漠。

　　後面我就提出任何看到的人，只要知道是誰負責的，就@那我的，你們都不要客氣，這是第一步。

　　第二步就是業務方建條BUG單，方便以後的追蹤和回溯，固然，若是條件不容許或者不會建，那就讓測試組的人建立單子。

　　後面其餘人補充了第三步，那就是測試組的人會檢查這條單子是否重複，若重複就直接關閉。

　　我感受這個流程中有個瓶頸，那就是測試組的人須要關注着BUG單，須要損耗一點他們組的人力。

2）量化效率

　　常常會收到各種Web需求的優化，改完測試完後就上線，一套流水線，咱們只是其中的一環。

　　雖然咱們知道這是用來提高他們效率的，可是沒法直接量化提高的效率，這是我最近在思考的問題。

　　量化後，就能知道本身爲他們的工做帶來的多大的價值，其實也能夠提高咱們的工做積極性和參與度。

　　通過驗證後，發現能夠經過以前搭建的監控系統的通訊和點擊日誌，來一步步地計算出耗時，而經過優化先後的兩個耗時，就能得出效率值。

　　固然，並非全部的效率提高都能計算出來，還有不少須要業務方的反饋才能獲得。

3）協調人

　　當須要多端聯合解決問題時，若是沒有協調人從中穿針引線，強力push的話，那麼問題解決將會異常緩慢、效率低下。當無人主動承擔時，可由本身擔任。

　　這兩天客服反饋用戶充值後，虛擬幣沒有到帳，因而查看後臺發現是不少是未支付狀態，聯繫財務進入第三方支付後臺，導出已支付訂單。

　　將兩邊導出的數據作Excel比對，篩選出了50多張有問題的訂單。發現訂單在特定的時間段內（0點~6點之間）出現了問題，根據以前畫的一張問題畫像大體能夠推斷出是第三庫的問題。

　　因而在日誌中搜索他們要回調的接口，發如今那段時間裏一條都沒有。立刻再去聯繫那邊的商務，將問題拋給他們。

　　這裏必須得吐槽下他們的工做效率實在過低，12點50分反饋，一直到17點才說是總部系統問題，期間還得打電話給他們催促。

　　那隻能咱們自救了，聯繫客服諮詢補單流程，再去查看補單以及審覈的代碼。而且查看回調接口的邏輯，以避免二次補發。

　　一切就緒後，和財務一塊兒整理補單須要的數據，再聯繫當時的運營（他也充值了沒收到虛擬幣），測試一條，一切正常後，再讓客服和財務處理剩餘的問題訂單。

　　這樣來來回回，也搞了大概一天的時間。

4）控制需求

　　控制需求並非爲了逃避責任，偏偏是爲了更好地盡責，好鋼用在刀刃上。

　　最近接到一個需求，是在隱私條款更新後，要在APP中彈個框告訴用戶。那麼這裏就會涉及三端：客戶端、服務端和前端。業務方但願能在後臺開放一個可視化頁面供他們操做，服務端但願由咱們提供數據的寫入，他們直接讀取（咱們組有操控數據庫的權限）。客戶端經過讀取服務端的接口來作相應地提示。

　　理想狀況下是作一張爲此功能服務的新頁面，但狀況並不理想。須要控制下需求，功能要作，但實現方式須要商量，並且要給出明確的解釋。

1. 衡量後認爲作新頁面的性價比過低，不只功能太單一，並且還要作兩套（服務兩個APP）。在目前的管理後臺中有不少這樣服務某個功能而已經廢棄的頁面，其實徹底能夠先預判一下，值不值得作或者有什麼更合適的替代方案。
2. 目前的人力資源捉襟見肘，優先級很高的需求正在進行中，若作新頁面，時間成本咱們沒法負擔。
3. 那些頁面被廢棄除了公司的客觀緣由以外，還有人爲緣由，新來的運營都不知道有這些功能，長此以往就用其餘方式替代了，他們的交接有嚴重的問題。
4. 在後臺爲了應付這類動態配置，開發了一套通用配置系統，能夠在此處配置參數，這是一段JSON格式的數據，對運營並不友好。由於更新不會頻繁，因此若要更新數據，可由測試、產品或咱們組的人代勞。
5. 服務端若不想讀取咱們的數據庫，則能夠提供內部接口，幫他們讀取。亦或者他們本身讀庫，緩存起來。

　　由通用配置來實現該需求是一個折中的方案，既能維持咱們本身的開發進度，也不會影響產品的發版。綜合考量後，決定採起此方案，固然在實際使用中還會碰到些問題，這些都好解決。

　　在項目的開發中會碰到不少這樣的場景，並且我相信基本上開發時間人力資源都會很緊張。爲了讓本身不被動，須要想辦法控制住需求，控制的方式有多種，例如提早未雨綢繆實現可複用的技術方案和系統，分析出需求存在的矛盾點引導產品順着本身的思路走，讓出現衝突的業務方本身PK先作勝的那方需求。

5）溝通細節

　　在跨組聯調以前必定要溝通好細節，不能粗粗的一過。要細到數據庫表的一個字段都沒有歧義，不然很容易會在陰溝裏翻船。

　　以前要作一個加密音頻的功能，客戶端播放加密的音頻文件，服務端將這些文件下發給客戶端，後臺管理系統將原始音頻上傳到加密平臺。

　　在一開始的會議時討論的方案是從咱們這邊拿到加密後的文件地址，而後再更新數據庫表的一個新字段，服務端讀取此字段，最後下發給客戶端。

　　可是中途他們的實現方案發生了改變，沒有通知到我這邊（信息不對稱），致使在發生聯調時數據不匹配。

　　我在中途也想固然的覺得更新加密地址就行，沒有對清楚需求。好在，服務端須要的數據在個人代碼中已經讀取到，只要換個參數就能完成聯調。不過下次真的是要好好捋一捋了。

　　通過此次事件後，團隊協做規範中也要補充一條確認細節，以避免再次發生這類失誤。

2、工做優化

1）Node服務升級

　　Node服務升級失敗，原本想從 v8升級到 v10，但出現一個時區問題，沒法解決，只得回退，原本打算用代理轉發的方式，後來想一想這樣太繞了，不必。

　　因而新建一個項目，分配獨立域名，運用TS語言，依託框架 egg.js，它的優點包括：

• 基於KOA，定製上層框架的能力。
• 按照約定進行開發，奉行『約定優於配置』，團隊協做成本低。
• 穩定，功能完善，文檔齊全，適合多種場景。
• 支持TypeScript，提供了應用層開發規範，有了強類型約束和靜態檢查，能夠下降軟件腐化的速度。
• 支持代碼的聲明索引，不用再經過項目搜索來查找變量或方法的聲明處了。
• 讓成員使用新技術新語法的，開闢新的成長空間，並與當前主流接軌。

　　具體遷移步驟包括：

• 引入JWT（egg-jwt），自定義JWT驗證中間件。
• MySQL，MongoDB，Redis的鏈接和配置，引入egg專用插件，egg-sequelize，egg-mongoose和egg-redis。
• 日誌的配置，包括自定義的請求日誌，數據庫查詢語句日誌（包括MySQL和MongoDB），內部請求通訊日誌。
• 將config目錄中的文件所有上傳到配置服務器中，保留 config.default.ts、config.{env}.ts和plugin.ts文件。
• 在服務器中部署時須要先將TS文件編譯成JS文件，再執行start命令，而且傳遞環境參數。
• 當sequelize版本6以上時，要求MySQL最低版本得是5.7，但目前線上的版本都是5.6，所以沒法更改，得想辦法將egg-sequelize降配。
• 在部署Node性能監控平臺的時候也遇到了點麻煩，蒐集不到監控數據，主要是運維配置的問題，前先後後搞了好幾天。

2）問題畫像圖

　　將問題和技術點經過一張圖聯繫起來，可快速而有序地定位到問題的出處。

　　統計每週遇到的BUG，瀏覽公司的BUG單平臺，再將BUG抽象成問題畫像圖，按照「問題 --> 平臺 --> 技術點」的方式梳理。

　　Web端的不少業務都是各種短時間活動，並不是階段性的，所以在提煉的時候比較難以抽象共性，不少問題不具表明性。

　　下圖是通過整理後的問題畫像圖。

　　

　　例如遇到頁面空白，那有多是JSON.parse()數據解析遇到了問題，也多是語法編譯後瀏覽器不支持，亦或者是接口504了得不到渲染數據等等。

　　最後推薦一款開源的辦公軟件：LibreOffice，支持PPT、Word、Draw，本次的圖就是用該軟件製做的，它也支持各個平臺，包括mac、windows和linux。

3）疑難雜症

　　爲每一個項目增長疑難雜症的wiki，記錄花費了不少時間修復或常見問題的排查過程。

　　目的是在下次遇到時，不用再重頭開始，減小修復時間，提高工做效率。既能間接地補充文檔，也能梳理舊邏輯。

　　像以前的那些充值問題，就能夠記錄在案，下次遇到相似問題，均可以此爲參考。

　　在休息時間，線上遇到BUG，若找不到相關人員或相關人員不方便操做電腦，那麼就能讓其餘人員按照記錄的排查步驟，一步步地修復，儘可能作到一個問題可多人修復。

4）先後端分離

　　這是我進公司後一直在推動的一件事，可是得不到服務端的支持，因此一直擱置着。最近遇到個站內信發送的問題，纔將此問題又提上了日程。

　　目前服務端與咱們組分工的職責界線很模糊，很容易發生衝突，因此我才一直致力於先後端分離。

　　咱們組維護着一個比較龐大的管理後臺，它鏈接的數據庫多達8個，但其中只有一個MySQL和MongoDB纔是咱們組維護的，其餘都是與業務相關的數據庫。

　　個人設想是除了本身維護的系統以外，其餘邏輯都應經過調用接口的方式與後端交互（包括增刪改查），咱們組須要與服務端的數據庫表以及緩存作隔離。

　　前端監控系統，開發者工具，後臺帳戶管理等是咱們組的自有系統，仍然由咱們來維護。

　　討論後的方案：

• 將來管理後臺數據請求直接走服務端接口，服務端提供一個新的跨域域名。
• 保留管理後臺的鑑權和權限功能，在登陸時將用戶的權限傳輸給服務端。
• 服務端的鑑權和權限驗證與當前保持一致。
• 日誌保存在MongoDB中，需將其與服務端隔離，開放操做日誌接口，供服務端調用，統一日誌格式。

　　H5活動會走一個Node.js提供的中間層服務，經過它再調用服務端接口。

　　主流的先後端分離是前端只作頁面交互，數據處理全由服務端提供接口，目前在咱們公司有不少現實問題使得難以這麼搞。

　　折中的方案是咱們本身維護Node中間層，業務數據從服務端讀取。但若是是一個大活動，會有很大併發量的，那麼就不走中間層，所有讀取服務端接口。

　　討論後的方案：

• 將來仍是要走分離線路，但目前服務端對活動這塊仍是空白，須要有個搭建過程。
• 先從幾個小活動開始，嘗試着分離，穩步前進。

5）單元測試

　　在公司的幾個項目中，其實早就將單元測試的環境搭建完成，但一直沒有啓用。

　　不作的理由一大堆，諸如：接口就是簡單的增刪改查，讓測試組作功能測試就好了；工期太緊，來不及作；異步通訊須要有後臺接口等。

　　後面讀了篇專欄才瞭解到，單元測試是不須要依賴外部服務的，也就是說不須要鏈接數據庫，調用內部接口、讀取本地文件等。

　　藉助單元測試框架庫（例如sinon.js），可以模擬出那部分外部服務，從而就能完成各個功能的單元測試。

　　結合當前項目的實際狀況，我並不要求組內成員覆蓋率達到一個數字，只須要對那些比較核心和複雜的業務邏輯加上單元測試便可。

　　我在使用時，會修改源碼，讓源碼更容易測試，以函數或方法做爲一個單元，在測試的過程當中，發現了些潛在的問題，並當場修復，免得測試的時候出現而返工。

6）Code Review

　　雖然每週都會開個週會，但Code Review還從未作過，根本緣由仍是由於沒有認識到Code Review的價值。

　　最近有個比較重要的年中活動，因此在提測以前先作了簡單的Code Review。

　　在這個過程當中糾正了一些影響思路和視覺的寫法，例如 if 的一個判斷分支要一百多行，另外一個分支就兩行，那能夠將短的分支移到上面加個 return，長分支轉移到後面便可。

　　還找到了幾個聯調錯誤，避免在測試階段才發現，形成沒必要要的返工，影響測試進度。

7）B計劃

　　軟件的風險管理是必需要考慮的，在項目的開發階段，就要提早考慮線上出現情況時的B計劃，未雨綢繆，防患於將來。

　　例如定時任務中會計算榜單，當計算出現錯誤時，該如何快速恢復榜單數據？補救措施是提早備好腳本，在後臺管理系統中留執行該腳本的入口。

　　還例如會員充值從銀聯支付替換爲微信公衆號支付，在試運行期間須要保留一個能夠在二者之間切換的開關，當出現問題時，可快速應對。