Some Days You Get the Bear

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

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

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

推察せよ、能動的に。

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

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

仮説を検証せよ。

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

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

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

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

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

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

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