← 解説「こまめに動かして確認する — 小さく書いて小さく確かめる」に戻る
サンプルコードで身につける: こまめに動かして確認する — 小さく書いて小さく確かめる
解説で学んだ概念を、5つの具体例で確認します。素朴な例から実務寄りの例へと進みます。
11歩ごとの確認サイクル
保存するたびに ng serve が再ビルドし、ブラウザが自動リロードします。数行書いて保存して画面を見る、この数秒のサイクルを回すのが確認の基本です。
# ng serve を起動したままにしておく
ng serve
# ── 確認サイクル(1周は数秒〜数分)──
# 1. 数行だけ書いて保存する
# 2. ng serve が自動で再ビルド(ターミナルにエラーが出ていないか見る)
# 3. ブラウザが自動リロード(画面が意図どおりか見る)
# 4. 次の数行へ進む
# 保存 → 数秒後に画面へ反映、なので確認のコストはほぼゼロ。
# 「まとめて後で確認」する理由はどこにもない
2console.log で処理の通り道を確かめる
画面に見えない部分は console.log で確かめます。「この関数は呼ばれているか」「値は何か」をログで見れば、当てずっぽうで直す必要がなくなります。確認が済んだら消しましょう。
export class FavoriteList {
favorites = signal<string[]>([]);
add(item: string) {
// 疑問①: そもそもこの関数は呼ばれている?
console.log('add が呼ばれた:', item);
this.favorites.update((list) => [...list, item]);
// 疑問②: 更新後の中身は期待どおり?
console.log('更新後の一覧:', this.favorites());
}
}
// ログが出ない → 呼び出し側(クリックイベントなど)を疑う
// ログは出るが値が変 → この関数の中を疑う
// と、ログの結果で疑う場所を機械的に絞れる。確認後は消す
3DevTools で確認する場所
ブラウザのDevTools(F12)には確認に使える画面がそろっています。まずは Console と Network の2つを見られれば、初学者のデバッグはほとんど足ります。
// ── DevTools(F12で開く)のよく使うタブ ──
//
// Console タブ
// ・console.log の出力と実行時エラーが表示される
// ・画面が真っ白/反応しないときは、まずここを見る
//
// Network タブ
// ・サーバーへの通信(APIの呼び出し)が一覧で見える
// ・「保存したはずが残らない」→ そもそもリクエストが
// 飛んでいるか、ステータスは200かをここで確認
//
// Elements タブ
// ・実際に描画されたHTMLとCSSを確認できる
// ・「表示が崩れた」ときに要素を選んでスタイルを調べる
4まとめて書くとまとめて壊れる
確認せずに3つの変更を積むと、エラーが出たときに疑う場所が3倍になります。しかも変更同士が絡み合うため、原因の切り分けは3倍よりずっと難しくなります。
// ── ありがちな失敗の流れ ──
// 1. ボタンのクリック処理を書く (未確認)
// 2. 続けて一覧への反映処理も書く (未確認)
// 3. さらに保存処理も書く (未確認)
// 4. 初めてブラウザを見る → 画面が真っ白。エラーが複数
// → 原因は1?2?3?組み合わせ? 切り分けから始める羽目に
// ── こまめに確認していた場合 ──
// 1. クリック処理を書く → 確認、動く
// 2. 一覧への反映を書く → 確認、動く
// 3. 保存処理を書く → 確認、壊れた!
// → 原因は3で足したコードのどこか。範囲は最初から明確
// エラーが複数出たときは、一番上の1つだけ読んで直す
5確認できたらコミットして戻れる場所を作る
動作確認とコミットはセットです。動く状態をコミットしておけば、次の変更で壊れても git diff で差分を見たり、動いていた状態に戻したりできます。
# 画面で動作を確認できたらコミット(=動く状態のセーブポイント)
git add src/app/favorite-list/
git commit -m "feat: お気に入り一覧に追加できるようにする"
# 次の変更で壊れたら、まず直前のコミットとの差分を見る
git diff
# → 壊した犯人はこの差分の中に必ずいる
# どうにもならなければ、動いていた状態まで手元を戻せる
git restore src/app/favorite-list/favorite-list.ts
# 「動いたらコミット」を守るほど、失敗のダメージが小さくなる