プログラムは二度書け

私がこのブログに記事を書くときには、まず内容を考えてから書き始める。しかし、書いているうちに、内容が最初に考えていたものと徐々に変わっていくようなことがある。「書く」ということで、意見や主張が頭の中で整理され、考えもしなかった結論に至ることもある。

「書く」ということは、「何かを伝えるための行為」であるだけではなく、「何かを知るための行為」でもあるのかもしれない。

結城浩氏や平鍋健児氏は、ソフトウェア開発でも同様のニ面性が見られることを指摘している（※）。もちろん、どんなソフトを作るかという大枠（企画、要件）は、最初に決める。しかし、具体的にどのように作るかということ（設計）は、実際にプログラムを書きながら見つけていく方が現実的（効率的かつ低リスク）であることが多い。

★

しかし、本来、誰かに何かを伝えようとすることと、自分が何かを知ろうとすることは全く違う。そういう意味では、この２つの「書く」という行為は、明確に区別して理解すべきかもしれない。

例えば、数学の試験問題を解くことを考えれば分かりやすい。答えを導くために紙の上で行う「筆算」は、まさに「知るために書く」という行為である。しかし、最終的に解答用紙に残すべきなのは、「筆算の跡」ではなく、綺麗にまとめられた「数式」だ。つまり、別途「伝えるために書く」という行為が必要なのである。

暗算が得意な人なら「筆算」は不要かもしれない。同様に、優れたプログラマであれば、一度の「書く」という行為で、これらの２つの目的を達せられるだろう。しかし、普通のプログラマにとっては、それはなかなか難しいことである。

実際、「筆算の跡」がそのまま残ってしまったようなソースコードは、世の中に溢れている。「もっと単純に書けるのに、なんでこんなに複雑な書き方をしているのだろう？」と思うような記述の多くは、プログラミング中に試行錯誤しながら何度も書き直したものが、そのまま残っているのだろう。

★

「知るため」に書かれたコードは、密林を切り開きながら作った道のように曲がりくねっている。密林を抜ければそれでいいじゃないか、と思うかもしれない。しかし、その道を後から通る者（コードを保守する者）のことも考えて欲しい。見通しの悪い道では、後から来る人がいつ獣（バグ）に出くわすか分からない。

試行錯誤によって道を切り開くことができたら、次には、その道を綺麗に整えることを考えるべきである。プログラムが動いただけで安心してはいけない。振り返ってみたら、真っ直ぐできるはずのところが曲がっていたりするものだ。

コードを綺麗にするということ自体は、そう難しいことではない。深呼吸をしてコードを読み返すだけでも、直すべきところをいくつか発見できるだろう（もちろん、美しいプログラムとはどういうものか、ということが分かっていることが前提だが）。より本格的に取り組むなら、「リファクタリング」について学ぶとよいだろう。

あとは、コードを他の人に見せ、指摘してもらうことである。もし、自分のチームに、ソースコードをレビューしたり、ペアプログラミングを行ったりする習慣がないのであれば、それらを取り入れてみるのもいいだろう。

応援のクリックお願いします →