良いプログラムであることの4つの条件

2011年のGWも終わってしまいました。夢のようなGWは、夢のようであるが故に儚く終わってしまいました。また社畜の日々が始まりますが、皆さんいかがお過ごしでしょうか。

さて、唐突ですが良いプログラムであることの条件とはなんでしょうか?

この手の話を始めると宗教戦争が勃発するので、よほど気の合うエンジニアか、もしくは酒の席で話した方が良いですが、今年からソフトウェア品質管理をとりしきるお仕事についたので、自分の考えを一旦整理しておこうかと思います。

僕の考える、良いプログラムの条件は以下の4つです。

  1. シンプル
  2. 読みやすい
  3. ドキュメントに頼らない
  4. 動く

1つずつ詳しく説明していきます。

1. シンプル

プログラムはシンプルな方が良いというのは割と言い古されていると思いますが、ではシンプルではないプログラムとはどのようなものでしょうか。シンプルの反対語は複雑なのですが、複雑なプログラムとはどういうものかとういうと、機能毎の結合が強いプログラムと考えます。

つまり、「プログラムは出来うる限り疎結合になっていた方が良い」ということです。疎結合になるよう十分意識されて書かれたプログラムであれば、ある1機能に対して見たとき、その機能が影響を与える、あるいは影響を受ける他の機能の数が最小になっているはずです。

疎結合になっていることによって、ある機能に障害や修正などが発生した場合にも、影響範囲が小さくなります。

2. 読みやすい

プログラマというのは面倒臭がりな人が多く、とにかくプログラムを書くときに楽をしようとする傾向があるように思います。その結果、書いた本人しか読めないようなプログラムが出来上がってしまうことも稀にあります。

忘れてはいけないのは、「プログラムは書く時間よりも読む時間の方が圧倒的に長い」ということです。

読みやすいプログラムとは、ズバリ、統一感があることです。例えば、ソースコードによってインデントの数がバラバラだったり、スペースの入れ方が異なっていたり、命名規則が整っていないプログラムは統一感があるとは言えません。

日本語の文章であっても、漢字の使い方や改行の仕方などに統一感がないと読みづらいと思います。しかし、一般的な文法を崩していても統一感がある文章であれば、最初戸惑うことがあったとしても慣れれば読みやすいはずです。

3. ドキュメントに頼らない

ドキュメントがいらないという意味ではありません。ドキュメントは大事です。しかし、ドキュメントがないと何が何だかさっぱりわからないというプログラムは良いプログラムとは言えません。

そもそも、ドキュメントはプログラムの動きそのものに関与しません。そのため、プログラムが修正されてもドキュメントが正しくアップデートされている保証はありません。ドキュメントがないのは困りものですが、諸悪の根源はドキュメントがないと読み解けないプログラムにあります。

よーく思い出してください。あなたが今まで経験した開発で、ドキュメントがちゃんと管理されていて、正しくアップデートされ続けていた現場ってどれだけありますか? 僕は恥ずかしながら、そのような開発現場は一度足りとも見たことがありません。。

4. 動く

お前は何を言ってるんだ、と思われた方もいるかもしれませんが、これは最も重要なことです。動かないプログラムはどんなに素晴らしいコードが書かれていてもゴミだからです。どんなにシンプルで、読みやすくて、ドキュメントが整備されていても、それは産業廃棄物です。 そしてそれは、今現在動いていることだけが重要なのではなく、未来においても動き続けてくれることが重要なのです。

例えば性能問題を抱えていて負荷が大きくなると動かなくなるようなプログラムは良いプログラムとは言えません。最近ではみずほ銀行、ちょっと前は三菱電機インフォメーションシステムズがやらかしましたが、高負荷や障害が発生しても出来うる限り速やかに正常な動きに戻せる、というのも良いプログラムの条件だと思います。

とすれば、プログラムは運用され始めてから役目を終えるまで、真に良いプログラムだったかはわからないということになります。ただ、良いプログラムは運用され始めてからエンジニアの手を煩わせることが非常に少ないです。そのため、良いプログラムはエンジニアに忘れ去られます。


以上、僕の考える良いプログラムの4つの条件でした。ツッコミなど大歓迎ですので、どしどしお願いします。