程序員，代碼清理有必要嗎？

【CSDN編者按】日常編程工作中，程序員經常面臨各種代碼bug。但是是否所有項目都適合清理重構？bug修復的手段又是否合理？本文的作者以原型設計、新項目、緊急bug修復、新功能開發、項目維護等各階段為例，分別給出了相應的解決方法，希望能對你有所幫助。

以下為譯文：

你的項目截止時間就要到了，你有一個緊急的 bug 需要修復，你的項目需要快速迭代輸出產品。

雖然你很忙，但是你也必須考慮你的未來：你現在引入的每一個 bug，都會給以後修復帶來巨大的時間成本。因此我們不應該使用過時的API、過時的版本依賴、或者一些老舊的做事方法。

所以，我們什麼時候來清理我們的代碼呢？

現在就做？

以後需求少了再做？

還是永遠不做？

本文，我將告訴你該在什麼時間去用以下三種方法來清理你的代碼：

更新項目依賴和廢棄的API；

重構不合適的抽象設計；

編碼規範和日常編程習慣等雜項清理。

解決方法

原型設計

在工程構建之前，你會做一些技術調研，做一些原型設計（或者極限編程中的Spike解決方案），但你不會長期保留使用這些代碼，你僅僅是使用這些代碼來驗證是否能解決問題。考慮到你有可能會廢棄掉這些代碼，更新和規範沒有什麼需要值得特別注意的事項。如果你也想嘗試理解學習那些已經存在的API，你也不需要對代碼進行重構。

但是，如果你是想通過原型設計找到更好的抽象方式，你就必須進行大量的重構了。

最佳實踐：

更新：不需要處理；

重構：如果你需要找到更好的架構方式，你就需要重構，反之，你就不用在意重構的問題；

雜項清理：不需要處理。

新項目

如果你正在著手搭建一個全新的項目，你的任何一個決定都會給以後帶來很大的維護成本。

當然，這也是一個機會，讓你可以使用最新的框架，最佳的解決方案，最好的編程規範和最好的架構。雖然你不一定能做到完美，但是你可以使它儘可能的接近完美。

最佳實踐：

更新：從現在開始；

重構：從現在開始；

雜項清理：從現在開始。

緊急的bug修復

在這個時候，你需要快速為用戶修改 bug。如果你看到了問題需要解決，但是這個問題和當前需要修復的bug無關，我建議你暫時不要動它，等 bug 修復結束了再來處理它。

有些時候，bugfix 有兩層含義: 一次是快速解決問題，另一次是你需要讓代碼更整潔。

最佳實踐：

更新：稍後；

重構：稍後；

雜項清理：稍後。

新功能開發中或者不緊急的bug修復

當你有一個正常迭代開發的一個項目，不管你是在做新功能開發，還是bug修復，這個時間是你做代碼清理的最佳時機。

在這個時候，你並不需要修復所有你接觸到的代碼，你需要做的是整理你處理中的代碼，並且使你的代碼庫更加的整潔。詳情參考https://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/。

最佳實踐：

更新：立即更新你用到的代碼；

重構：立即重構你用到的代碼；

雜項清理： 在你用到的代碼中，立即使用新的代碼規範等。

項目維護階段

當你的項目已經開發完成，沒有什麼新的開發任務的時候，經常幾個月才有一些給菜單多加一個選項等這種小的需求修改。

現階段，你的目標是做少量的修改，讓項目穩定運行。重構和雜項清理在現階段是不必要的，但是你項目需要你及時更新一些框架庫的依賴 —— 某些框架庫不在提供服務，或者有安全更新。經常更新依賴顯然要比5年才更新一次容易得多。

所以不管你是不是因為有bug要修復，你都應該及時的去更新你的依賴項 —— 理想情況下，長期發布更新，以減少對API使用的更新需求。

最佳實踐：

更新：現在更新，並且長期發布版本支持；

重構：不需要；

雜項清理： 不需要。

現在與未來的平衡

軟體開發是一個持續的過程，不是做完就沒事了。現在著手去清理代碼，將會為你以後節省時間，儘管你現在趕項目的截止時間，現在著手去做也比放在以後多花幾周時間去做要好。

本文只是做一個開篇，與任何其它方法一樣，也都有不適用的時候，所以，你需要根據你項目中的實際情況和目標來做一些調整。

原文: https://codewithoutrules.com/2018/11/02/when-clean-up-your-code/

譯者：羅昭成

責編：郭芮

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！