レガシーコードは時間が経つほど悪化する
レガシーコードは時間が経つにつれて良くなることはありません。むしろ悪化していきます。
先週、私はバグの修正に3時間を費やしました。本来なら20分で済むはずでした。問題は2019年のバリデーションモジュールでした。「動いているから」と誰もが無視していました。しかし、それは動いていませんでした。ファイルの中に、2020年のTODOコメントを見つけました。
多くの人は、レガシーコードを「余裕があれば返済できるオプションの負債」のように扱います。しかし、レガシーコードはカビに似ています。それは広がり、システムの他の部分を汚染していきます。放置すればするほど、掃除にかかるコストは膨れ上がります。
これにより、以下のような悪循環が生まれます：
- 整理されていないプロジェクトを引き継ぐ。
- 機能を実現するために、さらに1つのif文を追加する。
- 6ヶ月後、他の誰かが同じことをする。
- 1年後、そのファイルは800行に達し、テストはゼロになる。
この「動いている」コードには、隠れたコストが存在します：
- 開発スピードの低下。コードを書くよりも、文脈を理解することに多くの時間を費やすようになる。
- バグの増加。一つの箇所を直すと、別の箇所が壊れる。
- オンボーディングの困難化。新しい開発者が、なぜ至る所でロジックが重複しているのかを理解するのに苦労する。
次のようなレッドフラグ（危険信号）に注意してください：
- 無意味なコメント、あるいは嘘をついているコメント。
- 異なるファイル間でのビジネスロジックの重複。
- 循環依存と高い結合度。
すべてを書き直そうとしないでください。全面的な書き直しは80%の確率で失敗します。ビジネス側が新機能を待っている間に、すでに存在するものを再構築するために数ヶ月を費やすことになります。
キャラクター化テスト（characterization tests）を用いた、段階的なリファクタリングを行いましょう：
- たとえ奇妙な挙動であっても、テストによって現在の挙動をキャプチャする。
- その挙動を変えずにリファクタリングする。
- コードが読みやすくなるまで繰り返す。
- その後になって初めて、適切なテストを用いて挙動を変更する。
落とし穴を避けるために、以下のルールに従ってください：
- テストなしでリファクタリングをしない。
- リファクタリング中に挙動を変更しない。バグが、クライアントが依存している「ドキュメント化されていない仕様」である可能性があるからです。
- 静かなコードには手を触れない。3年間変更されておらず、問題も起こしていないモジュールは、そのままにしておきます。
頻繁に触れるコードにエネルギーを集中させましょう。
Source: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h