誰も保守していない古いプロジェクトは、どこから見るか
レガシーコードのリスクは、見た目が汚いことではありません。何を変えたのか自分で分かっていないことです。読む、評価する、そして最後に変える順番で進めます。
進め方
データの流れで未知のコードを読む
一度に一つのモジュールだけを「見慣れないコードを読む」に貼ります。全体を一文で説明させ、入力がどこから来て、どんな変換を通り、出力がどこへ行くかをデータの流れで説明させます。読み間違えやすい箇所を二、三挙げさせ、一行ずつの構文説明は求めません。自分用の呼び出し図を描きながら読みます。
境界と単一障害点を洗い出す
システム名、デプロイ方式、主な外部依存を「複雑なシステムを分解する」に渡します。内側と外側の境界を引き、入力・出力・目的を挙げ、三から六のサブシステムとインターフェースに分け、ボトルネックと単一障害点を指摘させます。最後に実際のシナリオを一つ通し、見落としやすい箇所を確認します。
最も危険なコードを先に見つける
ステップ2で最もリスクの高いモジュールを選び、「コードレビュー」に貼ります。バグ、セキュリティ、性能につながる箇所だけを重大度順に出させ、それぞれ発現条件と具体的な修正方法を書かせます。この一覧で、次にテストを足す場所を決めます。
テストが実際に何を守っているか見る
ステップ3で特定した危険なモジュールについて、実装と既存テストを「テストの抜けを見つける」に渡します。古いプロジェクトでは、実装の詳細を検証するテストが多いものです。未カバーの分岐を挙げさせ、本番影響の大きい五件を選び、重複したテストや内部実装に依存するテストは削ります。これから変える箇所を守れるテストにします。
依存ライブラリの更新で踏む地雷を評価する
依存名、現在のバージョン、目標のバージョン、呼び出し箇所の数を「依存ライブラリ更新のリスク評価」に渡します。実際に呼ばれている破壊的変更だけを残し、必須・推奨・後回しに分類し、更新順序とローカルでの確認方法を出させます。一度に一つだけ上げ、通ってから次に進みます。
使うプロンプト
よくある質問
古いプロジェクトを引き継いだら、まず書き直すべきですか、テストを足すべきですか
どちらもまだ早いです。境界とデータの流れを読み、本当に危険な箇所を見つけ、そこにテストを足します。焦点のない書き直しも、均等にテストを足すことも、リスクの低いコードに時間を使うだけで、実際に壊れる箇所を守れません。
ドキュメントがない古いコードでも、AI は補えますか
一部は補えますが、出てくるのはコードから推測した挙動で、当時の設計意図ではありません。推測は未確認と明示し、昔の担当者やコミット履歴で照合してください。事実として書くと、次の担当者が同じ罠を踏みます。
依存がかなり古いのですが、一度に最新まで上げるべきですか
おすすめしません。呼び出し量に応じて分割し、一度に一つだけ上げてテストを通します。複数のメジャーバージョンをまたぐ場合は、実際に呼ばれている破壊的変更を先に確認し、それ以外は後回しで構いません。