GDBと作業プロセスの記述の重要性

GDBは積極的に活用しないと、もったいない。

今では、そう思うようになりました。

GDBをさわるようになるまでは、C言語で実装したプログラムのデバッグは、いわゆるprintデバッグで行うことが多かったです。printデバッグは簡単だし、ちょっとしたデバッグをしたい時には、今でも便利な手法だと思っています。

でも、GDBが段々使えるようになり、printデバッグ以上に、GDBが便利なツールだということに気がつきました。今振り返ると、場当たり的なprintデバッグに頼りすぎて、GDBを勉強する、言い換えると「プログラムを理解する」機会を自ら妨げていたように思います。

プログラムの理解力とデバッグの技術をさらに磨きたい方は、GDBを積極的に活用していけば、スキルの幅が格段に広がるのではないでしょうか？

僕も引き続きGDBと一緒に、勉強してみます。

参考

ユメのチカラ: gdbの実践的使い方

さて、このエントリではGDBに加えて、もう１つ言いたいことがあります。それは、作業プロセスの記述の重要性についてです。

デバッグプロセスの記述の重要性に気がついたきっかけは、DECONで高林さんが紹介された「Binary Hacks in Action」の中にあった「WEBRickをGDBでいじる」という話題です。この話題のおかげで、GDBで遊んでみようという気になりました。

なぜそのような気になったのか、ちょっと考えてみました。高林さんの教養の高さとスライドの内容自体が大変興味深いというのも、その要因として大きいとは思います。でも、やっぱり一番大きかったのは、「誰でも再現できるように作業プロセスが明記されていたこと」です。作業プロセスが明確に記されていなかったら、GDBを全然操れなかった自分としては、多分、GDBで遊んでみようという気にはならなかったことでしょう。

つまり、作業プロセスの記述の仕方によっては、それを読む側の人間を大きく動かす(成長させる)武器になるということが言いたいのです。(「プロセスを共有することは大切」という考えは、ミラクルリナックスのCTOの吉岡さんのブログの影響が大きいです。)

世の中のエンジニアの各自がお互いに、blogのようなツールを使ってオープンにさまざまな問題の作業プロセスを共有する動きが活発になっていけば、非常に面白い世界になりそうな気がします。