リファクタリングに付きまとうトレードオフ

「 「現物主義」に基づいたソフトウェア開発手法」に次のようなことが書かれている。

ここで大事なことは、Step1で作成した「50点のソフトウェア」は、すべて破棄することです。 すべて破棄したうえで、Step2でゼロから開発しなおします。 これは、Step1のコードは不細工かつ低品質であり、そのようなコードを混ぜると新しいコードも不細工で低品質になってしまうためです。汚いコードを直すなら、最初から書き直したほうがよい ― ソフトウェア開発でよく言われる格言の通りです。

全て破棄すると書かれているが、これはあまりにももったいない。XP や TDD の場合は、Step1 でもテストが作られているので、不細工かもしれないが決して低品質ではない。もちろん、汚いコードは最初から書き直した方がいい場合もあるが、それは一部であり全部ではない。汚くてもきちんと動いていればそれでいい。たとえバグだらけでほとんど全部を書き直すべきと思えるコードでも、8割程度のコードは再利用できるだろう。(パレートの法則を適用すれば、8割のバグは2割のコードにあると言えるから)
それに、がんばってきれいに書き直したとしても、ある程度の期間が経過すればプログラミングスキルが向上し、きれいに書き直したものが汚く見えてくるものだ。(もし、過去に自分が書いたコードを見て恥ずかしいと思わない人は、プログラマをやめた方が良い。)
コードを書き直す(リファクタリングする)のは、機能追加やバグ検出などにより以前のコードに手を入れなければならないと分かったとき(条件1)、より良いコードに改善できると思えたならば(条件2)、そのときが書き直すタイミングだと言える。
リファクタリングには、リファクタリングにかかるコストとリファクタリングすることによるメリットのトレードオフの問題が常に付きまとう。