デバッグで効率よくプログラミングしよう【C# visual studio】
コードが出来上がると実行にて動作を確かめるわけですが、
プログラミングを始めたばかりでは、なかなか一発目からうまくいくことは少ないかもしれません。
大抵はバグや動作が違うなどの不具合がでたりするものです。
そんなとき心強い対処方法がデバッグになります。
そして、C#には強力な開発環境visual studioがあります。
デバッグもしやすい開発環境だと思いますので、
C#でデバッグを効率化していくための具体的な方法を紹介したいと思います。
また、本記事ではデバッグ効率化によるメリット、
プログラミングの学習効率への影響と
業務レベルで活躍できる場面も合わせて紹介します。
興味がありましたら、最後までお読みいただけると嬉しいです。
目次
デバッグを効率よく進める方法
デバッグ操作の方法はそんなに多くはありません。
ゆえに、少ない労力ですぐにでもあなたの作業を助ける力になるでしょう。
- 変数の中身を変える
- 指定した条件で止めるブレークポイント
- 止めた後のコード実行4パターン
- コードスキップ&コードバック
変数の中身を変える
活躍する場面と実際の操作を紹介します。
活躍する場面
変数の中身を変えると嬉しい場面は開発をしているとでてくるでしょう。
例えば、コード仮組していみて、止めて変数の中身が間違っていた時です。
とりあえず間違っていたけど、先に進めるために値を変更すればその先の動きを確認できます。
また、あえてエラーを発生させる値に変更してcatchに入るなど、異常系の動きを確認することもできます。
変数の中身を変える方法
では、実際のやり方です。
止めたい場所にブレークポイントをいれてまず止めます。
今回はこのhello変数を変えてみましょう。
helloにはそのまま”hello”が入っているわけですけども
「値」の項目を変えればhello以外の文字列を出力できます。
変え方はいくつかありますが、一番簡単なのは
変数helloにフォーカスオンしてでてきた値”hello”をクリックして編集する方法です。
これでサクッと変えられます。
ほかにも変数の中身を確認できる場所からであれば、どこかれでも変えられます。
実例をみてみましょう。
「ウォッチ式ウインドウ」「ローカルウィンドウ」「自動ウインドウ」
上の画像では、この3つのウインドウどこからでも編集できることがわかります。
指定した条件で止めるブレークポイント
こちらも活躍する場面と実際の操作を紹介します。
指定した条件での止め方
ブレークポイントを右クリックして条件を選択します。
ブレークポイント設定がポップアップするので
条件にチェックをいれ、止めたい条件を入力すればOKです。
今回はfor文のiが50になった時だけ止まるように設定しています。
ループと相性が良い
やり方のサンプルとしてもループを題材にしましたが、
指定した条件で止めるブレークポイントはループと相性がよいです。
ループ中で止める場合、10回程度のループではF5で実行再開すればいいのですけれども、
これが100とか1000とかになってくると大変です。
見たいループ回数にたどり着くまでに再実行し続けなければなりません。
そんな時に活躍するのが指定した条件で止めるブレークポイントの設定です。
データ量が多いサービスなんかは配列の要素数が増えていくので
この条件で止める方法を覚えておくと作業の効率化がはかれます。
止めた後のコード実行4パターン
ブレークポイントで処理を止めてからのコード実行する4種類の方法について紹介します。
- 再開するF5
- メソッドの中に入るF11
- 呼び出し元に戻るshift + F11
- 次に進むF10
動きを覚えれば、自在にコード実行するのに役立つので余裕があれば暗記をしたいところです。
もう知っているよという方もおさらいの意味で読んでいただければと思います。
さて、上の画像は100回ループするメソッドloop100()を実行する手前で止まっている状況です
こちらを題材にひとつずつ見ていきましょう。
再開するF5
まずは、次のブレークポイントまで処理を再開するF5です（画像オレンジ色の矢印）。
loop100はもちろん、Console.WriteLine(“hello!”)も
Console.WriteLine(“End DoSomething”)も実行し先に進んでいきます。
ブレークポイントがない限りは処理が終了するまで実行をします。
メソッドの中に入るF11
次は、メソッドの中に入るF11です。
ステップインともよばれ、メソッドの中に処理を進めることができます。
今回の例では、「layar2Service.loop100();」からloop100()の先頭行に進みます。
呼び出し元に戻るshift + F11
メソッドをすべて実行して抜けるので、ステップアウトとも呼びます。
「F11」で中に入ったのち「shift + F11」で呼び出し元にもどります。
画像上はわかりにくいですけれども、
loop100が「実行し終わった状態」で呼び出し元のlayar2Service.loop100()にもどります。
次に進むF10
真下の行に進みます。
F11で一つずつ処理をするのを一瞬で実行し、次の行に進むため、
ステップオーバーとも呼ばれます。
ちなみに、loop100内にブレークポイントがあると、ブレークポイントが優先されそこで止まります。
この動きは「再開する（F5）」と同じです。
コードスキップ&コードバック
デバッグ操作にはコードをスキップしたり、通り過ぎたコードをもう一度実行する事ができます。
やり方は簡単。
実行している黄色い矢印をドラッグアンドドロップするだけ。
先に進むことも戻ることも可能です。
コードスキップ
「コードを実行しない」で別の行まで処理を進める荒業ですね。
エラーを吐き出してるメソッドを丸ごとスキップしたりするのに役立ちます。
そもそもエラーがある状態でデバッグするなよという意見もあるかもしれません。
しかし、実行時にエラーが起きるような「書き途中」のコードであっても
完成している部分だけ実行して動きを確かめられますので、柔軟なデバッグができます。
こまめに動かしたい時などはこのコードスキップを使ってみてはいかがでしょうか。
コードバック
コードをスキップを後ろに戻せば同じコードを、もう一度実行できます。
デバッグ時に「あ、通り過ぎてしまった！」というときに手軽に再実行できるのでおすすめです。
コードスキップ&コードバックで注意すること
黄色い矢印にフォーカスするとポップアップでメッセージが表示されます。
次に実行されるステートメントです。次に実行されるステートメントを変更するには矢印をドラッグしてください。ただし予期しない事態が起きる可能性があります。
字面だけでみると、コードスキップとコードバックに躊躇してしまうかもしれません。
しかし、内容としては極単純なことを言っていて、
「一応、本来の動きではないので、違う動きになるかもしれないことを念頭においてね」
程度の内容です。
コードを飛ばしたり、もう一度実行したりするのですから、
当たり前といえば当たり前の警告文といえます。
ですので、過度に気にする必要はありません。
学習効率を上げるためのデバッグ
あなたがもし、C#のプログラミングを始めたばかりであれば、
学習速度を上げるためにもデバッグ操作を覚えることをお勧めします。
コードを修正するスピードを上げる
プログラミングの学習速度を上げるにはバグのリカバリーするスピードを上げる事でもできます。
コードを書いていて、バグが発生しないのであれば次の内容、次の内容と進んでいけます。
しかしながら、プログラミングの学習を始めたばかりでは
思いもよらないバグがいくつも発生し、
書いたコードがなかなか動かないかもしれません。
これは、まだ道具の使い方に慣れていない段階なので、時間がたてばバグの数は減っていくでしょう。
気長にプログラミングを習得していきたい場合は特に問題ないですね。
ですが、さっさとプログラミングができるようになりたいならば、話は別です。
プログラミング習得までの時間を短縮するには、いかにバグを早く修正し次のステップにいけるかは、
学習速度を上げるポイントのひとつになります。
デバッグを覚えることはコスパが良い
コード書く力＞デバッグだとしても
- 第一に、覚えなければならない物は少ない
- 第二に、覚えるとしてもキー操作とマウス操作がメイン
「デバッグを効率よく進める方法」でも紹介した4つの内容を使うだけでも効果があります。
また、コードを書くようにロジックを考えるわけではなく、あくまで単純な動作が基本になるので覚えやすいです。
確かに、プログラミング学習という点では「コードを書く」ことに比べるとデバッグはあくまで補助の立ち位置です。
コードを書くことに比べると重要度はどうしても落ちてしまいます。
それでも、バグが起きた時にいかに早く期待通りの処理にもどせるかは、
デバッグ技術が関係してきます。
4つのデバッグ方法を覚えるくらいで学習速度にプラスの効果があるならコスパが良いと思います。
デバッグは実践で使える
また、デバッグは学習効率をあげるだけの存在ではありません。
業務レベルでもデバッグは活躍します。
業務においてもバグは身近にあるものです。
デバッグは保守業務で欠かせないもの
リリース後も製品をケアする作業を保守ともいいますが、
デバッグはまさにこの保守作業のスキルの一つにもなります。
バグは発生するもの
バグがない状態でサービスを開始しても、いずれバグが発生します。
なんなら、バグがあるとわかっていてもサービスを開始したりします。
何故か？
理由の一つはバグとテストの関係です。次の図をご覧ください。
バグを潰すにはバグをすべて確認しなければなりません。
この図はどれだけテストをすればバグをすべて洗い出せるかを洗い出したイメージグラフです。
テスト数を上げればバグ確認率が100%に近づいていきますね。
しかしながら、80%～90%を超えたところで、テスト数を上げても確認率がなかなか上がらなくなります
このグラフはあくまでサンプルデータなのですけれども、
実際の開発でも同じような曲線を描きます。
頑張ってバグ確認率を100％に近づけるには時間・人手・お金がいります。
無限にリリースがあれば問題ないのでしょうが、現実はそうはいきません。
つまり、何を言いたいのかというと
お金の問題でビジネスでは、あえてバグを検出しきらないで製品をリリースする可能性があるということです。
もちろん、作る製品には様々なのものがあります。
人命に関わる製品であれば、多くのコストを払ってバグを可能な限り潰していくことも求められます。
それでも、人の作るもの完全なバグ0は、統計上の話です。
先のバグ確認率のイメージでも100%には到達しません。
ですので「統計的にバグをすべて出し切った」いうところまで品質を持っていきます。
ただ、残念ながら「統計的に起きないでしょう」といっても運が悪ければ、バグは発生したりするものです・・・
リリース後はバグとの闘い
製品をリリースしてもバグは発生することについて説明しました。
バグを放置すれば、ユーザーにとって不利益、いずれは自分たちの不利益につながります。
ですが、バグが起きることを前提とするならば、あとはどうやって対応するかを考えればいいだけです。
そう、不具合をみつけたら早急に取り除けばよいのです。
不具合（バグ）を取り除くからこそのデバッグ技術
バグ修正のポイントは3ステップと考えています。
「再現できるか」「原因特定できるか」「修正できるか」
このうち、再現できるか、原因特定できるか、でデバッグは活躍します。
再現する
バグの原因特定はどれだけ再現できるかにかかっています。
バグ再現できないようであれば、いつまでも原因はわかりません。
デバッグの技術はコードレベルで再現する手段の一つです。
今回紹介した、指定した条件で止めたり、意図的に変数を書き換えることで
いち早く再現できたりする場面は、決して珍しくはありません。
原因特定する
また、原因特定するための強力なエビデンスにもデバッグは使えます。
デバッグでは不具合の値になる瞬間を再現できるわけですから、
原因特定といえる強力なエビデンスになります。
原因を特定できれば、コード修正を後は行うだけです。
どれだけコード修正までにたどり着けるかどうかは、デバッグの早さにかかっています。
まとめ
- 変数の中身を変える、指定した条件で止める、止めた後コード実行の仕方を覚えるだけでも効果あり
- 原因究明までの時間を短縮できるので学習効率もあげられる
- 業務レベルでもデバッグは使える
デバッグはプログラミングの効率化や保守作業でつかえる技術です。
繰り返しになりますが、デバッグの作業自体は覚えることはそこまで多くはありません。
これを機に覚えてみてはいかがでしょうか。
