バグがないことが、よいプログラムの条件ではない

プログラムは、シンプルに、そして慎重に書くことが大切だと思います。
バグを出さないようにするのではなく、打たれ強いプログラムにすることが大切です。

プログラムはなるべくシンプルに書こう。これは他の人がコードを理解しやすくなると共に、自分が後でロジックを理解するのにも役立つ。

プログラミングの本などを読むと、よく｢プログラムは分かりやすく｣と書いてある。では、分かりやすいプログラムって何だろう。それはコードが単純であるということだと思う。

個人的にシンプルなプログラムと思うのは最初に思いついたアルゴリズムだ。ロジックは考えれば考えるほど技巧的になっていく。誰でも思いつくようなアルゴリズムが、結果的にはよいコードになることが多いと思う。

自分の書いたコードがシンプルかどうかは、一年後に見て見ればよい。もし全くコードが思い浮かばなければ、それはきっと難しく書いてあるのだ。よいコードが、すぐに内容を思い出せるし、改造もしやすい。

エラーハンドリングはけっこう面倒なものだ。成功することがほぼ約束されている場合。ついエラー処理を怠ってしまいがち。

だが、一般的にバグは想定外の値が渡ってくる場合に発生している。通常はあり得ないケースでも、万が一に備えてエラーチェックをしよう。そうすれば、想定外の値が来た場合でも、被害を最小限に抑えることができる。

エラー処理はなるべくシンプルに。あまり凝ったエラーハンドリングをすると、エラー処理中のエラーなど、バグ解析が難しくなる。

一般的にプログラムを全て自分の手で作ることは少ない。中には全部作ることもあるだろうが、それでもOSのサービスやライブラリを使っているだろう。全てを見渡すことは、なかなか難しい。

処理をそれほど深く理解しなくてもプログラムは動く。だが、バグは不意なところから発生する。細部に渡って全てを理解する必要はないが、関連するモジュールは、なるべく調べて使おう。

｢よくこんなんで動いてたな｣バグを見つけた時、こう思ったことはないだろうか。一生懸命考えて、多くのテストをしていても、人間誰しも単純ミスをする。レビューでは、このようなミスを見つけやすい。

特にバグが多く出る現場では、コードレビューをしてみる価値があるだろう。

以上述べてきたことは理想論かもしれません。開発に余裕があることは少なくて、実際には少ない時間で作業が行われることが普通です。うまく開発が進んでいても、急な仕様変更で、コードの見直しをさせられることも少なくないでしょう。

あと、これは私見ですけれど、あまりコード作成に時間をかけすぎるのは問題だと思います。コードをよく吟味することは大事なことですが、テストして見ないと分からないこともあります。プログラムの品質を高めるためにも、テストする時間は多く取りたいですよね。

なかなか時間の取れない開発の現場だからこそ、コードは慎重に書くべきではないでしょうか。慎重に書いたコードは致命的なバグも少なく、他のコンポーネントの影響を受けにくいものです。それが結果的には開発工数を少なくすることにもなるのではないかと思います。

そして、コードはなるべく単純に。シンプルなコードは分かりやすく、仕様変更も容易です。処理時間がシビアな環境もあるでしょうけど、クリティカルな部分はなるべく局所化したいものです。

バグを0にすることは不可能かもしれません。でも、プログラムを安定したものにすることは出来ます。バグを減らすことだけに注力するのではなく、不足の事態に遭遇しても簡単にクラッシュしない、打たれ強いコードにすることが大事ではないでしょうか。

プログラマyasuhoの隠れ家