Tidy First? ―個人で実践する経験主義的ソフトウェア設計

2章デッドコード

　

消そう。以上。実行されないコードは消すだけだ。

デッドコードを消すことに強い抵抗を感じる人もいるだろう。誰かが時間と労力をかけて書き、それに対して組織がお金を払った。そんなコードが残っているのだ。無駄金にしないためには、またコードが呼び出されるようにすればよいだけだ。それに、消したコードが将来必要になったら、消したことを後悔するかもしれない。

このなかにどれだけの認知バイアスがあるか探してみてほしい。整頓好きなあなたへのエクササイズだ。

デッドコードを特定するのは簡単だ。だが、リフレクションが多用されているようなときには少し難しい。コードが使われていなさそうだと当たりをつけたら、整頓する前に使用状況のログを取ってみよう。本番環境に載せて、確信が持てるまで待つのだ。

「でも、もしあとで必要になったら？」と考えるだろう。そのためのバージョン管理なのだ。実際には何も削除していない。今は見る必要がないというだけだ。コードがもし（これは条件式の長い羅列だ）、1）たくさんある、かつ、2）今は使われていない、かつ、3）将来使いたい、かつ、4）書いた当初と同じ使い方をする、かつ、5）今も動作する、ならば、元に戻せる。そうでなければ、書き直したほうが良いものになる。しかし、最悪なことになったとしても、いつでも元に戻せる。

いつものように、少しずつコードを削除しながら整頓しよう。そうすれば、間違いに気づいても、比較的簡単に変更を元に戻せるだろう（28章参照）。「少しずつ」の尺度は認知的なものであって、コード行数ではない。条件式（たとえば真になることがわかっている場合）の節かもしれないし、ルーチン、ファイル、ディレクトリかもしれない。