Effective Debugging ―ソフトウェアとシステムをデバッグする66項目
- オライリージャパン (2017年6月24日発売)
- Amazon.co.jp ・本 (252ページ)
- / ISBN・EAN: 9784873117997
作品紹介・あらすじ
デバッグに役立つ考え方、方法論、アプローチ、ヒントなど66項目を提示!
『Code Reading』『Code Quality』の著者として、また『ビューティフルアーキテクチャ』編者として、さらに数多くのオープンソースの開発や教育に貢献著しいディオミディス・スピネリス氏の最新刊。デバッグに対する心構え、方法論、戦略、テクニック、ツールなど、さまざまな角度からデバッグの本質に迫ります。デバッグ手法を体系的に網羅、すぐに応用できる具体的な例も多く挙げられています。作業効率と品質を向上させたい全プログラマ必読の書籍です。
感想・レビュー・書評
-
普段、コードレベルのデバッグはしないのですが、障害に対する調査の姿勢など、勉強になりました。
細かいレベルも見るようになったら、また読み返したい。詳細をみるコメント0件をすべて表示 -
ソフトウェア開発のうえでのデバッグ技法について解説した本。
どこかで二重引用符(ダブルクォーテーション)でエラーメッセージを括ってググる方法ということが書かれてあると知って、その程度のレベルのことが書かれてあるのかなと思ったら、ほとんどかなり高度な内容だった。正直半分も理解できた気がしない。少なくとも、全部把握しようと思うならUNIXやアセンブラ程度の知識はあったほうがいいだろうなと思った。
Gitの「git bisect」というコマンドは初めて知った。問題のあるコミットを特定してくれるコマンドらしい。自分が関わっているプロジェクトでもようやくGitを使うようになったし、Gitの利用例はもう少し知っておきたいと思った。後は、Wiresharkについてももう少し使い方学んだほうがよさそうだなと思った。
寝てる間にデバッグして解を見つけるという手法は、台湾のオードリー・タン氏も似たようなこと言ってたなと思い出した。天才的といわれるプログラマは普通にやってることなのかもしれない。マネできる気がしないのだけど。
1つの欠陥を修正したら、同様の欠陥がないか探してあれば修正する必要があるというのは、そりゃそうだろうと思うけど、見落としがちだよね。自分も、前に修正したバグと似たようなバグが別の場所ででたことがあるので、分かる。気を付けたい。
ラバーダック技法というのはよく聞くけど、とにかく自分が書いたコードを言葉で説明するというのが大事なんだろうなと思う。これはでも、プログラミングのデバッグだけに限らないだろうなと思う。誰かに話したら、自分の中で解決することってあるだろうし。同じ類だよなと思う。
Javaで文字列の結合に「+=」を使うと遅くなるというのがよく聞くけど、逆アセンブルしたコードを見て納得。内部的には毎回StringBuilderを生成しているような動作になってしまうらしい。でもこれって、今でも何だろうか。これぐらい、コンパイラ側でうまく解釈できないものなのかと思わなくないのだけど。
ところで、この本はネットで購入したのだけど、3色のペンでメモ書きが書いてあってちょっとショックを受けた。メモ書きがある本を買ってしまったのは初めて。ネットで買うと中身確認できないからこういうこともあるのだなと思った。まあ、読めないことは無いからよかったけど。まあ、ほとんど最初の25ページだけなので、途中であきらめたのだろうなと思う(その後は1,2か所だけあったとは思う)。かなり丁寧で細かいメモ書きだったので、真面目な人なんだろうなと思った。 -
帯にあった一文がささりました
「最初に、問題を特定して解決できると固く信じることが必要だ」
内容は実践的で有用なものでした -
ソフト開発で不可避のデバッグのためのTips集。
プログラミング言語やドメインによらないかたちで66個の戦略・手法が紹介されている。
具体的なツール・技法等については紹介にとどまっているので、この本だけで使いこなせるようになるわけではないが、存在を知っていることでいざという時に選択肢に挙げることができるようになる。例えば、『opensslプログラムでは-nosaltオプションが用意されている(p.139)』ことを知り、類似の暗号プログラムのデバッグ時に似たようなオプションを探すことができたり、自分が暗号プログラムを開発するときには同様のデバッグオプションの追加を検討できる。
心構えとして挙げられている中で、特に刺さったのは、
・『最初に、問題を特定して解決できると固く信じることが必要だ。(p.23)』
・『最もよくあるデバッグでの間違いは、デバッグのためのインフラストラクチャを整備するための投資が不十分なことによるものだ。(p.24)』
理想論だけでなく、実際の現場での運用も見据えた書き方をしていて共感がもてた。
例えば項目1:「あらゆる問題を課題管理システムで扱う」では、課題管理システムの重要性を説いている。その一環として、不具合発生時の環境の情報が大事であることを述べているが、一方で環境の記述項目を増やして報告者の負担を上げることの弊害も書いている。ここにも記載があるように、検証対象ソフト側で把握できる情報については自動的に収集する仕組みを用意するなどしておき、報告者には報告者しか知り得ない情報をきちんと記載することに注力してもらうべきだ。
訳者あとがきも良い。
『デバッグとは、アドホック対応の塊(p.206)』
まさにそのとおりで、非常に抽象度を挙げることが難しいテーマだ。一方で、デバッグ効率が高い人と低い人は間違いなくいる。なんとか先人の知恵を吸収し効率を上げていきたい。 -
6割くらいはデバッグのセオリー。どれもプログラマならやったことあるよねというような話(たとえば、ソースコードの変更点からバグを追ってみる、とか)だが、その手段をいつでも一覧で見られることに価値があると思う。
残りはさまざまなデバッガを使った厳しいバグ(ローレベルのレースコンディションのデバッグなど)のデバッグ方法について。こんな手があるということだけでも目を通しておくとよさそう。
さらっと読めるので一通り読んでおくとよいと思う。
保護されてないメモリ空間の話も多く、特定のプラットフォームに依存しない話もかなり出てくるので、特定のIDE上やWebフロントエンドでアプリを書いてる人には向かないと思う。 -
貸し出し状況等、詳細情報の確認は下記URLへ
http://libsrv02.iamas.ac.jp/jhkweb_JPN/service/open_search_ex.asp?ISBN=9784873117997