ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books)

  • 108人登録
  • 3.48評価
    • (6)
    • (7)
    • (13)
    • (1)
    • (2)
  • 7レビュー
著者 : やねうらお
  • 技術評論社 (2008年11月14日発売)
  • Amazon.co.jp ・本 (312ページ)
  • / ISBN・EAN: 9784774136684

ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books)の感想・レビュー・書評

並び替え:

表示形式:

表示件数:

  • 内容は、ソフトウェア開発をしたことがある人なら全て経験しているであろうデバッグに関するテクニックがあれこれ書かれています。簡単なテクニックからはじまり、徐々に高度なテクニックに移り、ちょっと難しいなと思ったあたりから、コードレビュー的な視点で何がいけないのかが丁寧に書かれ、最後に集大成のデバッグが待っているという(プログラムから離れて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バイトで、まず呼び出し元のアドレスを取得。
    これは確実に呼び出し元のアドレスといえる。
    呼び出し元の関数のアドレスの取得方法がポイントになるが、これはここに記載しない。
    本を読んだ方が早い。

全7件中 1 - 7件を表示

ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books)を本棚に「読みたい」で登録しているひと

ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books)を本棚に「いま読んでる」で登録しているひと

ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books)を本棚に「読み終わった」で登録しているひと

ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books)を本棚に「積読」で登録しているひと

ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books)はこんな本です

ツイートする