ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books)
- 技術評論社 (2008年11月14日発売)
- Amazon.co.jp ・本 (312ページ)
- / ISBN・EAN: 9784774136684
感想・レビュー・書評
-
やねうらお作のデバッグテクニックの連載。
全てがいつまでも使えるテクニックではないが考え方は参考になった。
かなりMicrosoft系の開発に偏っている。
Visual Studioショートカット
C-] 対応する括弧に移動
C-E,C コメントイン E=Extend C=comment
C-E,U uncomment
C-J インテリセンス再表示(Iの次の文字がJ)
インテリセンスはCtrlキーで半透明
C-W,D Window Define メソッド定義を別ウィンドウで表示
[more]
・Sparse Matrixの実装は、std::map<std::pair<int,int), val_type> でできる。
・lap aroundも巻き付くという意味だが、通常は wrap around
・2001年頃の命名:ハンガリアンにならい、メンバ変数は m_ その後、name_。だとCライブラリとバッティング
・2007年頃の命名:C#だとメンバ変数に印を付けなくなった。インテリセンス。this.とドットなので楽。
・1997年頃の関数返り値のブーム:0が成功。0以外は失敗の理由を表す。C++ではif(ret)でエラー処理をかける。
・C#ではintをif文に使うとboolでないと警告。詳細をみるコメント0件をすべて表示 -
内容は、ソフトウェア開発をしたことがある人なら全て経験しているであろうデバッグに関するテクニックがあれこれ書かれています。簡単なテクニックからはじまり、徐々に高度なテクニックに移り、ちょっと難しいなと思ったあたりから、コードレビュー的な視点で何がいけないのかが丁寧に書かれ、最後に集大成のデバッグが待っているという(プログラムから離れて10年の私でも)楽しく読み進められる本でした。
もちろんこの本にも難点(納得がいかない点)もないわけではありません。230ページ2行目の仮引数とローカル変数の書き間違えといった誤植系が多少あることと、いや、そんなことはどうでもいいことなのですが、それよりも、問題は191ページです。
「ところで、ケニチ君。次のプログラムをどう思う?」
if (10<=b1) {
} else {
init();
}
といったところ。
詳しくは本文を読んでもらうとして、ここで筆者が言いたいことは、「コピペしてきたソース(上に引用したelse部しかないif文)をきれいに書き直してしまうと、コピペしたこと自体が判らなくなるので、最悪のリファクタリングだ」ということです。まぁ、議論は分かれると思いますが、私は賛同できないなぁ。 -
軽い調子で書かれているが意外に深い。デバッグを体系的に扱う類の本ではなく、プログラミングのノウハウをまじえた読み物という感じ。具体的なテクニックはVisual Studio C++/C#前提だが、デバッグの考え方は環境を越える。インテリセンスのようなIDEのサポートによってコーディング規則がどんどん変わる。コーディング規則は宗教戦争だと切り捨てていてなるほどと。
#ひげぽんさんのcountoバグの話が出てくるw -
VisualStudioでのデバッグってかなり自己流+できる人の後ろで「それどーやんの?」だったからこの本は参考になってる。
-
読み物として意外と面白い。テクニックはかなり具体的。
-
Visual Studio 2008を前提にしたデバッグのハウツー本。ただツールの使い方というより、その時にどう考えればいいのかというところに注目して書かれている本。
デバッグの方法を特に誰かに教えうけたわけでもなく我流でやってきて行き詰っている人や、この本の主人公(w)のケンイチくんのようにこれからデバッグにかかわっていくプログラマ初心者には何をどうすればいいのかという点に道筋をつけている点でいい本だと思います。
ただそれにしてはC/C++のデバッグに必須ともいえるプロセッサの仕組み等奥行きに関する記述が少なく、これだけで済まないのも事実で、その点についてはこの本の後にさらなる書籍に移っていく必要があるので、それらの書籍の紹介もあったほうがいいと思う。 -
勉強した結果をまとめる。
・第一回「デバッグにおける不確定性原理」
デバッガの使い方をメインに取り上げているが、やればできるのでここでは述べない。
役に立つ考え方は以下のようなものか。
・デバッガは一行単位で動作するので、一行に多くの処理を記載しないようにする。
・第二回「バグの発生点と発現点」
バグが現出したポイントと、実際にバグが存在するポイントは異なるという考え方。
明確に考えたことがなかったが、確かにそのとおりだ。
バグが外部APIで現出したから外部APIにバグがあるとは限らない。
バグが現出したポイントから遡り、それぞれの処理が正常に動作しているのか判断することが肝要だ。
バグが露見した瞬間に、プログラムを停止させること(できる場合のみ)。
__LINE__マクロを使い、関数呼び出し元の行数を確認すること、など。
正規表現、そろそろ使い方をマスターした方がいいよな。。。
・第三回「二分法によるバグ発生点の絞込み」
継続的にステータスを更新するようなプログラムにバグがあり、
ある時点で発生したパラメータ異常がクリアされずにプログラム内に残存することにより、
異常データが異常なまま動作していき、
結果としてある時点でプログラムが異常終了する、といったケースへの対処法。
この場合、異常が発生するポイントを探ることになる。
ポイントは2点。
・パラメータが異常か正常かを判定するテスト機能を用意する
・パラメータがどの時点で異常になったか検索するテスト機能を用意する
(この機能の中で、前者のテスト機能を使用する)
後者の機能を実現するため、ここでは再帰呼び出しを使った二分探索を行っている。
使う場面は限られると思うが、パラメータを累積する類のプログラムのテスト技法として覚えておくとよいかも。
「探索結果なし」が正常終了を意味するのだから、バグがあるかどうかわからない状態でも使える。
・第四回「コールスタックの活用」
段々内容がマニアックになってきました。
C/C++で関数をコールする場合、コールスタックに引数の値を格納した後、
戻り先の関数のアドレスをスタックに格納して、呼び出したい関数にジャンプする、らしい。
これを利用して、呼び出し元の関数を割り出す、というテクニック。
呼び出した関数の第一引数-4バイトで、まず呼び出し元のアドレスを取得。
これは確実に呼び出し元のアドレスといえる。
呼び出し元の関数のアドレスの取得方法がポイントになるが、これはここに記載しない。
本を読んだ方が早い。