如何做系統重構(下)
前兩天完成了《如何做系統重構》上半部分，今天的內容沿著上部分來繼續展開下去。上半部分寫了4點，那麼下半部分繼續寫4點。
5. 採用「迭代式」重構
做過重構的小夥伴都知道，做重構的複雜度並不亞於做一個全新的產品，和自己的小夥伴私下溝通下來，都願意重新做，而不是在老的代碼上改。在這裡說這個話的意思在於重構並不是一個一蹴而就的事情，既然如此，那麼我們就需要考慮將一次重構拆分為多次「迭代」行為，然後每一個重構步驟能快速部署上線並得到反饋，以便評估重構的效果，及時作出調整。從項目風險的角度來說，通過將重構分成多個迭代，能有效的控制迭代的風險，每一個步驟，重構團隊（開發和測試）都能集中一點吃透，並進行充分的測試。如果直接將重構1，2個月後的版本，一下丟給測試同學去驗證，效果可見一斑。
另外一方面，重構過程對bug的容忍性比新產品的研發更低，上一次重構迭代的結果，決定了下一次重構迭代的執行。不論團隊多忙，一定要保證代碼提交之前，是經過其他成員審核過的，短期來看會佔用團隊的時間，長期來看是事半功倍的好事。
至於如何來拆分重構，並沒有一個統一的標準，但是我個人的看法，每次重構的工作量，不應該超過1個正常的迭代（2周時間）。
6. 重構首選團隊熟悉的技術
在我們制定重構方案過程中，第三方技術框架的選擇至關重要，這關係到重構最終的成敗，畢竟最後判斷重構成功與否的是上線正常運行，所以是選擇最新流行的技術還是發展成熟的技術其實並不重要，重要的是我們團隊能否駕馭這門技術，是否有對應的人才儲備，我們是否清楚該技術裡面的「坑」，是否可以找到對應的技術社區幫助我們應對執行過程中產生的問題，在這裡可以和大家講一個我自己經歷的慘痛的教訓，2年前，我們在緩存方案上選擇了我們並不是特別熟悉redis cluster, 而不是常規的redis 2.x版本，或者阿里雲的KVStore，上線後，踩了各種坑，每次都只能事後來修復，充分暴露了如果對該技術沒有吃透，就將它推向生產線，那就有很大的潛在風險，當然，如果現在上Redis Cluster, 我是很有信心的，因為我已經掌握了 
。對技術的選擇上，我們需要反覆確認各種技術方案對系統重構的影響和效果，必須要有前置的技術調研，並拿到對應的調研數據，根據數據和經驗來做決策。
7. 重構前務必和業務方溝通
很多技術團隊認為，重構的事情就是技術團隊內部的事情，但是從我過去共事過的多個團隊看，這個想法過於天真了，重構的最終目的就是改進業務和更好的承接業務，所以如果不和業務方做充分的溝通，甚至不了解業務就開始做重構，結果就是很可能沒有抓到重點，例如，我們需要知道哪些關鍵業務的架構是不能輕易碰的，哪些業務之間是互相關聯的。所以，我自己的技術團隊在執行重構前，會和產品團隊，運營團隊做充分的溝通。
與業務方溝通的目的有2點：了解業務方的述求，並把這些點放入到重構過程中，梳理清楚代碼中，各類業務的運行情況，清楚每一項業務的重要程度。
尋求業務方的支持和幫助，重構過程中，需要和業務保持積極的溝通，確保重構不會對業務產生影響。 反過來說，通過溝通，才能獲得業務團隊對技術團隊做重構的支持和理解，重構過程中才不會碰到非技術層面上的障礙。
8. 重視重構中的非技術問題
這一點是我過去1年，理清楚的一些問題，趁這個機會分享一下：
舒緩團隊的壓力，給予團隊更多的鼓勵。 說白了，重構對個人或者團隊來說通常是一件費力不討好的事情。和做一個新產品或者新功能，能夠取得老闆或各業務方的掌聲相比，重構的成績往往不受老闆重視，而且出了問題還要承擔很大的責任。 因此，重構之前，我會提前給團隊做好心理準備，打預防針，幫助大家舒緩壓力，並且將重構的成果量化和業務的變化關聯起來，定期向各方同步狀態，得到大家的理解和支持。
做好重構過程中各種非技術溝通，任何一次較大的技術重構，都會遇到一些非技術因素，而這些因素往往不是我們所能掌控的。我們能做的就是與相關利益方進行有效的溝通，坦誠地和他們交流，非技術因素的影響是客觀存在的，從公司層面來說也是合理的，對於技術人來說要學會適應。
關於重構的話題就先告一段落了，大家有任何想法和建議，請留言與我聯繫，希望得到大家更多的反饋。
封面是我另外一本喜歡的重構相關的書，通俗易懂，將重構中常見的一些模式都介紹到了，而且還提出了很多有價值的建議，大家有興趣的話，可以讀讀。
掃碼關注 本訂閱號： ForestNotes
推薦閱讀：
