重構這件小事
摘要：
服務端的技術重構，對於很多開發人員來說並不陌生。這裡，我們稱大的技改叫做重構。自加入我站以來，也是主導或經歷過比較大的技術重構，簡單說有兩類：
從php到golang的重構
兩年累積的golang程式碼的重構
其實重構的動機無非就這麼兩類
語言棧的...
服務端的技術重構，對於很多開發人員來說並不陌生。這裡，我們稱大的技改叫做重構。自加入我站以來，也是主導或經歷過比較大的技術重構，簡單說有兩類：
- 從php到golang的重構
- 兩年累積的golang程式碼的重構
其實重構的動機無非就這麼兩類
- 語言棧的遷移或統一 算是重寫了
- 因業務發展，老的架構不滿足了，包括穩定性、效能上的、擴充套件性上的等等
那麼，到底我們的專案，是否需要重構了呢？
重構本身屬於技改，一般情況下產品和老闆不一定是非常關心的，甚至有時候是“反對”的。短期來看，重構對業務迭代速度的影響、重構中或者重構後系統的穩定性也未知。那麼，我們要不要重構呢？
我們要會算賬！重構的收益是什麼？成本是什麼？風險是什麼？想清楚這3個問題再決定！
*收益能否量化！ 比如效能資料提升多少？耗時的減少是直接改善使用者體驗的。頻寬是否減少百分多少？頻寬的成本往往是技術成本大頭。還有如CPU的優化，對於大的業務叢集也是可觀的收益。
*成本和風險 成本和風險往往是相關的。這裡主要指技改的額外開發成本對業務迭代的風險影響 ，以及過程中的對系統穩定性 的風險影響。
其實，還有很多隱形收益是特別需要開發人員關注的 ，如程式碼規範和質量的優化 對後期開發效率和易維護性的影響，平臺化改造 使得整個系統的擴充套件性、業務解耦的改善，等等。那麼我簡單舉例下近期推進的go業務系統改造。
兩個月前我開始制定評論等社群系統的重構roadmap。這些系統在兩年前是從我站的大雜燴系統拆分出來的，經歷了非常多的功能堆積、多業務方接入，存在非常多的系統性問題。方案包括核心幾點：
- 服務拆分 比如單體拆成閘道器和service服務。閘道器邏輯包括對外介面、埋點上報、防刷限流、資料聚合、業務配置等，無狀態。service服務側重基礎功能邏輯、DB和快取操作，基本上做到和功能迭代、業務方解耦。這樣閘道器的頻繁發版帶來的心智負擔就很少了。
- 平臺化改造 比如系統不斷接入了很多業務方，那麼我們要支援平臺功能的配置化。 同時，要儘量和業務方邏輯解耦。
- 效能優化 這點不細說了，基本上做核心介面效能分析 就好了，見golang下的併發、並行優化
- 穩定性 穩定性的影響因素很多，架構的合理、容災容錯方案、依賴方系統的穩定性等等。
- 通用邏輯規範寫法 基礎庫越強大，業務程式碼越簡單。還有比如job常用的記憶體merge、並行呼叫框架等等......
- 編碼質量和UT覆蓋 高內聚、低耦合，比如api協議和interface的設計啊、類的設計啊、函式的設計啊、命名啊、狀態屬性的寫收斂、太多地方了
重構也許很累，但是本身是思考的過程和提升的過程，重構的方案也特別重要。敢於重構，勇於突破。
最後拋一個我們重構過程中的小技巧，新老系統怎麼切換？我們會同時並行請求新老介面，並做結果diff。當結果完全一致才考慮返回新介面資料。