はじめに
「動いているから触れない」 「ドキュメントがないからわからない」 「作った人がもういない」
レガシーシステムを抱える現場では、こんな声をよく耳にします。
この記事では、そんなレガシーシステムを改善していくための最初のステップについて解説します。
なぜ「まず全部書き直す」は危険なのか
レガシーシステムを見ると、「一から作り直したい」という衝動に駆られることがあります。しかし、これは多くの場合、危険なアプローチです。
リスク
- 隠れた仕様の喪失 - 長年の運用で蓄積された「暗黙の仕様」が失われる
- 並行開発の負担 - 現行システムの保守と新システム開発の二重負担
- ビッグバンリリースの失敗リスク - 一度にすべてを入れ替えるリスク
改善の第一歩:現状を可視化する
1. テストを追加する
まずは、現在の動作を「正」として記録するテストを追加します。
// 既存の処理をそのままテストで保護する
@Test
void 既存の計算ロジックが正しく動作すること() {
var result = legacyCalculator.calculate(100, 0.1);
// 現在の動作を正として記録
assertEquals(110, result);
}
このテストは「仕様を理解するため」ではなく「現在の動作を保護するため」のものです。
2. 依存関係を図示する
コードを読むだけでなく、モジュール間の依存関係を図にします。
- どのモジュールが他のモジュールに依存しているか
- データの流れはどうなっているか
- 外部システムとの連携点はどこか
3. 変更頻度を分析する
Git のログを分析して、よく変更されるファイルを特定します。
git log --format=format: --name-only | sort | uniq -c | sort -rn | head -20
よく変更されるファイル = よく触る必要があるファイル = 改善の優先度が高いファイル
小さく始める
レガシーシステムの改善は、大きな計画より「小さな一歩」が重要です。
- 今週1つテストを追加する
- 今月1つのモジュールをドキュメント化する
- 今四半期で1つの依存関係を整理する
Small differences make a huge difference.
小さな改善の積み重ねが、やがて大きな変化を生み出します。
まとめ
レガシーシステム改善の第一歩は:
- テストで現在の動作を保護する
- 依存関係を可視化する
- 小さく始める
次回は、テストの追加方法について、より具体的に解説する予定です。