AIにコードを直してもらう前に、影響範囲を知りたい

AIは、methodを見つけて数行を修正する作業がとても速いです。しかし実際のプロジェクトで時間がかかるのは、「コードがどこにあるか」よりも「ここを直すと、ほかのどこに影響するか」という確認です。

検索結果が正しそうに見えても、複数ある実装の一つにすぎなかったことがあります。dependency injectionで生成されるserviceは、直接の呼び出しが見つけにくいこともあります。数個のfileにしかない設定値が、起動、deploy、testのすべてに影響する場合もあります。

そのため、私は最初から変更するfileを決めません。まず、実現したい動作を言葉にします。

確認できる動作から始める

例えば、「端末が再接続したとき、重複した登録を作らず、既存のsessionを復元する」という形です。

この一文があれば、「connection serviceを修正する」と早い段階で決めつけず、application、domain、persistence、testを横断して調べられます。

最初は文字検索で、event、endpoint、class、既存testなど、処理の入口になりそうな場所を探します。全体の方向をつかむには、今でも文字検索が最も速い方法です。

中心となるsymbolが見つかったら、ローカルのcode graphで関係をたどります。誰が呼び出しているか、前にどのinterfaceがあるか、後ろにどの実装があるか、どのmoduleが依存しているか、同じ流れを扱うtestはどれかを確認します。

リポジトリ全体を読む必要はありません。変更範囲を決められる、小さな地図があれば十分です。

調査は広く、変更は小さく

修正前に、変更する可能性があるfile、変えてはいけない動作、結果を確認するtestを整理します。

近くのcodeが少し読みにくくても、今回の変更を妨げない限り、ついでのrefactorはしません。patchが小さいほどreviewしやすく、検証が必要な仮説も少なくなります。

確認も影響範囲に合わせます。まず変更に近いtestを実行し、riskに応じてmodule testやbuildへ広げます。patchが問題なく適用できたことは、動作が正しい証拠にはなりません。

code graphも新しい正解ではありません。indexが古いことも、言語の機能をすべて理解できないこともあります。最後は必ずsource code、build設定、testを確認します。graphは、より良い質問を作り、見落としやすい関係に気づくための補助です。

編集前に少し立ち止まる流れですが、難しい変更ほど結果的に早く進みます。最初に見えたfileを直して後から影響に気づくより、理由と確認方法が明確な小さな変更を作るほうが安心です。