事件は会議室で起きているんじゃない！

日記

ソフトウェアにはバグが憑き物(気が付いたら居るよね...)。個人的な感覚では、二分探索をでっかい範囲でやっているような感覚だ。バグに気が付くということは、基本的に 「何か」をやったら、「結果」になった。時間が経つと出る場合も、「時間が経つ」と「結果」になった。ということか。そして、その間を順番に切り分けて、問題箇所を算出する感じだ。

  入力 ----LogA-------LogB--------LogC--------LogD-----> 結果(おかしい)
 　　　<--------- この間のどこかに犯人がいる ---------->

LogCが怪しい(予想と違う)ような場合は、LogBとLogCの間に何かある。このあたりは、個々の製品や、大まかな動作がわからないと絞り込めない。

  入力 ----LogA-------LogB--------LogC--------LogD-----> 結果(おかしい)
                        <-- この間 -->

ログだけとは限らないが、その間のログを確認し、無実の方々は釈放し、限りなく黒に近い方を探していく。結局、ソフトウェアは、論理的に動作するから、たまたまというやつも、あるタイミングで、またはある数字になったときなど、仮説を立てる。これらの仮説を立てていき最も説明が付くパターンからその立証を行い、動作を確認し、犯人に迫る。そのときに、自分の道具箱に何があって、これをどうやって使えば、こんな情報が得られるので、これを試してみようということになる(osのコマンドとかアプリがどんな風に動くとかソースがどれとか)。これを繰り返し、自分の仮説と、実際の動きでの対話を行い、真犯人に迫っていく。

  入力 ----LogA-------LogB--------LogC--------LogD-----> 結果(おかしい)
                              A
                              |
                      この辺に犯人が居た。

そして、絞り込んだ先にあったものが、無罪が有罪か。結局デザインとして仕様なのか、それとも明らかに論理的にやりたいことと違うよねということで、有罪か。何をやりたいのかわからねーか。まぁ、そんな結論にたどり着く。その後、修正をする場合、その変更がどこまで影響をするか検証し、影響を最小限にするか、ガツンと変更しちゃうか。。。そこら辺のさじ加減は、難しいものである。


ログが無ければ、絞り込むためには、ソースにすぐ当たらないと(適当に真ん中あたりでデバッグコードをしかけるとか)いけないかもしれないし、ログが多すぎると、そもそも絞り込みの対象までたどり着けないかもしれない。また、無駄にログが出ても雑音になることもあるしね。この辺も、経験値に左右されそうだ。