いつでもなんでもリファクタリングをすればよいというものではない。例えば、納期がぎりぎりに迫った場合などにリファクタリングを行っている余裕はないし、リファクタリングは将来に備えて行うものであるため、そのリファクタリングが実を結ぶ可能性は少ない。また、リファクタリングといえども、やはりプログラミングであるので、常にミスをする危険性は拭えない。
『リファクタリング』では、機能追加するときと、リファクタリングするときをはっきり区別することを勧めている（このことを比喩して「実装の帽子をリファクタリングの帽子に被りなおす」という）。リファクタリングしてばかりいては開発は進まないし、どのリファクタリングをするべきかはある程度開発が進まないと分からない。リファクタリングを開始するタイミングとして、コードに「不吉なにおい」を感じ始めたら、と提案している。これは似たようなコードの重複や、長すぎるメソッド、ひとつの変更の度に複数のクラスが影響を受ける、などの症状が見つかったときを指している。また、機能追加の前、コードレビュー時、バグフィックス時にもリファクタリングを勧めている。
テストの重要性.
リファクタリングの課題.
リファクタリングには、いくつか課題が存在する。例えば、データベースに変更を加える場合、データを移行する必要がある。たしかに、中間層を挟むことで影響を緩和できるが、やはり時間が掛かることは否定できない。また、リファクタリングでは、従来のようにカプセル化されたクラス内だけでなく、インタフェースも変更することがある。それが広く公開されたインタフェースである場合、新しいインタフェースと古いインタフェースを両方保守しなければならない。また、修正するコードがあまりに酷い場合、新たに書き直したほうが早いこともある。リファクタリングは発展途上の技術であるため、これら以外の課題が見つかる可能性がある。
歴史.
博士論文は、機能的かつ手続的プログラムのリファクタリングに関する最初の主な学術的な仕事であり、そしてすべてこれらの理論と機械はずっとシステムとして可能だったけれども。すべてこれらの文献はリファクタリングの主だった手法の目録を与える；リファクタリングの方法はどのように方法を適用するか、そしていつその方法を適用すべきか（あるいはすべきでないか）について指し示す、記述を持っている。