バグデータベースを読む(その２)
バグデータベースを読む人の立場から、すなわちバグを直す人の立場から、バグデータベースの書き方のコツを一つ二つ。
バグと思われるものを発見したあなたはどのようにバグを報告するか？あなたはその問題を解決してほしいとせつに願っている。
- 現象の記述
- 再現方法の記述
- 期待される結果
最初にやることは現象をあるがまま報告する。次にその現象を再現する方法を明確にかつ簡潔に記さなければならない。その現象を再現するのに必要なOSのバージョン、ソフトウェアのバージョン、その他関係しそうな事を厳密に記す。そして再現方法を逐一記述する。
最後に本来期待される結果を記す。XXXでYYYするとZZZとなるが、AAAという結果になるべきである。
ここから開発者(バグを直す人)とコミュニケーションが開始されるのである。バグを直す立場から言うと再現方法の書いていないバグを修正することは非常に難しい。コミュニケーションの密度、スピードを加速するためには、明確に記述した再現方法が必須である。バグを通して利用者と開発者は会話をしている。共通の理解をするために、バグの再現方法は重要である。バグを再現できればその問題について９割方解決したと言っても過言ではない。デバッグの最初のステップは問題を正しく理解し、バグを再現することだ。そしてバグを再現できれば最初のステップはクリアしたことになる。
開発者はその実装について詳細をしっているので現象をみれば多くの場合、ほとんど瞬時に原因を特定できる。問題の８割はそのような簡単な問題であると言う事を経験論は示している。残りの２割はソースを読んで詳細を検討しないといけないような問題である。
それはともかく、期待される結果と現象の差を利用者はバグと認識するわけだが、開発者がそれに同意するとは必ずしも限らない。ZZZという結果は仕様である。修正しないという宣言である。これについてはまたまた後日記す。
