本文首發在 CSDN 微信（ID：CSDNNews）。
你的項目截止時間就要到了，你有一個緊急的 bug 需要修復，你的項目需要快速迭代輸出產品。
雖然你很忙，但是你也必須考慮你的未來：你現在引入的每一個 bug ， 都會給以後修復帶來巨大的時間成本。 因此我們不應該使用過時的API， 過時的版本以來，和一些老舊的做事方法。
所以，我們什麼時候來清理我們的代碼呢？
現在就做？
以後需求少了在做？
還是永遠不做？
在本篇文章中，我將告訴你該在什麼時間去用以下三種方法來清理你的代碼：
- 更新項目依賴和廢棄的API
- 重構不合適的抽象設計
- 編碼規範和日常編程習慣等雜項清理
解決方法
原型設計
在工程構建之前，你會做一些技術調研，做一些原型設計（或者極限編程中的Spike解決方案），但你不會長期保留使用這些代碼，你僅僅是使用這些代碼來驗證是否能解決問題。考慮到你有可能會廢棄掉這些代碼，更新和規範沒有什麼需要值得特別注意的事項。如果你也想嘗試理解學習那些已經存在的API, 你也不需要對代碼進行重構。
但是，如果你是想通過原型設計找到更好的抽象方式，你就必須進行大量的重構了。
最佳實踐:
- 更新： 不需要處理
- 重構： 如果你需要找到更好的架構方式，你就需要重構，反之，你就不用在意重構的問題。
- 雜項清理：不需要處理
新項目
如果你正在着手搭建一個全新的項目，你的任何一個決定都會對以後帶來很大的維護成本。
當然，這也是一個機會，讓你可以使用最新的框架，最佳的解決方案，最好的編程規範和最好的架構。雖然你不一定能做到完美，但是你可以使它儘可能的接近完美。
最佳實踐：
- 更新: 從現在開始
- 重構：從現在開始
- 雜項清理: 從現在開始
緊急的bug修復
在這個時候，你需要快速爲用戶修改 bug ，如果你看到了問題需要解決，但是這個問題和當前需要修復的bug無關，我建議你暫時不要動它，等 bug 修復結束了在來處理它。
有些時候，bugfix 有兩層含義: 一次是快速解決問題，另一次是你需要讓代碼更整潔。
最佳實踐:
- 更新：稍後
- 重構： 稍後
- 雜項清理: 稍後
新功能開發中或者不緊急的bug修復
當你有一個正常迭代開發的一個項目，不管你是在做新功能開發，還是bug修復，這個時間是你做代碼清理的最佳時機。
在這個時候，你並不需要修復所有你接觸到的代碼，你需要做的是整理你處理中的代碼，並且使你的代碼庫更加的整潔。詳情參考<Refactoring – Not on the backlog!>
最佳實踐：
- 更新：立即更新你用到的代碼
- 重構：立即重構你用到的代碼
- 雜項清理： 在你用到的代碼中，立即使用新的代碼規範等
項目維護階段
當你的項目已經開發完成：沒有什麼新的開發任務的時候，經常幾個月纔有一些給菜單多加一個選項等這種小的需求修改。
現階段，你的目標是做少量的修改，讓項目穩定運行。重構和雜項清理在現階段是不必要的，但是你項目需要你及時更新一些框架庫的依賴 —— 某些框架庫不在提供服務，或者有安全更新。經常更新依賴顯然要比5年才更新一次容易得多。
所以不管你是不是因爲有bug要修復，你都應該及時的去更新你的依賴項 —— 理想情況下，長期發佈更新，以減少對API使用的更新需求。
最佳實踐：
- 更新：現在更新，並且長期發佈版本支持
- 重構：不需要
- 雜項清理： 不需要
現在與未來的平衡
軟件開發是一個持續的過程，不是做完就沒事了。現在着手去清理代碼，將會爲你以後節省時間，儘管你現在趕項目的截止時間，現在着手去做也比放在以後多花幾周時間去做要好。
本文只是做一個開篇，與任何其它方法一樣，也都有不適用的時候，所以，你需要根據你項目中的實際情況和目標來做一些調整。
原文地址: https://codewithoutrules.com/2018/11/02/when-clean-up-your-code/
譯者：羅昭成
傳送門
歡迎關注我的公衆號，一起交流技術事。
