重構的時機：什麼時候重構？
重構絕非沒事的時候改動下**讓**更美觀，這個意義真的不大，太浪費精力了。當發現以前書寫的**不滿足目前的功能需求時，那麼可以考慮重構；當以前的**不滿足目前的效能要求時，需要重構（甚至於重寫，重寫要慎重）；當可預見的未來裡，可能會出現功能效能瓶頸時，需要重構。總而言之，沒有明確的有價值的目的期望，那還是let it alone比較好。
重構的方式：怎樣開始重構？
不是說拿到專案之後立馬開始改寫**，按照自己的意願完成**的重構；在重構之前要有足夠的分析工作，確定你要重構的**能對你的目標起到正向促進作用，重構並不一定能保證你改善**的效能（你需要確立一些優化點-----這些點可能能改進效能），然後去執行重構工作。切記，完全不需要改進所有的**，真正決定關鍵效能的**一般絕不會超過30%，分析好關鍵點之後進行優化重構工作往往能起到事半功倍的作用。
重構的結果：怎麼樣？
重構的結果未必會達到你的期望值，所以如果不行就改回原來狀態，再去分析別的關鍵點，重構一定要通觀全域性，確立疑似點，而後再去重構改寫，最糟糕的情況只能是重新設計了。
ps:重構可以讓你讀懂**更容易；重構可以讓**效費比更高;重構能做很多很多，但重構也要求很多很多，要有足夠的經驗，要有足夠的分析能力，要有足夠的專案認知能力。在重構的路上，我還是徹頭徹尾的大菜鳥，加油哈。
關於重構的思考
目前組內專案的 數量已經到了1.7w行了，架構或者說設計已經逐漸顯示出了疲態，有些功能我們已經超出了我們之前的設計範圍。我們當前的困境，我們在新增部分新功能的時候已經開始強行相容，用一些很變扭的操作實現。同時也已經埋下了很多坑。我們應該進行重構的操作，把當前看到的問題整理調並整我們的設計。這週我進行...
對於重構的思考
最近接到乙個任務，大致就是在一段 裡多加乙個else if 來做些事情。考慮到後面有可能還會加條件，想重構部分 弄成策略的。做了大半後發現業務邏輯比我想象的要複雜，按這個思路重構完可能會出現意外的bug，或者重構失敗。於是我打算還是加else if來解決。這件事情的教訓就是 在非常了解一段邏輯之後再...
分析 思考 重構
在平時的開發中，我們總是習慣於使用過程化的思維方式來編寫 沒有通過開發高內聚的方法，來結構化自己的思維，從而消除邏輯重複，邏輯復用不僅僅是指在乙個平面內的邏輯復用，更應該是一種結構化的邏輯復用。下面，我用平時開發過程中乙個重構的過程，來做乙個描述。假設，現在有三個類，如下圖所示 在這三個class中...