英文原文：Refactoring -- Not on the backlog!
對于如何進行代碼重構，一直有着很多種說法。很多人都認為應該将重構代碼放在backlog裡。但是其實，這并不是一個理想的方法。
在項目剛剛開始的時候，你的代碼很幹淨。
即使有的時候需要小小的繞一下路，但是這個時候我們可以輕松、平穩的添加功能。這個階段一般都不會出現問題，而且由于我們比較着急，是以即使出現了一些小問題，我們也不會注意到。
然而，随着項目做的時間變長，這些小的問題就會累計起來。這就是人們所說的“技術債務”。其本質，就是并不算特别好的代碼，但是這個時候其問題還沒有完全顯現出來。
但是，随着我們一直添加新功能，這些問題就會逐漸顯現出來，我們不得不小心翼翼的繞開他們。
不可避免的，我們的開發速度會被拖慢。但是為了追求速度，我們開始變得越來越不小心，不久之後，問題也會越來越多。
這些問題會像積木一樣累計起來，層層疊疊，讓我們的開發速度變得更慢。雖然我們終于意識到了問題的存在，但是沒有時間徹底解決它。我們隻能繼續小心翼翼的繞開它們。
很快，我們會發現半數以上的代碼都與那些小問題有交集，它們無時無刻不在影響我們的開發速度。直到有一天，你發現自己沒法繼續繞開它們。
不得不做點事情了。我們必須要進行複雜的代碼重構，讓我們重新獲得幹淨的代碼。你不得不向上級申請時間進行代碼重構。其實這種工作方式并不好，我們花時間去填自己以前挖的坑。而且有的時候，公司并沒有讓你去重構代碼的時間。
即使公司給你時間了，你也很難很好的對代碼進行重構。要知道，重構代碼所需的時間，往往要遠高于你的預期。如果這些紛亂的代碼是你用了10周寫出來的，那麼你很難再用10周的時間對它們進行重構。
由此可見，這種代碼重構的方式并不好。那麼我們應該怎麼做呢？
很簡單，那就是每遇到一個問題，就馬上解決它，而不是選擇繞過它。完善目前正在使用的代碼，那些還沒有遇到的問題，就先不要理它。在目前前進的道路上，清除所有障礙，以後你肯定還會再一次走這條路，下次來到這裡的時候你會發現路上不再有障礙。軟體開發就是這樣。
或許解決這個問題需要你多花一點時間。但是從長遠來看，它會幫你節省下更多的時間。
在添加新功能的時候，我們就先清理這個功能所需要的代碼。花一點時間，用滴水穿石的方法逐漸清理代碼，随着時間的推移，我們的代碼就會越來越幹淨，開發速度也會越來越快。
一段時間之後，你會發現之前所有的技術債務都不見了，所有的坑都被填平了。這種循序漸進的代碼重構的好處開始顯現，程式設計的速度明顯加快