Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

プログラマには想像力が必要だ(仮)

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

推察せよ、能動的に。

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

仮説を検証せよ。

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

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

 また、ある程度、複数の確認点を挙げておき、
 それを並行してつぶしていくことで、ツリーの分岐を絞り込むことができる。
 (あぁ、ここは絵を描きたい)

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

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

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

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