レガシーコード
古い建物の壁の中に張り巡らされた配管のようなもので、下手に触るとどこから水が漏れ出すかわからないコードです。
定義 昔に作られて今も使われているものの、古くて複雑すぎるために修正するのが怖いソフトウェアコードのことです。開発者のマイケル・フェザーズ（Michael Feathers）は「テストコードのないコード」をレガシーコードと定義しました。一見正常に動いているように見えても、時間が経つにつれて新機能の追加やバグ修正がどんどん難しくなっていきます。
なぜ手を入れるのが怖いのでしょうか？
築数十年の古い家をリノベーションしようと壁を剥がしたら、見慣れない電線がクモの巣のように絡み合っていて呆然とする姿を想像してみてください。レンガを1つ間違えて抜いたら、家全体が崩れてしまうかもしれません。
レガシーコードはまさにこのような状態です。最初にプログラムを作った人はすでに退職しており、仕様書（ドキュメント）もまともに残っていないことがよくあります。今この瞬間は動いていても、コードをたった1行修正しただけで全く関係のないはずの別の機能が突然停止してしまうリスクが高いのです。
そのため、開発者は問題が起きても根本的な修理を敬遠し、その場しのぎのパッチ（継ぎ接ぎコード）を当ててしまいがちです。こうした応急処置が繰り返されると、コードはますます手のつけられない怪物へと化してしまいます。
もう少し正確に言うと
単に書かれてから長い年月が経ったからといって、すべてがレガシーコードになるわけではありません。10年前に書かれたコードでも、構造がきれいでドキュメントが整っており、自動検証の仕組み（テストコード）がしっかり支えていれば、それは良いコードです。
専門家がレガシーコードを見極める最も決定的な基準は、まさに自動化されたテストの有無です。テストコードは、自分が修正した内容が既存の機能を壊していないかをボタン1つで確認してくれる安全装置です。
この安全装置がないと、コードを直すたびに人間が手作業ですべての機能を動かして確認しなければなりません。結局、不安から誰もコードを改善できなくなり、技術的な借金（技術的負債）ばかりが雪だるま式に膨らんでいくことになります。
レガシーコードはどう扱うべきでしょうか？
最もありがちな失敗は、「最初から全部作り直そう」とシステムを丸ごとリプレイスしようとすることです。しかし、既存のシステムが何年もかけて耐え抜いてきた無数の例外処理やノウハウを一度に新しく再現することは、想像以上に危険で失敗する確率も高くなります。
代わりに、庭師が枝を剪定するように少しずつ安全に整えていくリファクタリングという手法を使います。手を加えるべきごく小さな部分にまず安全網（テストコード）をかぶせ、その部分のコード構造だけをわかりやすく整理する作業を日々繰り返していくのです。
こうして徐々に古い部品を新しい部品へと交換していけば、走り続ける車のエンジンを載せ替えるように、システム全体を安全で健全な状態に保つことができます。
🤔 よくある誤解
レガシーコードは、単に古くて昔に書かれたコードのことだ。
書かれた時期にかかわらず、テストコードがなかったり構造が複雑で修正するのが怖いコードがレガシーコードです。昨日書いたコードであっても、テストがなくぐちゃぐちゃであればレガシーコードになり得ます。
🧺 日常で出会う場面
レガシーコードとは安全装置や説明書がなく修正するのが怖いコードのことであり、小さなテストと段階的なリファクタリングによって克服していく必要があります。