前一段日子開發節奏太快，需要調整業務的時候越來越麻煩，所以最近看起了《大話重構》，想為優化程式碼提供一些思路。這本書提供的思路其實和業務非常貼近，除非挖新坑，否則相對於大規模的推翻重來，小步迭代顯然更優秀，曾經避開的坑都藏在細節裡，推翻重來的時候往往最容易忽視這些細節，常言道不要一口吃個胖子就是這個道理。

優化的目標就是第一是正確性，第二是透明無感，第三是可擴充套件。其實從實際例子看前端無感未必是最好的，當邏輯合併優於無感調整時，某次迭代的時候能同協商前端一起修改是最好不過的了。例如前期業務不具體為了規避風險，同類介面提供了兩套，隨著業務漸漸成型，同類介面合併成一套，既利於前端分享，也利於頁面模型上下文的傳遞。

優化程式碼的思路和學習一本書其實非常類似，學習一本書先讀厚再讀薄，一遍遍才整理出：

首先，優化通讀程式碼，其次根據程式碼邏輯將一個功能的塊註釋（說明這些是可以抽象出去的）。這是優化的第一步，好多時候優化無從下手，不要小看整理程式碼邏輯，要邊讀邊思考重複率，是抽象成私有工具方法還是抽象成類方法。通讀既給優化開了口，也給梳理思路的過程，給後續優化提出了挑戰。

然後，將塊註釋下的小程式碼片抽象成私有方法。酌情再抽象成類方法、系統方法。

最後，根據具體業務調整呼叫邏輯。重構不是一次就能完成的，每重構一次都要驗證其正確性，寫寫JUnit和自動化測試指令碼。單元測試完系統測，系統測試完極限測。

每次重構都是SOLID的取捨，講真，多調程式碼多思考比看一百本書管用。