3. コードを理解する

概要

実装を始める前に、画面表示、残席計算、テスト、CI、GitHub Pages デプロイに関係するファイルと処理の流れを確認します。この操作ではファイルを変更しません。

既存コードを理解せずに変更すると、修正すべき場所を誤ったり、既存の動作やテストを壊したりする可能性があります。データ、画面、ロジック、テスト、Workflow の役割を整理すると、変更対象と検証対象を必要な範囲へ絞れます。

このハンズオンでは、残席表示を変更する前に、src/main.js から formatAvailability が呼び出される流れと、その結果を Vitest と CI で検証する仕組みを確認します。

手順

1. コードを確認する

Ask モードで以下の指示を与えます。

この Vite アプリについて、画面表示、残席計算、テスト、CI、Pages デプロイに関係するファイルを挙げ、処理の流れを簡潔に説明してください。
ファイルは変更せず、コマンドも実行しないでください。

次を確認します。

• src/main.js、src/availability.js、src/availability.test.js が説明されている
• .github/workflows/ci.yml と .github/workflows/pages.yml の実行条件と役割が説明されている
• ファイル変更やコマンド実行が行われていない

補足: GitHub Copilot のモード

GitHub Copilot には Agent、Ask、Plan モードが存在し、それぞれ用途によって使い分けることで効率的にエージェントを動作させることができます。

• GitHub CopilotにIDEで質問を行う - GitHubドキュメント
• Copilot ask, edit, and agent modes: What they do and when to use them - The GitHub Blog

2. アプリとテストの処理を確認する

src/availability.test.js は formatAvailability を直接呼び出し、通常の空席、満席、定員超過の3つの入力で結果を検証します。画面の組み立てと残席計算が分離されているため、ブラウザーを起動せずに計算部分だけをテストできます。

3. データモデルと残席計算を確認する

src/main.js の events は、イベントを表すオブジェクトの配列です。明示的なクラスや型は定義していません。

プロパティ	値の例	役割
title	JavaScript テスト入門	画面に表示するイベント名
date	2026-10-21	開催日
capacity	12	定員
attendees	10	参加者数

capacity と attendees は formatAvailability へ渡されます。関数は残席数を0未満にしないよう計算し、「残り○席」または「満席」という表示用の文字列を返します。

4. CI/CD の処理を確認する

.github/workflows/ci.yml では、on が実行条件、jobs が処理単位、steps が実行順序を表します。.github/workflows/pages.yml では、build ジョブが公開用の dist を作成し、その完了後に deploy ジョブが GitHub Pages へ公開します。

確認事項

• formatAvailability による残席計算と画面表示の関係を説明できる
• Vitest が残席計算の境界値を検証する流れを説明できる
• Pull Request および対象ブランチへの push と CI の関係を説明できる
• main への push と GitHub Pages デプロイの関係を説明できる

まとめ

ソースと Workflow を確認し、イベントデータ、画面表示、残席計算、テスト、CI、デプロイがどのようにつながっているかを整理しました。これにより、残席表示を変更するときは src/availability.js を修正し、src/availability.test.js で境界値を検証すればよいことが分かりました。

実装前に処理の入口、変更対象、呼び出し元、テスト、デプロイへの影響を確認すると、無関係なファイルへ変更を広げずに済みます。GitHub Copilot の説明を利用する場合も、回答をそのまま信頼せず、実際のソースや Workflow と照合して判断することが重要です。

次は、ここで把握した変更対象と検証方法をもとに、変更の目的と完了条件を Issue へ記録します。