デバッグパターン: うごかない、ほかうごくなら、ただひかく

ありがちなパターン

「動かないんですけど、原因が...」

という相談を受けまくるjfluteですが...

"一瞬解決パターン" がよくあります。

その典型例が...

他のクラスでは動いてるんです

他の書き方では動いてるんです

他の環境では動いてるんです

などなど、他では動いているというパターン。

ただひたすらに比較

もちろん、

"エラーメッセージを読んで推測する"

これが真っ先にやることです。jfluteの日記でも、何度も何度もそういうブログを書いてきました。

それでもパッとわからないとき...

「うーんうーん、さらに推測、機転をきかせて、仮説を立てて、うーんうーん」

じゃなくて!

動いてるのがあるんだったら、"動いてないもの" と "動いてるのもの" を、比較してみよう!

試してから逆算

ほら、これが違う。

「でも、それって関係あるんですか?」

関係あるかどうかわかんないけど、結果が違うんだから、とりあえず、そこを同じにして試してみようよ。

ふむぅ、とくに変わらないな。これは関係ないかもしれない。もう一つ違うところがある。これを同じにして試してみると...

あっ、結果が変わった。

ってことは、これこれこういうことだから...だから、こうするとこうなって、これが違うと動かなくなるんだ、あーなるほど。

...

試した結果から、逆算して、その原因の仕組みがわかることもあります。

動いてる似たものを探す

なので、動かないものがあったとき、似たもので動いてるものがないかを探します。それを聞いたりします。

「原因はなんだろう!?うーんうーん」

いいから似たもので動いてるものない?

あった瞬間に "ほぼ終わったな" って思ってしまうくらいです。比較できるものがあるとないとでは、あまりに難易度が違うからです。

でも、それをやらずに、壁の前で立ち止まっている人が多い、という印象です。

立派な機転はほとんど要りません。ただひたすら比較して検証するのです。

使う脳みそが違う

って聞くと、あまりにも当たり前のことではないでしょうか?なぜそれをやらずに突き進んでしまうのでしょう。

ひとつ思うのが...

"機転を利かせてアイディア待ちのデバッグ作業"

と、

"二つをひたすら比較して検証するデバッグ作業"

とでは、ストレスが違うからかも!?

前者は、楽しいですし、できるとかっこいいでしょう。でも、後者は多くの人にとってたぶんつまらないです。あんまりやりたいことじゃないし、そこに求められる能力も違うのではないかと思います。

自然と目を背けてしまうのかなぁ...とか。

仮説は検証の上にある

jfluteは、ここぞというとき、一時間二時間ひたすら後者をやり続けることもあります。試しづらい環境もあったり、違いがたくさんあり過ぎたり、どうにもこうにも手がかりがまったくないような現象もありますしね。

一時間二時間、雲をつかむようなアイディアのひねり出しをするのであれば...

一時間二時間、ひたすら比較分析をして、雲の切れ間を探します。

到達して解決したとき...

「おおぉ、さすがjfluteさん、これよくわかりましたね、すごい!」

とか言われたりもするのですが、地味なことをただひたすらやっただけで、あまり頭が良いわけではありません。でも問題は解決した、良かった。

jfluteも "仮説検証" を強く推していますが、"仮説検証" の "仮説" ばかりに気を取られてはいけません。"検証" という工程があるからこそ "仮説" が生まれるのです。

どっちにも楽しみましょう(^^

...

// 逆にテーブルスキャンもできなきゃね
http://d.hatena.ne.jp/jflute/20150112/tablescan

// 問題分析と問題解決を分けることがハマらない第一歩
http://d.hatena.ne.jp/jflute/20170712/analysissolving