ソフトウェア開発のうえでのデバッグ技法について解説した本。 どこかで二重引用符(ダブルクォーテーション)でエラーメッセージを括ってググる方法ということが書かれてあると知って、その程度のレベルのことが書かれてあるのかなと思ったら、ほとんどかなり高度な内容だった。正直半分も理解できた気がしない。少なくとも、全部把握しようと思うならUNIXやアセンブラ程度の知識はあったほうがいいだろうなと思った。 Gitの「git bisect」というコマンドは初めて知った。問題のあるコミットを特定してくれるコマンドらしい。自分が関わっているプロジェクトでもようやくGitを使うようになったし、Gitの利用例はもう少し知っておきたいと思った。後は、Wiresharkについてももう少し使い方学んだほうがよさそうだなと思った。 寝てる間にデバッグして解を見つけるという手法は、台湾のオードリー・タン氏も似たようなこと言ってたなと思い出した。天才的といわれるプログラマは普通にやってることなのかもしれない。マネできる気がしないのだけど。 1つの欠陥を修正したら、同様の欠陥がないか探してあれば修正する必要があるというのは、そりゃそうだろうと思うけど、見落としがちだよね。自分も、前に修正したバグと似たようなバグが別の場所ででたことがあるので、分かる。気を付けたい。 ラバーダック技法というのはよく聞くけど、とにかく自分が書いたコードを言葉で説明するというのが大事なんだろうなと思う。これはでも、プログラミングのデバッグだけに限らないだろうなと思う。誰かに話したら、自分の中で解決することってあるだろうし。同じ類だよなと思う。 Javaで文字列の結合に「+=」を使うと遅くなるというのがよく聞くけど、逆アセンブルしたコードを見て納得。内部的には毎回StringBuilderを生成しているような動作になってしまうらしい。でもこれって、今でも何だろうか。これぐらい、コンパイラ側でうまく解釈できないものなのかと思わなくないのだけど。 ところで、この本はネットで購入したのだけど、3色のペンでメモ書きが書いてあってちょっとショックを受けた。メモ書きがある本を買ってしまったのは初めて。ネットで買うと中身確認できないからこういうこともあるのだなと思った。まあ、読めないことは無いからよかったけど。まあ、ほとんど最初の25ページだけなので、途中であきらめたのだろうなと思う(その後は１，２か所だけあったとは思う)。かなり丁寧で細かいメモ書きだったので、真面目な人なんだろうなと思った。

ソフト開発で不可避のデバッグのためのTips集。 プログラミング言語やドメインによらないかたちで66個の戦略・手法が紹介されている。 具体的なツール・技法等については紹介にとどまっているので、この本だけで使いこなせるようになるわけではないが、存在を知っていることでいざという時に選択肢に挙げることができるようになる。例えば、『opensslプログラムでは-nosaltオプションが用意されている（p.139）』ことを知り、類似の暗号プログラムのデバッグ時に似たようなオプションを探すことができたり、自分が暗号プログラムを開発するときには同様のデバッグオプションの追加を検討できる。 心構えとして挙げられている中で、特に刺さったのは、 ・『最初に、問題を特定して解決できると固く信じることが必要だ。（p.23）』 ・『最もよくあるデバッグでの間違いは、デバッグのためのインフラストラクチャを整備するための投資が不十分なことによるものだ。（p.24）』 理想論だけでなく、実際の現場での運用も見据えた書き方をしていて共感がもてた。 例えば項目１：「あらゆる問題を課題管理システムで扱う」では、課題管理システムの重要性を説いている。その一環として、不具合発生時の環境の情報が大事であることを述べているが、一方で環境の記述項目を増やして報告者の負担を上げることの弊害も書いている。ここにも記載があるように、検証対象ソフト側で把握できる情報については自動的に収集する仕組みを用意するなどしておき、報告者には報告者しか知り得ない情報をきちんと記載することに注力してもらうべきだ。 訳者あとがきも良い。 『デバッグとは、アドホック対応の塊（p.206）』 まさにそのとおりで、非常に抽象度を挙げることが難しいテーマだ。一方で、デバッグ効率が高い人と低い人は間違いなくいる。なんとか先人の知恵を吸収し効率を上げていきたい。