新しい会社の初出社日にリポジトリを受け取り、初めてコードを開いた瞬間を今でも鮮明に覚えています。
3,000行のファイル1つに、あらゆるロジックが絡み合っていました。思わずため息が出ました。
「いったい誰がこんなコードを書いたんだ…」
ところが数か月後、私の書いたコードを見る新人が、まったく同じ表情をしていました。そのとき、レガシーコードは誰か1人の責任ではないと気づきました。
結論から言うと、こうです。
レガシーコードが嫌われるのはコードが悪いからではなく、書かれた当時の文脈が失われているからです。
今日は、なぜレガシーコードがいつも責められるのか、そしてその前でどうすれば傷つかずに済むのか、私の経験をお話しします。
レガシーコードとは？ 古いコードとは違うのか
まず押さえておきたいのは、レガシーコードは単なる「古いコード」ではないということです。
私の経験では基準は1つです。テストがなく、変更するのが怖いコードです。
マイケル・フェザーズは著書『レガシーコード改善ガイド』で、レガシーコードを「テストのないコード」と定義しています。書かれてから1週間でも、テストがなく修正のたびに緊張するなら、それはレガシーです。
逆に、10年前のコードでもテストが充実していれば安心して修正できます。
つまり問題は年数ではありません。「ここを変えても他が壊れない」という確信があるかどうかです。
レガシーコードはなぜいつも嫌われるのか
理由を整理すると、大きく3つありました。
1. コードを書いた人が会社にいない
なぜそう書いたのか尋ねる相手がいません。コメントもドキュメントもなければ、残るのはコードと自分の想像力だけです。
2. 文脈が失われている
奇妙に絡み合ったコードには、たいてい事情があります。厳しい納期、無理な要件、特定のOSバージョンのバグ回避などです。
当時は最善でも、その事情はコードに残りません。結果だけが残るため、今見ると理解できないのです。
3. 他人のコードはもともとすべて奇妙に見える
正直、これが一番大きいです。自分のコードは流れを頭で把握していますが、他人のコードは最初から追う必要があります。
そのもどかしさが、「なぜこんな書き方をしたんだ」という言葉になるのです。
次のコードを見てみましょう。一見すると、なぜこんな条件があるのかと思う典型的なレガシーの痕跡です。
// なぜ 30を引くのか誰も知らない
if user.type == "B" && amount > 0 {
finalPrice = amount - 30 // 2019年のプロモーションの名残?
}この- 30が今も必要なのか、昔のイベントの名残なのかを知る術はありません。こうした1行が積み重なってレガシーになります。
では、レガシーコードにはどう向き合えばよいのか
見慣れないレガシーを前にすると「全部書き直そう」と思いがちですが、もっと良い道があります。
私が今守っている原則は3つです。
- むやみに書き直さない — 動いているコードには、これまで積み重ねてきた多くのバグ対応が組み込まれています。書き直せば、それを最初から経験することになります。
- 修正前にまずテストを書く — 現在の動作をテストで固定すれば、修正後に何が壊れたかすぐ分かります。
- なぜ修正したのか記録を残す — コミットメッセージやコメントに理由を書けば、次の人に恨まれる度合いを少し減らせます。
特に3つ目が重要だと感じます。今の自分のもどかしさを、未来の誰かに引き継がせない唯一の方法だからです。
結局、今日の新しいコードも明日のレガシー
6か月で気づいたことは、少し虚しいものでした。今、私が丁寧に書いているコードも、数年後には誰かに嫌われるレガシーになるのです。
それを認めると気持ちが楽になりました。完璧を目指すより、次の人が苦労しないよう配慮する方向へ舵を切ったのです。
今、見慣れないレガシーコードを前にため息をついているなら、それを書いた人もその日の最善を尽くしたのだと、少しだけ思い出してください。そして静かにテストから始めましょう。それが互いを傷つけにくい道なのだと思います。