最近接到乙個任務，大致就是在一段**裡多加乙個else if 來做些事情。考慮到後面有可能還會加條件，想重構部分**弄成策略的。做了大半後發現業務邏輯比我想象的要複雜，按這個思路重構完可能會出現意外的bug，或者重構失敗。於是我打算還是加else if來解決。
這件事情的教訓就是：
在非常了解一段邏輯之後再考慮重構。貿然重構可能會產生錯誤估計及更多意外效果。
先做完任務，多閱讀下這塊邏輯，更了解些後看看那有沒有機會重新重構下吧。
這裡記錄下此時的想法
重構優化的思考
重構的時機 什麼時候重構？重構絕非沒事的時候改動下 讓 更美觀，這個意義真的不大，太浪費精力了。當發現以前書寫的 不滿足目前的功能需求時，那麼可以考慮重構 當以前的 不滿足目前的效能要求時，需要重構 甚至於重寫，重寫要慎重 當可預見的未來裡，可能會出現功能效能瓶頸時，需要重構。總而言之，沒有明確的有...
關於重構的思考
目前組內專案的 數量已經到了1.7w行了，架構或者說設計已經逐漸顯示出了疲態，有些功能我們已經超出了我們之前的設計範圍。我們當前的困境，我們在新增部分新功能的時候已經開始強行相容，用一些很變扭的操作實現。同時也已經埋下了很多坑。我們應該進行重構的操作，把當前看到的問題整理調並整我們的設計。這週我進行...
分析 思考 重構
在平時的開發中，我們總是習慣於使用過程化的思維方式來編寫 沒有通過開發高內聚的方法，來結構化自己的思維，從而消除邏輯重複，邏輯復用不僅僅是指在乙個平面內的邏輯復用，更應該是一種結構化的邏輯復用。下面，我用平時開發過程中乙個重構的過程，來做乙個描述。假設，現在有三個類，如下圖所示 在這三個class中...