科学的なDebug - 主に学習備忘録

Udacity の「Software Debugging」を見た

まだ前半だけど

内容は簡単には「デバッグをする際には気合と根性で調べるのではなく、仮説を立て、検証すること」

というもの

講義内では explicit debug と呼んでる手法

どういったものかというと

先生「仮説を書き出して一つ一つ確かめること。何も書き出さずにデバッグするのは目隠ししながらマスターマインド（数当てゲーム）をするようなもの」

これは覚えておこうと思った。絶対に書き出して検証しないと、無理。目隠ししてゲームできるわけがない。

そりゃパッと見て治せればいいけど、最初の５分だけにしなさい、とのこと。それ以降は仮説検証をすべき。

これがまず絶対としてじゃあ具体的にどういう風にやればいいか？

何かバグが起きていたとして

　　・何を期待して

　　・何が起きていて

この二つから →「じゃあ何がどうなっている」と推測する。これが仮説。

当たり前と言えば当たり前。

これを一個一個潰していく、というのが趣旨。

仮説の正否を確認し、仮説のリファインを繰り返す。

これらを書き下していく。

講義内では assert を入れたりして検証してたけど、必ずしも assert で確かめないといけないわけでもないだろうとは思う。

ただ、変数の中身を見たりするにも全て「何を期待してどうなってて、そこから推測したこと」これを書き出して確かめれば、それで explicit debug になると思う。

automated simplification

再現の簡略化を自動化。手作業でやるな、と

Assertion

Assertion の使い方。不変条件について。

また、不変条件は自動で取得する。traceit を使う、だっけ

具体的にはまた次回

よく言われてるけど、デバッグは開発の50-75%を占める、と。割合とはか曖昧だけど、要は多大な労力を要するわけで。

俺は仕事遅い遅い言われてるけど、だからってミスはしてはいかんわけで、せめて効率を上げないとなあ、と思った次第。

絶対、仮説検証の形をとらないと、効率は上がらない。これだけは確か。

この講義、半年ぐらい前には見てたんだけど今一そこがわかってなかった・・・毎回 assert するのは手間だなあ、ぐらいに思ってた。

目隠ししてマスターマインドするようなことはないようにしないとなあ、と思った次第。

続きはまた次回