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