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

著者 :
  • 技術評論社
3.41
  • (6)
  • (7)
  • (15)
  • (2)
  • (2)
本棚登録 : 128
感想 : 8
本ページはアフィリエイトプログラムによる収益を得ています
  • 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でないと警告。

  • 2年以上前に読んだ本。デバッグのセオリーとして、デバッグ目的での変数の値の確認は、呼び出し回数の多い関数で実施すれば、プログラムのあちこちでチェックする必要がなくなると書かれていた。デバッグについて重要なことは、ソースコードを理解してなくても、効率的にデバッグ出来るように作るのがポイントじゃないかと思う。自分がソフトウエアを提供する立場で、あるソフトウエアの時間的効率について議論する場合、二つの点について考える必要がある。
    1) ソフトウエアの作成にかかる時間
    2) ソフトウエアの保守にかかる時間 <--- デバッグ作業の効率はここに効いてくる

    最も気をつけたいのは、1)を安易に最適化すれば、2)が効率的でなくなるケースだと思う。例えば、自作できる数行のコードのために、安易に外部のライブラリを活用すると、開発時間は短縮されるだろうけど、保守作業には不利に働く場合も少なくないと思う。外部のライブラリを使うことは、広義には保守対象のソースコードを増やしてることと同義である。外部のライブラリには、そのライブラリのメンテナーがいるので、ライブラリの利用者がそのライブラリのコードを保守する時間は必要ない。しかし、そのライブラリに不具合があった場合は、自分の環境にインストールしたライブラリをアップデートする(保守)作業は必要だし、そのライブラリのAPIが変わった場合は、自分のコードを変更すると言う作業が必要となる。また、そのライブラリは、自分が必要としてない機能も提供してたりする。そして、他のライブラリをつかっていることもある。こうなってくると、本来必要でない機能のために、ライブラリのバージョンアップをせざるを得ない状況が発生する。そうならないためには、自分が必要とするコードが、外部のソフトウエアが提供する主要な機能と一致していることが望ましい。外部のライブラリを使う上で考えるべき点はおおよそ次の通りだと思う。
    ・そのソフトウエアが提供する主要な機能が、他人のライブラリの機能と重複するなら、新しく作る意味はない(時間の無駄、ただし勉強目的以外)。
    ・自分が必要とする機能を主要な機能としているライブラリを使う
    ライブラリをリンクした時に、いらない機能も一緒にロードさせることによる無駄=不要な機能に対する脆弱性発生時の対応が発生する、を認識すべき。
    ・実装が容易なライブラリは自作する
    科学計算や公開鍵暗号、共通鍵暗号、ハッシュ関数などのライブラリは専門でない限り自作するのはデメリットの方が大きいと思う。
    ・ライブラリの依存関係のツリーが深すぎるライブラリの利用はなるべく避ける。
    保守対象のソースコードが広範囲にわたることになるので、適切な保守管理がより一層必要となる。

    さて、デバッグを、プログラムの不具合発生時の修正作業の1行程と考えると、その詳細は、次のように考えることができると思う。

    1) 不具合の発生条件を整理
    エラーのメッセージ、期待値と結果、プログラム動作環境を整理。
    2) 不具合の発生場所を特定
    不具合が発生する条件を満たす場所をソースコード内部から探し出す。
    3) 修正
    不具合が発生しないようにソースコードを修正する(この行程はデバッグと言わない)。どのように修正するかもプログラマの腕の見せ所だったりする。

    このことから、プログラム提供者のから、「デバッグが速い」とか、「デバッグが効率的だ」と言える(言ってもらえる)ためには、次の二つ条件を満たせば良さそうだ。
    1) 不具合の発生条件の把握が容易である
    発生箇所だけわかっても、発生する条件が分からなければ、修正は難しいので、エラーが発生する条件というのは重要だと思う。よく使われる手段は、
    ・アサーション
    変数が期待値かどうかを確認するために
    ・エラーメッセージ
    理由と期待値をエラーログに出力する。不具合の調査をする場合、プログラムの識別子(クラス名だったり、関数名だったり)と、エラーメッセージをキーにして、レポジトリ検索すると、ソースコードにたどり着けるし、場合によっては、Web検索すると、同じ状況に遭遇したユーザコミュニテで有益な情報を得ることができたりする場合もある。適切でないエラーメッセージであっても、あるとないのとでは、その後の動作に大きく影響していると言える。

    2) エラー発生場所の特定が容易である
    エラーの発生箇所だけわかってもあまり意味はない(不具合が発生してる箇所に特段の問題がなくても、期待値と異なる結果になるケースはたくさんある)のだけれど、修正する上では、エラーの発生箇所を起点として、エラーの発生に至る経緯を確認することが重要だと思う。よく使われる手段は、
    ・スタックトレースをログに落とす
    発生箇所がわかると、最低限不具合を避けるコードを書くことができる(実際の「修正」には開発者のソースコードへの理解度、コード作成能力、作業に割ける時間などによってバリエーションがあるけど)。

    逆に、デバッグを遅くする要因としてありそうなのは、次ようなケースとも言える。自分が提供する立場になったら、避けたいところである。
    1) 不具合の発生条件が全く分からない
    エラーメッセージを出力することなく、いきなり異常終了してしまうケース。
    2) エラー発生場所の特定ができない
    スタックトレースなどの情報がない。プロセス実行時のメモリイメージ(コアファイルやヒープダンプ)などもない。

    なお、デバッグという作業のために、プログラムの設計図書を読み、プログラムに対する前提知識を持っておく必要は、本来ないはずである。プログラムの設計図書は、本来そのプログラム自体を開発・保守するのためのものだと思うから。当然プログラムの全体像を理解できていれば、それに越したことはないのだろうけど(例えばプログラムを作った本人のほうが、全く知らない人よりもデバッグが速いことの方が多い)、ソフトウエアの寿命は、開発者がそのソフトウエアに関与する期間と一致しないし、長い場合だってある。したがって、プログラムを開発する人は、エラーメッセージをきちんと出す、とか、エラー発生場所の特定できるようにするなどのことをきちんと実装しておかなければいけないと思う。そうすることによって、数万行あるソースコードであっても、また、そのソフトウエアを開発した人でなくても、デバッグができるので、長期に渡って使い続けられる。このことは、人間本来の強みである、時間を超越した「言葉」によるメリットを生かせる。結果的に、永遠に発展し続けることが可能となるはずだから。

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

全8件中 1 - 8件を表示

やねうらおの作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×