不要になったコードの削除

フロントエンドでの「この画面が不要になった」、バックエンドでの「このAPIが不要になった」といったケースでの、不要になったコードの削除について、考えをまとめてみた。

なぜ削除するのか

• なぜ残っているのかという疑問が発生するのを防ぐため。
• リファクタするときの邪魔にならないように。
• 全文検索で無駄にヒットするのを防ぐため。
• ビルド、テストの時間を短縮するため。
• 総じて言えばメンテナンスコスト削減。

色々理由を挙げてみたなかで、疑問を防ぐことを1番目に持ってきた。この理由は、他の要素と違って我慢や努力で解決できないからだ。

会話例:

• 「icon_plus.png ってもう使ってない？」
• 「使ってなさそうだな。ファイル名で検索してもヒットしない」
• 「じゃぁなんで残ってるんだろう」
• 「tig -Sicon_plus してみたけど、このコミットでの削除漏れかなぁ。うーん、たぶん消して大丈夫でしょう」

icon_plus.png を使わなくなった時点で消していれば、このやり取り自体が発生しなかったはずだ。スムーズに、気持ちよく仕事をするために、不要なコードはなるべく削除されていたほうがいい。

根から断つか、葉から断つか

根とは、フロントエンド (SPA) やバックエンドではルーティング部分だと思ってもらえればいい。逆に、葉は、フロントエンドの場合はその画面でしか使ってなかった画像、バックエンドの場合はその API でしか使ってなかったユーティリティ関数といったものだ。

根から断つか、葉から断つか。多くの場合、削除しようと思いたつきっかけが根にあるので、できる限り根から断つほうがいいと考えている。このユーティリティ関数を消したい。と思い立った場合は、それを根とみなす。

根にハサミを入れる

この根を断つ、と決めたら、まずそこにハサミを入れる。ルーティング情報を削除するといった具合で。URL /hoge に対してこの画面、この関数といった連携を断つ。もし、その画面や関数が一気に消せるようなボリュームじゃない感じがするなら、そこに「TODO: これはもう使ってないので、あとで消します」のようにコメントしておく。そして、ここでコミットして一息入れる。

このコメントをさぼると、いろいろあって削除しきれなかったときに「なぜ残っているのかという疑問」が発生してしまう。このコメントとルーティングの削除が同じコミットに入っていれば、後から経緯を調べるのは格段に楽になるはずだ。

少しずつ削除していく

あとは、根を断って浮いた部分を削除していくだけだ。削除するときも、根の方から削除していくのがやりやすい事が多い。葉が明らかに見えていて、削除も簡単なら、そっちから削除してもいい。

根の方から少しずつ削除していくと、最終的に葉まで至る。フロントエンドなら、不要となったCSS、画像など。また、葉と言えるボリュームではないけど、その画面だけで使っていたライブラリなんかも末端の葉だ。バックエンドの場合は、データベースのテーブルやカラムが葉となりうる。こういった末端の葉ほど、削除し忘れたときに「なんで残ってるの？」という疑問が発生しやすいので、できるだけ削除する。

もしかしたら、削除しないほうがよさそうなコードなどがあるかもしれない。その場合は、「これはもう使ってないけど、近いうちに使う予定があるから残しておく」といった、削除してない理由を記録して、後日疑問が出ないようにする。とにかく「なぜ残っているのかという疑問」を残さないようにする。「なぜ」を調べるコストは高い。

PR やコミットの粒度

できれば、最初のハサミを入れた時点で PR にしておくといいと思う。というのも、万が一、その画面や API が使われていて、戻さなければならなくなった場合に、ハサミを入れただけなら復旧が簡単だからだ。その先についても、復旧のことを考えて PR の粒度を考えるといいだろう。

コミットの粒度は、それなりに小さめに留めておいたほうがいいように思う。よほどのことがない限りい、小さくて困ることはない。1コミットにつき、多くて数ファイル、数百行か。とはいえ、できるだけ意味のある単位、コンパイルが通る単位でまとめたほうがいいので、場合によっては数十ファイルなどに及ぶこともあるだろう。そのあたりはいい感じにしよう。

コミットを小さくするのと同じ理由で、PR を小さくしてもいいのでは？とも考えられるが、PR を小さくする場合は、その PR の先に控えている作業を記録したり記憶したりしておかないと、削除漏れが発生しやすいので注意が必要だ（理由はちょっと長くなりそうなので割愛）。