古いコードに向き合い、未来に何を遺すか

ここ数年は仕事で「最後のコミットが10年前」みたいなコードを触ることが多く、古いコードに対してどのように向き合うかと同時に、 コードを長く維持していく上でどのいう振る舞いをするとよいかを考えることが多くなった。 年末なので、自分が特に最近意識していることをを紹介する。

要らないコードはさっさと消す

年末といえば大掃除、ということで年末らしい話題。普段仕事をしている中で「これは使われてなさそうだけど、消していいかわからないな」とか、「これは今は使わなくなったけど、残しておいたらあとで使うかもしれないし残しておく」という場面がある。 消すためにもちょっと調べないといけないし、消すより残しておいたほうが安全だし、面倒なので残しておくか・・・ということをやったことはないだろうか。僕はある。 しかし必要のないコードなのであればさっさと消したほうがよい。現代だと大抵gitなりなんなりで管理されているのだから、必要だったら過去コミットから拾ったらいい。

事情を知っているメンバーがいるうちはいいが、気がついたらメンバー全員が入れ替わっているということもある。もしかしたら2周くらいしてることもあるかもしれない。 そうなった時に事情を知る人がいなくなり、あるいは残っているけど忘れてしまったということが起こり、より消しにくくなって、気がついたら最初に想像していた以上にコードが増えてしまうということもあるだろう。 コード量の多いリポジトリは新メンバーへの導入の心理的なハードルが高くなる。部屋を片付けてくださいと言われ、物が少ない部屋と、仮に整理されていたとしても物が多い部屋だと、後者に感じると思う。

消すことで得られるものは大きい。消すことでコードの見通しがよくなるし、全体のボリュームをできるだけ小さく保つ方向に力が働いて、より把握しやすくなる。 しかし使わなくなったと判断したその場で消すのが一番簡単だと思う。消していきましょう。

コミットログには変更の理由を残す

VCSで管理されているコードに対してなんらか修正したあとに「fix」みたいなログでコミットすることないですか。僕も昔はそういうことを結構やっていた。 しかし10年後にそういうログが残ったコミットを見たら「修正したのはわかるんよ」ってツッコミたくなると思う。ログを追っているのは変更した理由を知りたいからで、10年後にfixとだけ書いてあったらものすごくがっかりするだろう。 よほど単純な修正じゃない限り、ちゃんと理由を残すとすると、どの順番で修正するかというのを先に考えるとか、どういう粒度でコミットするとかを最初に検討することになり、結果としてコードの品質も上がるだろうと思う。

とはいえ試行錯誤の過程で雑なコミットが増える、みたいなことも普通に起こる。gitを使っているなら後から改めて修正することもできる。自分では後で全部の修正を見返して、コミットをまとめたり入れ替えたり、みたいなことをやっている。 あとうっかり同じファイルに対して複数の修正を一つのコミットに含めそうになってしまう場合とかはgit add -pでコミットする範囲を選んでコミットするとかして、粒度を調整するとよい。

【余談】サービスの寿命よりもチームの人員の入れ替わりのほうが早いことがある

これは振る舞いの話ではないけど、サービスが未来永劫同じメンバーで開発・運用され続けるとは限らない。メンバーが入ってくることもあるし、何らかの事情でいなくなることもあるだろう。 気がついたらメンバーが全員入れ替わっているということも起こる。当然引継ぎはされていくだろう。常に100%完璧に引継ぎされているのであれば問題ない。実際には良くて8割〜9割くらいで、残りはコードや残されたドキュメントから読み取ることになる。そうして何年かすると、考古学のように様々な資料から過去の経緯を推察する、ということになる。長く続けばそうなっていくのは仕方ないと思う。

だからこそ、ドキュメントにしてもコミットログにしても、あるいはコードのコメントにしても、今いる人や直近でチームに入ってくるだろう人向けにはもちろん、 今のチームメンバーが関わることがない未来のチームに対して残す、という意識で書くのが良いと思う。方法論ではなく意識の話になってしまうが、これは明日、つまり新年からでもできる。

ここまで技術的な話というよりは振る舞いの話に終始したけど、自分が大事だと考えている振る舞いについて紹介した。こんなの当然でしょという人たちはそのまま継続してほしいし、 もしもこんなこと意識してなかったという人がいれば参考にしてほしい。ここで紹介した振る舞いでもしかしたら10年後の誰かを助けることができるかもしれない。

ということで

無理やりエンディングって感じだけど、このエントリははてなエンジニア Advent Calendar 2023 - Hatena Developer Blogの31日目のエントリだったのでした。ちなみに昨日はid:stefafafanのエンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の fa は3つですというエントリでした。

2023年の大晦日だから今日で最後かと思ったけど、もうちっとだけ続くんじゃということで 2024年になってももう少し続くようです。明日はid:nakatakiさんとのこと。お楽しみに。

ぼく個人の挨拶としては「来年もよろしくお願いします」ということで。