kazuph/improve-legacy-code

レガシーコード改善ガイド (Based on Takuto WADA)

このスキルは、テストコードがなく、構造が整理されていない「レガシーコード」を、安全にリファクタリングし、持続可能なコードベースへと進化させるための手順を提供します。

ユーザーからレガシーコードの改善やリファクタリングの相談を受けた際、以下のフェーズに従って提案・実装を行ってください。

基本原則 (Mindset)

"テストがないコードはレガシーコードだ" (Michael Feathers)

• 現状認識: テストがなく、仕様書もなく、元の開発者もいない場合、コードこそが唯一の真実です。
• 安全性: テストコードなしでコードを変更することは危険です。まずは「動作するテスト」を用意することが最優先です。
• 優先順位:
  1. Version Control (最優先: まずGitに入れる)
  2. Automation (自動化: 手作業を減らす)
  3. Testing (テスト: 変更の恐怖を取り除く)

---

フェーズ 1: 闘う準備を整える (Preparation)

コードを変更する前に、安全地帯を確保します。

1. バージョン管理: 対象のコードがGit管理されていない場合は、直ちにコミットすることを提案してください。
2. 現状の理解: エントリーポイント（例: Lambdaハンドラ、main関数）を特定し、処理の流れを把握します。
3. 自動テストの整備:
   • 最初は網羅性を求めず、「脳天気な正常系 (Happy Path)」だけで良いので、動くテストを1つ書きます。
   • E2E/統合テストから始める: 内部構造に依存しない、外側からの入出力を検証するテスト（例: リクエストとレスポンスの検証）を作成します。
   • 接合部 (Seam) の特定: テストを困難にする要素（ランダム、時刻、外部API、DBなど）特定します。

テクニック: Humble Object Pattern (ランダム性の排除)

テストの決定性を確保するため、ランダム性や外部依存を「接合部」として切り出します。

• 手法: 依存部分（例: Math.random()）を引数や関数として外部から注入（Dependency Injection）できるように修正します。
• 目的: テストコードからは固定値を返す関数を渡し、本番コードではランダムな関数を渡すことで、ロジック自体は変更せずにテスト可能にします。

---

フェーズ 2: テスト駆動開発 (TDD) のサイクルを回す

テスト環境が整ったら、仕様変更や機能追加は必ず TDD (Red -> Green -> Refactor) で行います。

1. Red: 実現したい機能のテストを書き、失敗させる。
2. Green: 最小限のコードを書いてテストを通す（ダーティな実装でも可）。
3. Refactor: テストが通っている状態で、コードをきれいに整理する。

"コードを変更するためにはテストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある" (レガシーコードのジレンマ)

---

フェーズ 3: ドメインモデルの分離 (Extract Domain Model)

ロジックがフレームワーク（例: AWS Lambda, Express, Rails controller）にべったり張り付いている状態（Smart UI アンチパターン）から脱却します。

戦術: Extract or Sprout

既存コードに手を入れるのが怖い場合は、新しいロジックを独立したクラス/関数として作り（Sprout）、そこに対してテストを書きます。

1. POJOへの移行: ロジックを、フレームワークやインフラに依存しない純粋なクラス（Domain Model）に移動させます。
2. Humble Object化: フレームワーク側のハンドラは、リクエストを受け取ってドメインモデルに委譲し、結果を返すだけの「薄い層」にします。
3. テストの高速化: ドメインモデルは外部依存がないため、高速なユニットテストが可能になります（テストピラミッドの下段を厚くする）。

---

フェーズ 4: 事実と情報の分離 (Fact vs Information)

状態管理（State Management）を改善します。

• データ（事実）: ユーザーの回答履歴、タイムスタンプなど、不変の事実。
• 情報: スコア、現在のレベル、メッセージなど、事実から計算されるもの。

指針: 変数を直接操作して状態（例: score++）を管理するのではなく、事実（履歴）を蓄積し、そこから状態（スコア）を都度計算する設計に変更します。これにより、仕様変更（例: スコア計算ルールの変更）に強くなります。

---

フェーズ 5: アーキテクチャを定める (Clean Architecture)

最終的なゴールは、詳細（フレームワーク、DB、UI）から、重要（ドメインロジック）を守ることです。

1. 依存性のルール: ソースコードの依存性は、常に内側（ドメイン）に向かっていなければなりません。
2. 詳細の隠蔽: 具体的な実装（AWS SDKなど）はアダプター層に閉じ込め、ドメイン層からはインターフェースを通じて利用します。
3. 情報隠蔽: ドメインモデルの内部構造を公開せず、必要な操作（メソッド）のみを公開します。

---

ユーザーへのアクション提案テンプレート

ユーザーからコード改善を求められた際は、以下のステップを確認してください：

1. 🔍 現状確認: 「まず、このコードのテストコードはありますか？ バージョン管理はされていますか？」
2. 🧪 最初のテスト: 「リファクタリングの前に、現在の挙動を保証するテスト（Golden Master）を書きましょう。入出力のサンプルを教えてください。」
3. ✂️ 接合部の作成: 「ランダムな要素や外部通信を行っている箇所はありますか？ そこを切り離すことから始めましょう。」
4. 🏗 モデル抽出: 「ロジック部分を Session や CoreLogic といったクラスに切り出し、フレームワークから独立させましょう。」