プログラミングの試行錯誤と最後の手段

　夜風を取り入れるために窓を開けると、蛙の鳴く声が聞こえた。もうしばらくすると蚊が入ってくるようになるので、この空気を味わえる季節は長くはない。遠くから聞こえる、表現しがたい滑らかな音は風の音だろうか。あまり考えたこともなかったが、風の音にも色々な種類があるものだと感心した。

　特別な話題もないので、仕事のことを思い浮かべる。他の人と協力する仕事がちらほらとあって、なんとなく人がプログラムを書く様子を見ていた。書いたプログラムが一発で動くのは稀なことで、たいていの場合は、ああでもないこうでもないと試行錯誤することになる。

　一つ目。プログラムを一行ずつ読んで間違いがないか探す。誤字がないか、命令が漏れてないか確かめる。だいたい自分でプログラムを書いたばかりなので、間違いはみつからない。

　二つ目。似た処理をしている箇所を真似してみる。よく知らないライブラリやフレームワークを使うときには、よくやる。確かな根拠があってそうしているわけではないので、動いても動かなくても理屈はわからない。もし、それが成功したなら、失敗した時と何が違うのかを確かめるのが好ましい。雑にこれをやると、コピペが氾濫してプログラムは著しく劣化する。

　三つ目。プログラムを少しずつ変えながら実行する。入力を変えた時に、出力がどのように変化するかを観察する。変数をプリントする、というデバッグ方法は、これに当たると思う。

　四つ目。ググる。エラーメッセージが出ているならそれを使ってキーワード検索する。英語が出てきても逃げずに良さそうなところを探す。個人の日記は信頼性に難があるので、ほどほどに見る。技術を提供している公式のドキュメントを見るのが安全（公式がクソな場合もあるが、その場合は技術の選択を誤ったのだと思う）。技術者向けの質問サイトでも良い。ここでの調査の質が最後の手段の説得力に関わってくる。

　五つ目。先輩や同僚に泣きつく。相談の体でもよいが、愚痴気味に声をかけるという手もある。こんな方法やあんな方法を試したけれどうまく行かなかった、と語る。とにかく話を聞いてもらう。何かヒントになることが得られれば良いが、そうでなくても良い。少なくとも「自分以外の人でも、動かない原因は突き止められなかった」という安心感が得られて、次のステップに進むことができる。

　六つ目。諦める。採用しようとした方法は、ダメな方法だったのだと割りきって、別の解決策を探す。たとえば代わりとなるツールを探すとか、別のライブラリを使うとか、設計が変わっても仕様が満たされれば良い。それでも実現できないか、実現するのが果てしなく面倒な場合は、仕様を変えることもあるかもしれない。仕様を変えるには、仕様が変わっても目的が果たされることを説明しなければならない。

　だいたい順番は入れ替わり戻ったりもする。人によってはもっと別なアプローチがあるかもしれない。なんとなく新入社員や学生の世話をしてみた感じでは、彼らは五つ目と六つ目の方法を取らないことが多い。声をかけてやると、だいたいそういう流れになるけれど、自分から踏み込んでくる人はほぼいない。

　相談できない理由はいろいろ考えられる。話しかけるのが怖い、説明が下手でどもる、失敗しているのを見られたくない、とか色々。それでも、相談という手法は強力なので、できれば使ってほしいと思う。