「写経だけで終わらせない」ためのデバッグ入門
― クラスのスピードについていきながら“本当の理解”を手に入れる方法 ―
目次
1. 追いつくために写経しているあなたへ
授業中、周りのキータイプが速いと 「とにかく同じ画面を出さなきゃ」 と焦りますよね。
写経(コードの丸写し)は動くまでの最短ルートですが、そこで止まると
- コードの流れが見えない
- バグが出たとき手が止まる
という“理解の壁”にぶつかります。この記事では、
写経のスピードは保ちつつ、ステップ実行で動きを観察するコツ
を紹介します。あくまで 「追いつく → 理解する」 の二段階で考えてみましょう。
2. なぜ写経だけだと伸び悩むのか
症状 | ほんとうの原因 |
---|---|
何となく動くけど、自分で少し改造するとすぐエラー | 変数やループの“次の値”を想像できていない |
デバッグ方法が Console.WriteLine() 一択 | 実行を止めて値を直接見る体験が欠けている |
バグが出ると「センスがない」と自己否定 | エラー=挫折ではなく、観察チャンスだと知らない |
3. 写経+観察に切り替える 5 つのテクニック
テクニック | やり方 | 効果 |
---|---|---|
① 強制ストップポイントを埋め込む | Debugger.Break(); を数行ごとに入れ、必ず実行が止まるようにする | どんなに急いでも“停止&ウィンドウを覗く”動作が入る |
② ウォッチリストで値を覗く | 止まったら i や sum をウォッチ欄にドラッグ | 「頭で予想 → 実値で確認」を高速に回せる |
③ コピペ解禁タイムを使う | 授業後半に GitHub から完成コードを取り込み、みんなと同一状態でデバッグ練習 | 置いていかれる不安ゼロで“観察だけ”に集中 |
④ 5 分ペアデバッグ | 交代制で「タイピスト」と「ナビゲータ」を担当。ナビゲータはブレイクポイント操作だけに専念 | 片方が入力に集中している間も、もう片方は理解を深められる |
⑤ 予測クイズを挟む | 例:ループ 3 回目で sum は? → 止めてスクショ提出 | “写経して終わり”を防ぎ、観察しないと答えられない課題にする |
4. ミニチュートリアル例(所要 10 分)
- 写経 3 分
int sum = 0;
for (int i = 1; i <= 5; i++)
{
sum += i;
System.Diagnostics.Debugger.Break(); // ★ここで止まる
}
Console.WriteLine(sum);
- 実行→自動停止
- ウォッチ欄で i と sum を確認
- F10 キーで 1 行進め、値の変化を声に出す
- 「i は 1 から 2 に変わった」
- 「sum が 1 増えた」
- 最後まで進め、Console の出力を確認
ポイント
- “止めて見る”→“1 行進める”をループさせるだけで、時間軸の学習が完了します。
- これを写経直後に 1 回でもやれば、次の授業でバグに遭遇しても怖くありません。
5. 失敗は“動作ログ”を拾うチャンス
- バグが出たら 「なぜ止まった?」→ブレイクポイント再配置 が最短ルート。
- Stop → See → Think の 3 ステップを習慣にすると、写経スピードと理解力の両方が上がります。
まとめ
- 写経はゴールではなくスタートライン
- ブレイクポイントは動きを“見える化”する顕微鏡
- 小さな観察を毎回挟むだけで理解は指数関数的に伸びる
明日の授業から、まずは Debugger.Break(); を 1 行入れてみてください。
動きを“見る”習慣が付けば、「ただの写経」から一歩抜け出せます。
訪問数 3 回, 今日の訪問数 3回
ディスカッション
コメント一覧
まだ、コメントがありません