VB ソースを「全部読まない」差分レビュー術

なぜ書いたか

VB.NETの業務系ソースは、画面1つで *Frm.vb（フォーム本体）、*Frm.Designer.vb（デザイナー定義）、*Mod.vb（共通モジュール）など、軽く数千行になります。これを全部読んでから移行を始めると、いつまでも実装に進めません。今回は読む範囲を絞って差分レビューを高速化した話です。

やったこと

「全部読む」を諦めて、操作シナリオ単位で必要箇所だけ読む に切り替えました。

具体的には：

1. 対象画面のイベントを抽出: *_Click 系のメソッドを *Frm.vb から列挙
2. 対応シナリオで分類: 「クリア」「設定」「削除」「決定」など、ユーザー操作の言葉に変換
3. 呼び出し先を辿る: 各イベントから呼ばれるモジュール、SQL、関数を1階層だけ追う
4. 比較表を作る: 「VB側のシナリオX」「Blazor側の対応メソッド」「触るテーブル」「権限制御」を並べる

これで、画面ごとに 見るべきコードが1/10程度 に絞れます。

ハマりどころ

最初は *Frm.vb だけ読んでいたんですが、これだと足りませんでした。

• Designer.vb側の可視制御: ボタンの初期Visible/EnabledはDesigner側に書かれていることがある
• 共通モジュール側のSQL: フォーム内でSQLを組み立てているように見えて、実は共通モジュールに飛ばしている
• 共通モジュールの中の関数呼び出し: Oracle関数呼び出しが、フォームから2階層深いところに隠れている

なので、最低限「Frm.vb」「Frm.Designer.vb」「Mod*.vb」の3つは読むようにしました。

比較単位を「関数」ではなく「シナリオ」に

最初の失敗は、比較を関数単位でやろうとした ことです。「VBの btn_Delete_Click とBlazorの OnDelete を比較」みたいに。

これだと「OnDelete の中で何をしているか」までしか見ません。実際はVB側の btn_Delete_Click から呼ばれる deleteToData のようなモジュール関数まで含めて初めて、「同じテーブルを消しているか」が分かります。

なので比較単位を 「ユーザーから見たシナリオ」 に切り替えました。シナリオは「行を選択して削除ボタンを押す → 関連マスタ3系統が消える」のような業務観点。実装の階層構造ではなく、業務の単位。

わかったこと

• VBソースを全部読む必要はない。読むべき範囲を絞れる構造を最初に作る のが大事
• イベントハンドラは入り口にすぎない。実装は共通モジュール側にある ことが多い
• 比較単位は シナリオ。関数単位だと階層差で抜け漏れます
• AIに「VBのこのファイルを全部読んで実装して」と頼むより、「このシナリオに対応するVBのコードを抽出してから実装して」のほうが精度が上がります

次にやること / 未解決の問題

• シナリオ抽出を半自動化したい。AIに「*_Click を列挙して、ユーザー操作の言葉に変換して」とやらせる試行は始めている
• Designer.vbの可視制御を読むのは機械可読にしにくい部分がある。プロパティの並びを正規化するスクリプトを書きたい