デバッグ能力

artonさん所から

デバッグ能力

何かそうじゃない別のものもあるような気がします。

おくじさんのところ。思い当たる点がある考察。確かに不思議だ。

デバッグ能力は、プログラマが持つ不思議パワーの1つです。
只、まぁ、不思議とは言っても、技巧と心理分析の組み合わせかな…とか、
思ってます。

僕は、数学的な方法ではバグは効率良く見つける事は出来ないと思っています。
特に火事場では。
まぁ、数学的な方法でバグを見つけられるなら、まだ、結構何とかなる状況かな…と思います、経験上。
ま、そもそも、火事場でバグを探してるって状況が既に何か色々ヲカシイ訳ですが…。
それはさておき。

コーディング上のバグと言うかバグパターンに当てはまる様なのは、
それこそFindBugsで見つければ良いのです。
あ、artonさんの本が最近出ましたね。アレです。

僕がデバッグする時に重視するのは、
上手く明文化出来ないのですが、「誤解パターン」みたいなやり方です。
もちろん、スタックトレースやらコアダンプやらそういう当たり前の情報と、
該当個所の前後数百行にバグがあるなら、そりゃ簡単。
「エイっっ」ってなもんです。

感覚的に…ですが、過去に自分でやった、もしくは、
誰かがやった仕様の誤解、インターフェースの誤解を、経験として蓄積しています。
そして、何とも怪しい書き方ですが、「誤解パターン」には流れがあります。

スタート地点は、バグとして表面化した部分と、
直接的にそれに関わる部分の設計/実装をした人間との対話から始まります。
まぁ、掛かっても１〜２分の世間話です。*1
目的は犯人探しじゃありません。認識がズレてる所を探すのです。
そして、コードをCVSにコミットした人間で、
自分の書いたコードについて微細に渡って思い出せない人を探しだすのです。
書いたコードの内容を思い出せない人が居る部分は大抵澱んでいます。

そこで、初めてコードを見ます。ちょっと遠目で。
変数名までは分らないけどコードブロックは何となく分る、位の感じですね。
暗黒の力が蠢いている部分がある筈です。
そこが、正にバグか、もしくは、バグと直接的に関連している部分です。
これが、僕の「当たりを付ける」ってやつかな、と。

ポイントは、いきなりコードを見ずに、コードを書いた人間を見る事。
仕様を書いた人間と、コードを書いた人間のやりとりを観察する事。
そして、コードに入り込まない事。
です。

バグってんのは、コードじゃなくて人間だぁよ。

*1:僕は、主に喫煙所で本人達の無意識下から引き出す様にしています。