プログラマには想像力が必要だ（仮）

まだうまく「キーワード」化できていないのだけど、
消える前に書き残しておく。
そのうち整理して、ちゃんと言語化したい。ノウハウや観点にしたい。
　　
デバッグのコツ。というか「やり方」。
もっと言えば「プログラミングという行為」について。

推察せよ、能動的に。

　まずは推察。「ここはこうなっているはず」「こう動いていると思う」というのを、
　デバッガで追っかけてみて把握するんじゃなくて、
　「仕様」や「システムの特性・特徴」や、「プログラムとはこういうものだから」の観点で考えてみる。
　「考えてみる」のが大事。

　わかりにくければ、コードを動かしながら「探ってみる」のも
　早く手がかりをつかむコツではあるけれど、
　ここではあえて「しくみから考える」ことを推したい。
　コードだけじゃなくて、しくみや目的から「こうあるべき」の観点を持ってほしいからだ。
　つまり俯瞰した大きな視点を持ってほしいのだ。

仮説を検証せよ。

　さきほどの「はず」を確認する。
　前準備もなくて、単にデバッガで追っかけて「こうなっていた」では意味がない。
　仮説や事実を１つずつ挙げながら、実際にどうなっているかを確認するのだ。

　こんなときにはTOCの現状構造ツリーだ、などと思う。

　いくつか複数の確認点を挙げておき、
　それをひとつずつつぶしていくことで、ツリーの分岐を絞り込むことができる。
　そうやって原因に近づいていく。

起こりえないことも考えてみる

　仮説が出てこなかったら、あるいは仮説をつぶしていっても答えが出てこなかったら、
　さらに「こうじゃなかったら、じゃあ何があるのか」と問うてみる。
　順に事実を突き詰めるだけでなくて、
　思ってもみないことが起こっていないか、と考えて、それを検証してみることもある。
　「通常はありえないはずだけど、もしもここがこうだったら、
　こういうことが起こっているのかもしれない」って。
　目の前のものから少し距離を置いて、少し離れて、引いて、考えてみる。
　ただ闇雲に目の前のコードを追いかけるのじゃなくて、
　思いもよらないところで、何かが起こっていないかと「想像」してみる。
　直接のバグの原因でなくても、現象を把握するヒントになるかもしれない。
　いろんな情報を得て、そこから推察することも、また大事なのだ。
　　
だから、想像力が必要なのだ。
特に自分じゃない誰かがつくったものなんて、どこでどうなっているか
見当もつかないときさえある。
そんなのをまともにあたまから追っかけてては、いくら時間があったって足りやしないじゃん。

「まずは　「こうなってる「はず」だから」　ここいらへんから」、って目がないとね。

こういうところを「感性」だと思ってしまうときがある。
単なる「経験値」の違いにしては、なんか違うな－、と思ってて。
感性というよりは「発想」かなー？
あるいは、近道しよう、時間かけたくない、ラクしたい、
そういう想いの量の違いかなー、と思ってみたりする。
　
seichi23.hatenablog.com