先日、高尾山に登ってきた。山登りに行くっていうのもガキのとき以来。なんか懐かしい雰囲気だ。なんで山に登ったかっていうと、運動不足の解消（笑）というのもあるが、もう1つ、最近プログラミングのほうで解決できないバグに悩んでいて、一度ちょっと頭の中を空っぽにしたかったのだ。

自分で書いたコードというのはなかなか厄介な部分がある。細部まで熟知しているはずで、もちろん実際にかなりの部分は把握しているのだけど、実は細部の挙動はいまいちつかんでいないっていうこともたまにある。こういうときは逆に、自分で書いたということが障害になる。コードを追いかけていってバグを探すにしても、なまじ毎日付き合っているコードであるだけに変な思いこみが発生する。この辺にはバグはないだろうって勝手に調査対象から外してしまったり、テストの仕方が甘かったり、なかなか真剣に探すことが出来ないのだ。人のコードを読むときのあの真剣モードになるのが難しい。オレもまだまだ未熟なもんである。

そこでどうするかというと、変な思いこみを頭から追い出すに限る。やり方は人それぞれだろうが、オレの場合はあちこち歩き回ったりして体にストレスをかけて、頭の中を空っぽにする方法を使う。普段は長距離散歩に出かけることが多い。今回はそれがたまたま高尾山だったというわけだ。

そんなわけで、一応ソースコードも印刷して持っていった。帰りに近くの温泉にでも行って、すっきりした頭でソースを見直してみようという魂胆。それが見事にはまった。見慣れたコードも新鮮なものに感じられて、あーこの行は余計なことやっているなとか、こいつらは別のクラスにできるなとか、スムーズにコードと向き合えた。東京に戻って[*1]コードを書き換えて、見事にバグも直ってくれたのだった。

「すべてのプログラムにはバグがある」という有名な言葉が表しているとおり、プログラマは日々バグと戦うのが仕事とも言える。コードを書いたらバグも入れてしまった、と思うぐらいでバランスとしてはちょうどいい。実際われわれがテストやデバッグ[*2]に費やしている時間は、コードを設計したり実際に書いたりするよりも多いのが普通だ。とはいえ、デバッグというのは言葉の持っている印象以上にしんどい作業であったりする。デバッグが好きというプログラマ仲間には、まだお目にかかったことがない。できたら簡単に済ませたいと誰もが思っている。

バグが取りにくくなる理由は、1つは機能が複雑なところにバグが入り込んでしまうからであり、もう1つはコードを書いてからバグが見つかるまでに時間が経ってしまっているからである。ということは、機能を単純にして、コードを書いてからすぐテストすれば、仮にバグが入り込んでも簡単に修正できるだろう。こういう考え方がここ数年、プログラムの世界では主流になってきている。

この考えを推し進めていくと「テスト・ファースト」という手法に行き着く。まずは、機能そのものではなく、機能をテストするコードを先に書くのだ。テストというのは具体的なデータや事象に基づいているものなので、先にテスト方法を考えてしまうということは、ある意味で設計もこなすということなのだ。なのでテストが先ということは時間の節約にもなる。全体を細かい部分に分けて個々にテストすれば、組み合わせても問題は起きない。

テストを行うことで、バグがないことを簡単に確認できるということは、コードを書き直すことが可能だということだ。動作にあまり自信がないと、「とりあえず動いているからいいか」という感じでほっておかれていずれバグが露呈する。今回のオレのバグはまさにそれに相当する。こういう事態を避けるために、意味が曖昧な部分や、もっとシンプルになる部分を見つけては、グリグリいじっていくのが1つの解決策である。これを「リファクタリング」という。本や雑誌で言えば編集に当たる作業だ。〆切ギリギリになって入ってくる原稿であろうと、編集者さんがちゃんと文字チェックして、要らない行は削り、全体の構成を変えてでも分かりやすいもの、意味の通るものに変えていく作業。それと似ている。

リファクタリングは、一段落したらやるものではなく、日々の行程で常に行っていくべきものだ。昨日書いた自分のコードでも今日見直してみると冗長だったりすることも多い。ほっておくと後で修正出来なくなってしまう。気が付いたときにやらないと取り返しが付かなくなってしまうのだ。

別の考え方として、そもそもバグを持ち込まない考え方をしようというのがある。バグにもいろいろあるが、タイプミスとかを除けば、たいていは根本的な考え方の間違いが原因だ。妙に複雑に考えて全体を把握できなくなっていたり、チーム作業の場合などはコミュニケーション不足から他人と考え方を共有できていなかったりすることが原因になる。

一度に考える範囲を細かく絞り込むか、逆に大雑把にしてみると、意外と以前やったことがある事例と似ていることが多々ある。そういう場合にはその事例のロジックが適用できるので信頼性が増すことになる。ということは、ある程度パターンを蓄積して、それをみんなで共有しておけば、考え方に起因するバグは減るだろう。こうした考えから「デザインパターン」というものが生まれた。すべての特効薬にはならないが、要らぬ努力をしてバグまで仕込んでしまう、という悲惨なことはだいぶ減る。

こんな感じで、いろんな手法が最近のプログラマの世界ではかなり常識になりつつある。どれもあまり経験のない人にとっては使いこなせないものだが、1つのよりどころとなる手法だとは思う。あとはコミュニケーション能力を鍛えて、たくさんの失敗を繰り返すことが大事なのかな。勘っていうのはそういう経験すべてが積み重なってできるものなんだろうな、と思います。

バスケ 有限会社シエスタウェア（http://saryo.org/basuke/）
ちなみに、今回のこのコードというのは、昨年暮れに屋久島に行ったときに書いたそのときも自然の中に身を置いているウチに、すごいアイデアが沸いてきていても立ってもいられなくなり、旅館に戻って映までの短い時間に書き上げました。いいコードが書けるときって、不思議とこんなシチュエーションが多いもんです。

[*1] 東京に戻って - 高尾山も東京です（笑）。
[2] デバッグ - プログラムのバグを取る作業。