いつリファクタリングをすべきか

準備のためのリファクタリング

IMO：2つの帽子の話だ！

理解のためのリファクタリング

開発者が理解しながら、コード側も変える

詳細をずっと覚えておくのは困難

コードの中に理解を移動してしまえば、それは長きにわたって保存できますし、仲間の開発者にも伝わるようになります。(Kindle 版)

ゴミ拾いのためのリファクタリング

（IMO：テストコードは必要と思われる）

機に応じたリファクタリング

私は、あらかじめリファクタリング用に時間を確保しておくのではなく、機能の追加や、バグの修正の最中にリファクタリングを行います。(Kindle の位置No.1538-1539)

リファクタリングはプログラミングと不可分

if文を書くための時間を計画するか？ーしない

すばらしいコードもまた、多くのリファクタリングを必要とします。(Kindle の位置No.1548)

トレードオフ

変更の要求が来たら、まず変更が容易になるようにする（注：これは難しいかも）。それから容易になった変更を行う。(Kindle の位置No.1552-1553)

計画されたリファクタリングの話は、比較的まれと考えたほうが良いでしょう。ほとんどのリファクタリングの活動は目立たず、機に応じて行われます。(Kindle の位置No.1565-1566)

長期のリファクタリングはオススメしない

直近の2～3週間で問題を徐々に解決していくことにチームで合意するというのが有効なやり方です。(Kindle の位置No.1579-1580)

コードレビュー時のリファクタリング

私の経験では、コードの作者と並んで一対一となりコードをレビューしてリファクタリングも行う形が、最もうまくいきます。(Kindle の位置No.1605-1607)

＝ペア・プログラミング

リファクタリングを避けるとき

混沌としたコードを見かけたとしても、修正の必要がなければ、リファクタリングする必要もありません。(Kindle の位置No.1630-1631)

どのようにして動いているのか理解しなければならない状況になったときに初めて、リファクタリングの利点が出てくる (Kindle の位置No.1632-1633)