Debug Hacks発売記念講演 Debug Hacks Conference 2009へ行ってきた。
デバッグデバッグ
もうだいぶ経ってしまったけども、4/23のDebug Hacks Conference 2009へ行ってきた。
この本の内容は近々、必要になることではなく、もう少し未来に必要な内容だなぁと勝手に思っていたのだが、
そんなことを言ってる間に必要になる内容かもしれない。
自分メモとしていくつかメモを残す。だいたいの発表内容は本を見れば、わかるっぽい。
トラブルシューティングHacks
講演で気になったのは、具体的にどういうふうに対応するかのトラブルシューティングに関しての内容だった。
- 現場を保存する（写真を撮ったり、ログを取ったり、再現をするのに必要な作業）
- このバグの優先度を確認する（別にそこまでクリティカルでなければ、対応を後ですればいいかもしれない）
- いつまでに終わらせなければいけないかの確認
- 最悪のケースを想定する
- ストップロスを考える（止まっている間に発生するコストとデバッグにかかるコストの話だったと思う）
- 再現性の確認。エラーメッセージの確認（英語版のメッセージも確認）
- 人に任せたほうがいいか検討する（自分より適任者がいるかも）
- 困ったときに聞ける人、コミュニティを常に準備する
- 目的のために有効ならば、手段を選ばず
- １つずつ問題になりそうな要素を試す（環境をがらっと変えてやらない）
- 状態を変える（再起動とか）
- 実運用ではなく、クリーン環境で再現するか？（再現しなければ、徐々に実運用に近づけて検証）
話してたことの列挙。
結構当たり前のことも含まれているけども、ちゃんと出来ているかといえば微妙かもしれないので、ちゃんと意識していきたいと思った。
バグの優先度の確認なんかは自分は出来てないなと感じている。
バグの特定で苦労したら負け
最後にYuguiさんの発表で、バグの特定で苦労したら負けって話が面白かった。
テストをガンガン書いていけば、ほとんどバグが出ないで済むとのこと。
BDDとか新出単語を耳にしたのであとで調べないといけないなと感じている。
最後に一人一DebugHackというメッセージが託されたので、少しまとめてみようと思う。
My Debug Hack
最近、やっとテストを書くって行為を始めた。CppUnitとかがあればもっと高級に出来ると思うけども
自分のコードを見てくれる相手にもCppUnitが必要なので、今の状況では下記のようなマクロを使って、
テストを書いている。
#define RUN_TEST(func) if( func ){ std::cout << " 成功 (" << # func << ")" << std::endl; }\ else{ std::cout << "* 失敗 (" << # func << ")" << std::endl; }
単純に
bool TestHoge(){ return false; } void main() { RUN_TEST( TestHoge() ); }
こんなコードを書いて、テストコードを列挙するのが最近の状況。
普通はインターフェイスだけを書いて、実装をしていくのだと思うけども、実装しながらでないと考えられないレベルなので、少しだけ実装を書いてから、インターフェイスが固まったら、テストのコードを書いている。
基本的には単体テストでTestXXX（メソッド名）ってテスト関数が並ぶ状況。
C++のレベルが足りないので、まだこの程度。
テストコードが並んでくると、面白いことが自分の中で起きる。最初は失敗が並ぶわけだが、徐々にそれが成功に変わっていく。
なんだか、コードを書くゲームをしている気分になれる。
ちょっとテスト楽しいじゃんって思った瞬間だった。
