目前組內專案的**數量已經到了1.7w行了，架構或者說設計已經逐漸顯示出了疲態，有些功能我們已經超出了我們之前的設計範圍。我們當前的困境，我們在新增部分新功能的時候已經開始強行相容，用一些很變扭的操作實現。同時也已經埋下了很多坑。我們應該進行重構的操作，把當前看到的問題整理調並整我們的設計。這週我進行了部分重構的，==目的在與解決相同的計算邏輯重複出現的，以及結果輸出和計算過程揉雜的問題。==在重構的過程中我發現我遇到了的問題主要是：
如何平衡需求時間跟重構時間。
重構能力不足，野心大能力小。
重構的目標性不夠明確。
缺乏完整的測試重構意味這有風險。
控制重構範圍，分階段，控制風險。
為了重構而重構
這週在完成上線之後我就雄心勃勃的想要重構重構，感覺上自己已經了解了問題可以進行一次完美的重構，但是實際上重構的過程中發現自己在很對問題的理解上還是存在這模凌兩可的狀態，導致我無法在設計上做抉擇。整體對cdn的業務理解不夠深刻故我停止了大範圍的重構操作，轉而思考我到底要解決什麼問題，我重構的目的到底是什麼，回想到在舊專案上的經驗，自己很多的重構的目的性都不強，可以描繪成是一種為了重構而重構的衝動。
從問題出發
只有在明確自己要解決的問題才會胸有成竹，因此我放棄了大而全的重構衝動，轉為解決具體的，目的明確的問題的重構方向。帶著明確問題重構的過程和結果都能按照預期進行輸出。
我們對重構的態度
在我看來我們對重構的態度分為：
從沒想過重構。
有想法但是沒有行動。
眼高手低，沒有著眼於解決問題，想要大而全的解決所有問題。
不得不承認重構是需要很強的綜合能力，在能力還不夠強的時候我們應該小步快進。必須要明確當前要解決的具體問題後，小範圍重構。隨著業務地了解跟技術進步慢慢就有了經驗跟信心。
最後我有幾個小tips關於重構。
不要把所有問題都留給重構的時候解決，寫**的時候就應該避免低階的錯誤。
勤用注釋@todo 在自己猶豫不決的時候暫且把問題擱置，後面及時優化
重構不是銀彈，業務決定架構，對業務理解更深，重構的範圍才能擴大。
多寫測試重構的時候你就知道到底有多有用了。
重構優化的思考
重構的時機 什麼時候重構？重構絕非沒事的時候改動下 讓 更美觀，這個意義真的不大，太浪費精力了。當發現以前書寫的 不滿足目前的功能需求時，那麼可以考慮重構 當以前的 不滿足目前的效能要求時，需要重構 甚至於重寫，重寫要慎重 當可預見的未來裡，可能會出現功能效能瓶頸時，需要重構。總而言之，沒有明確的有...
對於重構的思考
最近接到乙個任務，大致就是在一段 裡多加乙個else if 來做些事情。考慮到後面有可能還會加條件，想重構部分 弄成策略的。做了大半後發現業務邏輯比我想象的要複雜，按這個思路重構完可能會出現意外的bug，或者重構失敗。於是我打算還是加else if來解決。這件事情的教訓就是 在非常了解一段邏輯之後再...
分析 思考 重構
在平時的開發中，我們總是習慣於使用過程化的思維方式來編寫 沒有通過開發高內聚的方法，來結構化自己的思維，從而消除邏輯重複，邏輯復用不僅僅是指在乙個平面內的邏輯復用，更應該是一種結構化的邏輯復用。下面，我用平時開發過程中乙個重構的過程，來做乙個描述。假設，現在有三個類，如下圖所示 在這三個class中...