文章首發於公眾號「陳樹義」及個人博客 shuyi.tech，歡迎關注訪問。
博主個人獨立站點開通啦！歡迎點擊訪問：https://shuyi.tech
驀然回首，我已經工作七年了。在這七年的時間里，做過了無數個項目，但要說大的重構，只有三個。第一個是在我工作三年時，重構公司的聊天 IM 系統。第二個是我在現在的這個公司，重構了整個業務線的業務架構。第三個是現在我正在做的，重構消息中台的技術架構。
IM 系統重構
2017 年的我，畢業三年了，但是從來沒有重構過一個系統，就連一個模塊也沒有。而剛好就在這個時候，公司考慮到原有聊天功能不太友好，決定對原有聊天功能進行重構。於是組件了一個項目組，有兩個架構師再加上我去做這個事情。
由於當時的我並不清楚如何設計一個 IM 系統，所以我分配到的是業務邏輯代碼梳理，而其他兩位同學則是進行架構設計，以及 IM 通信層面的代碼編寫。正是由於這樣的分工，讓我后面越做越難受。
這是一個積累了十年的功能系統，沉積了無數的業務邏輯，而且很多業務邏輯很多人也不清楚。當然了，單元測試肯定也是沒有的，測試用例肯定也是沒有的。在這樣的情況下，我只能自己厚着臉皮一點點地去擼代碼弄清楚業務邏輯。
后面回頭來看，這種方式真的是最低效率的方法。如果不到萬不得已，千萬別這么做。最好的方法是找一個人捋清整體思路，之后再一點點弄清細節。另外，最好的重構方式不是一開始就重寫，而是一個功能一個能地重寫，這樣才更加穩妥。
另外一個重要的點是向上溝通。很多時候我們都是按照上級的指令行事，但是卻不提出自己的想法和方案。但對於重構這件事情來講，如果不做好溝通，很可能會出大事。像這種大系統，功能眾多、細節復雜，一開始就應該和領導打上預防針，並且爭取分階段、分模塊開發，降低自己的風險。一般情況下，領導考慮到開發的風險，都會同意按照你的方案去做。如果領導執意要一次性做完，那你也盡到了自己的責任，后續出問題做不完，也不全是你一個人的問題了。
這個項目最終做一個多月才做完上線，主要的時間是在梳理業務邏輯上。在這過程中自己也一度快做不下去了，甚至做到后期有點抑郁了。現在回想來看，就是自己重構經驗不足，心態又不好導致的。
文章首發於公眾號「陳樹義」及個人博客 shuyi.tech，歡迎關注訪問。
業務線重構
熟悉的朋友都知道，我從唯品會出來后，就去了現在的公司。當時這塊業務是從別的部門交接過來的，我們算是從零開始去熟悉這塊業務。對比起上次的系統重構，這次的規模更大，直接是整個 CRM 業務線的重構。我作為技術 leader 則是參與組建了整個技術團隊，並主導設計、推動落地了整個 CRM 的系統架構。
CRM 系統看起來就是一個 B 端系統，一個管理后台有什么好做的嘛。一開始我也這么覺得，但慢慢深入了解之后發現：這個東西還是不簡單。經過一段時間的了解，我發現原有系統存在一些問題，例如：系統功能混在在一起，功能模塊之間沒有清晰的的划分；后台模塊耦合在一個項目中，沒有做合理的模塊拆分；等等。
經過一段時間對業務的深入了解，結合對業界公司解決方案的對比，我設計出了全新的業務架構圖。整個業務架構圖將系統功能分為了三大系統：消息管理平台（MMP）、營銷發送平台（MSP）、營銷分析平台（MAP)。
經過與技術總監、產品總監溝通，他們對這個方案感到很滿意，決定后續按照這個方案去推動。在整體產品、開發、測試團隊的一起努力下，我們經過了半年的時間，將原有的 PHP 與 Java 系統共存的業務項目，成功改造完成了上面所說的三大系統。
對比起兩年前的那次重構，這次重構是更大意義上的、業務架構層面的架構。 也是這次成功的系統重構經驗，讓我學會了如何從零開始去做一個業務，如何從零開始去重構一整個業務系統。后面有機會，我再寫一寫這塊的文章。
文章首發於公眾號「陳樹義」及個人博客 shuyi.tech，歡迎關注訪問。
消息中台重構
還記得前面說到的消息管理平台嗎？其實這個就是消息中台的前身。在這之前，消息管理平台只是負責發送小批量的消息（100條以下）。但隨着業務的發展，我們發現有很多系統也需要發送幾十萬、甚至幾百萬的數據。而在這之前，這個需求只有我們這塊業務有。而這塊業務實現則是我們單獨放在營銷發送平台實現，並沒有抽離出來作為中台服務。
經過與小伙伴們的討論，以及對未來業務發展的考慮，我們發現后續應該會有越來越多的系統需要用到這個功能，於是我們決定將原本在營銷發送平台的功能抽離出來，放入消息管理平台。而消息管理平台則作為消息中台，掌管所有與用戶通信的渠道，包括：郵件、短信、Push 等等。
雖然做架構決策很快，但是怎么去做調整，項目之間的眾多細節如何處理，卻是一個非常苦惱的問題。對於我來說，我擅長與抽象總結歸納，因此對於整體架構上游刃有余。但重構的具體實現，如何設計得更有擴展性，則更考驗程序員的代碼實現基本功。
目前這塊內容的重構還在進行，等到做得差不多之時，我再分享關於這塊內容的重構經驗。
總結
這篇文章分享了我工作七年來的三次重大重構經驗，也算是對我職業生涯里有關重構的一個總結。每一次重大的重構經驗，都讓我從中汲取養分，在下次重構時做得更好，讓我更加游刃有余。經歷過這么幾次重大的重構，我也發現了不少重構的經驗，這里簡單總結下。
第一，先了解業務再重構。 先把業務了解清楚，再去重構，不然這次重構很大可能是失敗的，並且會導致你提桶跑路。
第二，小步快跑。 無論如何，還是要保持小步快跑的方式，每次改動較少的地方，然后完成上線。而不要一次性改動太多的地方。
第三，注重溝通。 積極與領導溝通，讓他明白你當前的進度，必要時咨詢他的意見。切忌自己悶頭搞開發，最后別人都不知道你在做什么。
第四，給出自己的方案。 要有自己的思考，能給出自己的方案。對於領導不切實際的方案，要懂得提出自己的意見，引導領導按照自己的思路去做，從而按自己的節奏走。
第五，做好充分的測試。 單元測試是最基本的內容，一定要做好單元測試。對於無法做單元測試的，一定要讓測試同學做充分的功能測試。
好了，關於重構的分享，今天就聊到這兒。
謝謝大家的閱讀。如果文章對你有幫助，點個 「在看」 ，或者 分享到朋友圈 吧。