TL;DR
- すべてのコードは潜在的にレガシーコードである
- 重要なのは、読みやすく理解しやすいコードを書くこと
レガシーコードとは何か
「レガシー（legacy）」という言葉は本来、「誰かが残した財産」を意味します。プログラミングの文脈では、以下のように解釈できると考えています：
- 誰かが過去に書いたコード
- 時間の経過とともに理解が難しくなるコード
- 特定の開発者に依存するコード
重要な洞察：自己忘却によるレガシー化
興味深いのは、同じ開発者が書いたコードでさえ、時間が経過すると理解が困難になり、自分にとってもレガシーコードになる という点です。数ヶ月後に自分のコードを見返したとき、その意図や実装の詳細を忘れていることがよくあります。
What is the definition of "legacy code"? - Stack Overflow などにも、書いた瞬間にレガシーコードになるという意見が見られます。
なぜ「レガシーコード」という言葉を使うのか
この用語には謙虚さと自己改善への意志が込められていると、私は考えます：
- 「レガシー」という言葉は通常、否定的なニュアンスを持つ
- 同時に、自分のコードが完璧でないことを率直に認める自己省察の表現でもある
- この言葉を意識的に使うことで、常に改善を心がける謙虚な姿勢を示せる
レガシーコードを防ぐための実践的アプローチ
コードの持続可能性を高めるために、以下の簡単な習慣を心がけましょう：
1. インラインコメント
最小限でも、コードの意図や複雑な部分を簡潔に説明するコメントを追加します。
よくPRのコメントに説明を書くことがありますが、これはその場限りの情報でありコード自体の読みやすさには寄与していないため、注意をしてください。インラインコメントやドキュメントの追加が望ましいです。
2. 型の明示
変数や関数の型を明確にすることで、コードの可読性と理解性を向上させます。
3. 軽量なドキュメンテーション
ほんの少しでよいのでコードの背景や目的を説明するドキュメントを追加します。
Architecture Decision Record (ADR) などの形式でドキュメントを残すことも有効ですが、毎回完璧なドキュメントを書くことは難しいため、実装方針の検討背景がわかる程度であると望ましいと考えます。
将来的に参入してきたメンバーが、なぜそのような実装に至ったのかを追うことができれば、過去の試行錯誤に新しい技術を適応させることができるためです。ドキュメントがない場合は、新規の技術におわれて、過去の重要な判断を見逃されてしまう可能性があります。
心構え：継続的な改善
「完璧な」コードは存在しません。重要なのは、常に読みやすさと理解のしやすさを意識することです。
まとめ
任意のコードは、例外なく時間の経過につれてレガシーコードになります。
重要なのは、どのようなレガシーコードを残せるかということです。
経験談
私自身も、過去に書いたコードを見返すと、理解が難しい部分が多々あります。そのため、最近は上記のような習慣を意識してコードを書くようにしています。これにより、自分自身が将来の自分を助けることができるだけでなく、他のメンバーにとってもコードの理解が容易になると感じています。
ただ、他の方から過去の実装に対して問い合わせがある場面もあり、そのたびに自分自身のドキュメントの不備や考慮漏れなどを感じます。ただ、問い合わされたタイミングで自分が忘れていても、ある程度のインラインコメントを用意していたため、自分自身の実装がどうなっていたか思い出すことができ、その場で問い合わせを頂いた方に回答することができました。
完璧な状態のレガシーコードを作ることは不可能だと感じていますが、少しでも読みやすく理解しやすいコードを書くことが大切だと実感しています。