重構，是任何乙個技術團隊都無法繞過和迴避的話題。記得10年前，我的第乙份正式工作，就經歷了專案持續的重構歷程，為了寫好**，當時還反覆讀了martin flower的《refactoring》。時至今日，這本書裡的很多內容仍能給我很多啟示。最近，回顧了一下10多年來經歷的各類專案，發現還是有很多內容值得拿出來分享一下的，所以整理了這篇文章，拋磚引玉，期待大家有更多好的想法能冒出來。
關於做重構，我個人覺得可以按照以下這條線來執行。
1. 明確本次重構的目的
我的第乙個觀點，重構是有代價的，伴隨著業務的不穩定（引入新的bug）和人力資源的投入（大家需要暫時放下業務的推進）。所以在我們動手之前，一定要明確我們本次重構的原因是什麼，是為了滿足業務的需要或僅僅只是覺得架構有缺陷。
每一次架構的重構都是「傷筋動骨」，就像做手術一樣，即使再成功，也會傷元氣。重構的首要目的一定是為了更好的滿足業務需求，然後再考慮其他問題。這就意味著，如果本次重構對未來業務承接的促進很小的話（比如僅是引入新的框架和技術），那麼本次重構需要慎重或者暫緩。同時，需要認真比較重構的各種方案的利弊，想清楚後再開始，任何時候都需要有方案b。
2. 明確當前系統的狀態
決定要執行重構後，首要做的任務，並不是立刻動手執行重構，而是對當前的架構狀態有清晰的了解。如果開發當前系統的小夥伴還在本公司，一定要和他好好的討論一下，由作者給大家講講當時的思路，比我們悶頭看**理解還是要強不少的，還能清楚理解當前系統的設計初衷。除此之外，只有通過研究當前系統，才能記錄目前系統的效能基準，為未來評估重構的效果做準備。過去，我遇到不少同學，還沒吃透當前系統的設計和**，就大刀闊斧的開始重構了，最終的結果很可能是引入regression bug， 或者是執行過程中，發現重構不下去了，原來這塊的架構是為了達到某某業務需求啊，這塊不能動，得想別的辦法。
所以不吃透**和架構，直接進行重構是很危險的，慎行。
3. 重構的目標必須被量化
如果確定要重構，那麼要把目標明確下來，也就是重構的邊界條件，明確列出本次重構需要完成的要點，目標要有資料量化（比如**行數降為過去的一半，**執行時間縮短為過去的30%等等）。同時，重構後的**能夠被有效的測試。
重構之前，需要有乙個需求分析的過程，如果需求不明確，重構prd不能寫清楚，負責重構的團隊也就很難有明確的目標。特別是重構工作被乙個團隊來執行的時候，所有的成員（包括開發成員內部，以及開發和測試之間）對重構的目標必須要達成一致，謹防重構不到位或者過度重構。
4. 重構中必須建立或維護業務資料流
現在任何乙個後台系統，都會通過日誌系統建立必要的業務流轉記錄。比如，我這幾年前後帶的幾支團隊，都會建立各類業務埋點。本質上的原因在於，業務都是以資料流為載體的，架構重構的本質就是讓資料流更通暢。所以在重構過程中，我們務必保證以下兩點：
1. 重構後的系統，對於資料的儲存、處理、分析等功能沒有影響；
2. 在重構過程中或者重構後，我們能用資料來驗證重構的效果，能不斷的對系統進行優化。
5. 採用「迭代式」重構
做過重構的小夥伴都知道，做重構的複雜度並不亞於做乙個全新的產品，和自己的小夥伴私下溝通下來，都願意重新做，而不是在老的**上改。我在這裡想要表達的意思在於重構並不是乙個一蹴而就的事情，既然如此，那麼我們就需要考慮將一次重構拆分為多次「迭代」行為，讓每乙個重構步驟能快速部署上線並得到反饋，以便評估重構的效果，及時作出調整。從專案風險的角度來說，通過將重構分成多個迭代，能有效的控制迭代的風險。每乙個步驟，重構團隊（開發和測試）都能集中一點吃透，並進行充分的測試。如果直接將重構1，2個月後的版本，一下丟給測試同學去驗證，效果可見一斑。
另一方面，重構過程對bug的容忍性比新產品的研發更低，上一次重構迭代的結果，決定了下一次重構迭代的執行。不論團隊多忙，一定要保證**提交之前，是經過其他成員審核過的，短期來看會占用團隊的時間，但是長期來看是事半功倍的好事。
至於如何來拆分重構，並沒有乙個統一的標準，我個人的觀點是，每次重構的工作量，不應該超過1個正常的迭代（2周時間）。
6. 重構首選團隊熟悉的技術
在我們制定重構方案過程中，第三方技術框架的選擇至關重要，這關係到重構最終的成敗，畢竟最後判斷重構成功與否的標準是上線能否正常執行。所以，是選擇最新流行的技術還是發展成熟的技術其實並不重要，重要的是我們團隊能否駕馭這門技術，是否有對應的人才儲備，我們是否清楚該技術裡面的「坑」，是否可以找到對應的技術社群幫助我們應對執行過程中產生的問題。
在這裡和大家講乙個我自己親身經歷的慘痛教訓。2年前，我們在快取方案上選擇了我們並不是特別熟悉redis cluster, 而不是常規的redis 2.x版本，或者阿里雲的kvstore，上線後，踩了各種坑，每次都只能事後來修復。這次經歷再次說明了如果對該技術沒有吃透，就將它推向生產線，將有很大的潛在風險。當然，如果現在上redis cluster, 我是很有信心的，因為我已經掌握了 。
對技術的選擇上，我們需要反覆確認各種技術方案對系統重構的影響和效果，必須要有前置的技術調研，並拿到對應的調研資料，根據資料和經驗來做決策。
7. 重構前務必和業務方溝通
很多技術團隊認為，重構的事情就是技術團隊內部的事情，但是從我過去共事過的多個團隊看，這個想法過於天真了。重構的最終目的就是改進業務和更好的承接業務，所以如果不和業務方做充分的溝通，甚至不了解業務就開始做重構，結果就是很可能沒有抓到重點。例如，我們需要知道哪些關鍵業務的架構是不能輕易碰的，哪些業務之間是互相關聯的。所以，我自己的技術團隊在執行重構前，會先和產品團隊，運營團隊做充分的溝通。
與業務方溝通的目的有2點：
1. 了解業務方的訴求，並把這些點放入到重構過程中，梳理清楚**中各類業務的運**況，清楚每一項業務的重要程度。
2. 尋求業務方的支援和幫助。重構過程中，需要和業務保持積極的溝通，確保重構不會對業務產生影響。 反過來說，通過溝通，才能獲得業務團隊對技術團隊做重構的支援和理解，重構過程中才不會碰到非技術層面上的障礙。
8. 重視重構中的非技術問題
這一點是我過去1年，理清楚的一些問題，趁這個機會分享一下：
舒緩團隊的壓力，給予團隊更多的鼓勵。說白了，重構對個人或者團隊來說通常是一件費力不討好的事情。和做乙個新產品或者新功能，能夠取得老闆或各業務方的掌聲相比，重構的成績往往不受老闆重視，而且出了問題還要承擔很大的責任。 因此，重構之前，我會提前給團隊做好心理準備，打預防針，幫助大家舒緩壓力，並且將重構的成果量化和業務的變化關聯起來，定期向各方同步狀態，得到大家的理解和支援。
做好重構過程中各種非技術溝通。任何一次較大的技術重構，都會遇到一些非技術因素，而這些因素往往不是我們所能掌控的。我們能做的就是與相關利益方進行有效的溝通，坦誠地和他們交流，非技術因素的影響是客觀存在的，從公司層面來說也是合理的，對於技術人來說要學會適應。
如何做研究
來自 在研究生期間，一開始大家都很迷惑，都不知道自己要幹什麼 該幹什麼？即便知道自己要幹什麼，也不知道從哪幹起？上次兩位老師跟我們交流了一下，下面是他們的心得 給乙個專案 解決方案 問題分塊 任務明細 一開始並不是所有的問題都會想到，但是起碼要有乙個大體的框架在心中，然後細化模組，對每乙個功能進行細...
如何做專案
1，以業務規則為綱，而不是業務實體 2，在思考和設計業務規則的時候，以業務核心為綱，什麼是業務核心，定義為，當前你最關注的，當前最不確定的那一部分。所以我現在不喜歡領域驅動，我喜歡業務驅動 其實可能二者是一碼事 那麼我這裡所說的業務驅動要怎麼驅動法呢？就先以上面兩條為起頭，然後再來說，業務規則，以找...
磁碟如何做才能讓系統識別
看書那麼多，有時候用的地方想不起來，反省反省.對一塊未分割槽的空白盤，在windows磁碟管理上顯示是灰色的，要用軟體如diskgenius進行分割槽，然後更新分割槽表 要注意使用的是什麼格式，不懂多查查 看過linux的書，但是真正碰到行動硬碟識別不了這種狀況，我把以前的知識王的一干而將了 對於沒...