読んでいる

プログラマが知るべき97のこと

プログラマが知るべき97のこと

本日もカテゴリ「バグとその修正」より

37 バグレポートの使い方 マット・ドーア

バグのレポートには、必ず次の3つのことを書く必要があります。


●バグの再現方法(できるだけ詳しく)と発生頻度
●本来の仕様(バグがない場合の望ましい動作。こうあるべき、という自分の意見でかまわない)
●実際の動作(完全でなくても、自分の記録した範囲で詳しく書く)


バグレポートはもちろん、バグについて伝えるものですが、レポートを見れば、書いたのがどういう人かも同時に伝わります。詳細で質の高いレポートを書けば、自分の評価も高まるでしょう。ぶっきらぼうに、怒りをぶちまけただけのレポート(「この関数は最低!」)などとしか書いていない)では、人格を疑われることにもなります。書いた人間がとても不機嫌であることは伝わりますが、ほとんど何の役にも立ちません。状況が詳しく説明され、バグが容易に再現できるよう配慮されたレポートならば、逆に皆の尊敬を集めるはずです。


バグレポートに関わらず伝えるべきことを伝えるには、共通前提と共通言語(文脈)とかこの辺はとても重要ですね。


例えば、コードのコメントで、JavaにはJavaDocコメントってのがありますが、このJavaDocがあるべきあり方通りに使われていれば、それはそれを学んだ人たちがいる場所ならば、どこへ持っていっても通用する訳でね。それを知らない人間には分かりもしないこと。その標準があるのに分からないというのは単なる怠惰なのでもちろん学ぶべきだし、学べるので楽と言えば楽なほう。コードのベストプラクティスとかももちろん同じだし、なんでも共通理解と共通前提ってのは大事なんでしょうね。それすら無かったら、議論の余地なしと。詳細に書いてくれてたところで、最低限の前提すら持たずにそれに対峙しても、何一つ伝わらなかったりするから。


「このレポートわかんねーなー 最低だなー」と思ってふと横を見ると、横のおっさんは深くうなずき納得顔だったとき、そしてその横のおっさんが明らかに自分より日々学んでいるものごとが多いのが明らかであるのであるならば、それは目の前にあるレポートが最低なのでは決してなく、横のおっさんが知ったかぶっているわけでも決してない。「さっきの発言をした俺ってずいぶん可哀想な人だったんだなー」ときちんと認識しましょうね。自戒ですよ。自戒。