概述
在之前的文章技術經理成長復盤-發現團隊的瓶頸中提到，需要洞察出團隊里需要有什么重要的事情要做，當時分析的結果是，需要先搞重構，把這個事情做了，將來才能提高團隊的產出，當時搞重構是非常困難的，有點天空中的飛機換引擎的感覺，具體有如下幾個難點：
- 需要重構的功能模塊一直還有業務需求，這個對開發和測驗人員都是挑戰，因為重構的功能如果還沒有全量上線，中間就得一直在新舊代碼里同時寫業務需求，測驗人員則每次上線都得兩邊一起測驗,這里也就涉及到一些人力資源的問題；
- 重構的核心功能不能出事，如果有故障，必須一分鐘內切回到舊流程；
- 重構的核心功能業務復雜，很容易梳理遺漏；
既然困難點不少，重構負責人就必須對重構這個事情的價值有比較好的認知，不然一遇到困難，就會退縮的，當時團隊的實際情況，我在技術經理成長復盤-發現團隊的瓶頸提到過，不重構的話，團隊的整體產出將會越來越低，后續別說快速交付業務需求了，連回應業務需求都成問題了，另外不盡快重構的話，還有如下幾個問題：
- 會成為后續公司進行數字化的攔路虎，因為團隊負責的是公司最核心的業務，不重構完，做數字化會困難重重；
- 技術堆疊不能一體化，運維的同事得同時維護
PHP和JAVA應用，無法很好的做統一化發版、監控，很容易出事；- 系統出了事，永遠只能找固定的幾個
PHP開發來定位；
好了，說了這么多，下面可以具體講講當時重構發生的一些事情了，
列好重構計劃并與上司溝通
像PHP轉JAVA這種大事情，是一定需要上司的支持的，因為你需要占用一定的人力去做重構的事情，也就意味著部分組員無法承擔業務需求開發，那么產品經理肯定是有意見的，而測驗那塊就更加不用說了，直接加大了他們的測驗作業量，而且還可能給他們惹事呢，比如說重構的功能出故障了，那么當產品經理和測驗有意見，而自己搞不定的時候，需要上司去協調處理，
比較好的做法是，當上司同意你做這件事情的時候，需要再開個會議，拉上產品經理、測驗經理、PMO，將資訊和重構計劃同頻一下，方便后續重構專案的推動，如果他們意見很大的話，連你的上司都搞不定，那就只能將問題上升到更上一層，由大BOSS去拍板，
當時我這邊的重構計劃，是分三個里程碑：
- 下單、拉起支付、支付回呼，這幾個模塊是最核心最難弄也是最重要的模塊，平時大部分的業務需求也都會改動到這塊，因此得先動刀，盡快上線，盡快把影響團隊接需求吞吐量的地方消滅掉；
- 其他核心模塊，重要，但不是最緊急的；
- 非核心模塊,主要是一些功能簡單的模塊，
有了計劃，有了人，其他職能團隊也都協調好后，就可以開干了，
艱難的下單重構
下單介面的開發和測驗時間，其實都不長，還算順利，但是上執行緒序確極其艱難，總共折騰9次，灰度了一個多月，才真正的把整個下單介面全量(所有下單請求都全部走JAVA介面)了，后來我分析了一下，有如下幾個原因：
- 測驗
case有疏漏；- 下單介面業務復雜度超乎想象,很容易漏掉場景和踩到坑；
- 中間有業務需求，
在測驗階段，我們當時的做法是，根據列舉好的case，先用JAVA介面下單，然后用同樣的商品，用老介面下單，然后進行資料對比，如果新老訂單資料能完全匹配上的話，說明新介面的邏輯沒問題，但是很遺憾，我們的case漏了不少場景，導致每次剛一灰度線上流量，沒過多久，要么介面報錯，要么寫的資料不對，只能切換回老介面，來來回回折騰了很多次，而每次上線都需要測驗和運維的支持,有好幾次還讓他們在星期六日支持呢，到了后面測驗人員和運維，也開始都有意見了，運維的觀點是，別老上線，對生產環境得有敬畏之心，測驗的觀點是，上不上測驗說了算，但是作為重構負責人，我是通通不管這些的，因為沒有按照計劃走，我們說好這個星期要達到什么目標，就必須達到，而產品經理則時不時過來問，全量了沒？哎，壓力山大，
有網友可能會問，第一次上線失敗后，就應該趕緊重新完整梳理一下測驗case，但是我想說，那段舊的代碼真的不想再看了，真沒心情，另外公司也沒人可以盡量的將整個下單介面窮舉出所有case，不過，當時是有按照用戶灰度的，只要一出現問題，能立刻切換回去，對線上的用戶影響很小，因此就是遇到一個問題修復一個，折騰了一個月，最終全量，
順豐順水的支付回呼重構
拉起支付的介面雖然是核心介面，但是業務邏輯不算復雜，上線后，折騰了4次就全量了，這里我想重點說一下最難搞的支付回呼介面，雖然難度最大，但卻是三個核心介面中，上線最順利的，
公司是搞茶飲行業的，用戶的訂單給了錢，支付回呼回來后，是有大量的業務邏輯需要去執行的，像列印杯貼小票、跟會員、門店、商品系統互動、跟財務系統對接、訂單狀態扭轉等等，
雖然復雜，但是基于之前下單介面9次才全量上線的教訓，支付回呼介面特別的強調需要做好幾件事情：
- 找個非常細心的開發人員，在重構的程序中，梳理出支付回呼的業務場景；
- 邀請了公司里業務最熟悉的測驗人員，基于開發列的業務場景
case，寫測驗用例，盡量確保完整和準確；- 基于測驗用例，用同樣的商品走新舊邏輯的支付回呼，對比列印出來的小票和杯貼(公司是有線下店業務的)，必須一模一樣；
- 實時監控,只要有一個報錯資訊，立刻告警，先于業務方發現問題，
在靠譜的開發和測驗的合作下，有了一份非常完整的測驗用例，功能測驗、回歸測驗、線上測驗都是基于這份測驗用例，用了兩個星期時間，介面就灰度完畢，全量上線了，且中間基本沒出現問題，
跟著業務專案上線的功能
像上面提到的下單、拉起支付和支付回呼的重構，都是無法跟著業務專案上線的，因為這些介面上線后都需要灰度，且灰度時間也不短，業務專案的話是不可能上線后還接受灰度的，但是對于一些不需要灰度的重構模塊，則可以跟著業務專案上線，這其實一種非常好的方式，既可以做業務需求，給產品經理一個交代，又可以節省測驗資源，因為測驗人員只需要測驗一次，就可以把業務功能和重構的東西一起上上去，提高了效率，
自測的功能
如果測驗資源非常緊張的話，業務專案又非常趕，測驗人員不愿意帶著重構功能上線，那么可以采用如下的方式：
- 完全由開發人員自測后上線，當然這個需要選擇細心、代碼質量高、熟悉業務的開發人員去做；
- 開發人員自測，測驗人員走完主流程后就上線，降低對測驗資源的使用，
像最近，有10多個PHP定時任務，我就是讓其中一個組員，全部自測后上線，沒有動用任何測驗資源，上線后一點問題都沒有，當然選人很重要，像這種開發自測上線的，最好選擇細心、代碼質量高、熟悉業務的人來搞，
測驗資源不足的話，還有一種辦法，就是讓開發自測，然后在回歸環境，讓測驗人員過一下主流程即可，不過要提醒測驗人員，如果是過主流程的話，一定要認認真真詳詳細細的過，而不是點擊兩下界面，資料能寫入能展示就完事了，要認真的觀察資料是否正確，
總結
本文提到了做重構的價值以及難點，同時也介紹了上線灰度、跟著業務專案上線、自測上線 等重構手法，幫助推動重構，另外要提到一點的是，如果你是重構的負責人，把重構這個事情做成的欲望必須是最強的，不然面對中間程序中出現的困難，絕對會打退堂鼓的，
目前的話，自己團隊負責的重構任務基本完畢了，足足搞了大半年，雖然困難重重，但是重構這個技術專案，對公司對團隊對個人都是有好處的，有這個，也就值了，
CSDN認證博客專家
專案管理
團隊管理
總結和思考
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/234209.html
標籤：其他
上一篇：2020-12-12