2014/12/16プログラマなら誰しもが優れたプログラムを書きたいと思うだろう。これまで作ってきた自分のプログラムはどれもすばらしいものだった、と言う人もいるかもしれない。そもそも「優れたプログラムとは一体なんなのか」という問いに答えることは非常に難しい。プログラムの価値は、そのプログラムを取り巻く環境によって様々に変化するからだ。すれば必ずや万人が「優れている」と認めるような唯一無二の純然たる解はない。あるのはそれぞれの立場からの相対評価と、どれだけ多くの人がそのプログラムに価値を認めるかということだけだ。企業の理念・存在意義は社会奉仕である。役に立つソフトウェアを売り、社会に貢献し、利益を得る。ソフトウェアは企業活動の結果生み出される生産物であり、人々に使われて初めて価値が生まれる。プログラムを「ソフトウェアを生成するための存在」だと定義するならば、ニーズのないソフトウェア(の元となるプログラム)はただのガラクタだ。プログラマならこの意見に強烈な拒否反応を示すかもしれない。生産物の価値だけがプログラムの評価基準だなどと言うつもりはない。ソースコードそのものにも研究や学習、教育といった分野におけるニーズが存在するからだ。我々のようなソフトウェアを延々と開発し続けなければならない側の人間にとっては、バイナリ化された実行モジュールよりもソースコードの方に価値があることは言うまでもない。優れたコードは、それがコンパイルされようがされまいが、我々にとって非常に重要な存在なのである。プログラマであれば、この辺りの話は主に技術的側面に論点が集中するだろう。アーキテクチャやアルゴリズム、生産性や性能といったような部分である。思慮深い人であれば芸術性にまで言及する人もいるかもしれない。美的センスがコードの体裁に大きく影響することは皆さんもご存知のことだろう。ここで注意しなければならないことは、ソースコードの評価は相対的に変化するということだ。受託されたソフトウェアが顧客の要件を満たしているか否かという視点に立って考えてみるといい。要件を満たしていないプログラムは、その設計思想やアルゴリズムがどんなにすばらしいものであろうとも優れたプログラムとは言えない。それは間違ったプログラムであり、修正されるべきものだ。逆にこのアルゴリズムだけを取り出してどこにでも使える共通部品にしたとすれば、この部品は優れたプログラムと言えるかもしれない。顧客要件、すなわちソフトウェアの用途によってプログラムの優位性が正反対に変化するのである。不特定多数の集まるBBSやメールグループなどで純粋な技術論が噛み合ってない状況を見かけるが、これらの多くは互いの想定している環境や目的が異なっていることに起因している。テストツールを作っているのとフレームワークを作っているのとでは、作り方のセオリーはまるで違う。したテストツールを作るためにグローバル変数を使わないことがはたして「優れている」と言えるだろうか。このようにプログラムの優位性はソフトウェアを取り巻く環境によって大きく左右され、ソースコードただそれだけを見て評価ができるというわけではない。技術論は複雑な問題の発生しやすい、より大規模で、より長期間のプロジェクトにおける開発を想定して行うべきであり、できれば実際の場面やどのような状況での話かをきちんと決めた上で議論した方が良い。ここにプログラムを語る上での難しさがある。プログラムは純粋な数学などではなく、したがって工学的に語られるべきだ。上述のような外的要因の話と純粋な技術論とを切り離せない理由は他にもある。その1つにソフトウェア要件がプログラムの設計に大きく影響するということが挙げられる。されていればそれでいいというわけではない。これらを進めれば進めるほど開発量は増え、コードは難解になり、アクセシビリティは低下する。共通関数の汎用化を進めていくと引数が増え続けて使いづらくなったり、実装クラスが1つしかないinterfaceがやたらと出てくるようなプログラムは、不要なインプリメントをやめてもっとシンプルなコードにできるはずだ。行き過ぎを押さえなければならないが、これには想定されないデータや拡張可能性の排除が必要である。これはソフトウェアが対象とする実際の業務をある程度熟知しておかなければできないことであり、そういう意味ではプログラムの設計は本来(プログラミングに精通している前提で)上流従事者がやるべきものだと私は思う。優れたプログラムとは、その用途や規模、環境や経緯などの外的要因を考慮し、適度に抽象化・汎用化され、適度に疎結合化されていること、そのバランスを見極めることで作られる。ある一定レベルにまで達したプログラマには、このバランス感覚こそが最も必要な能力となる。バランスを欠いたプログラムは総じて独善的で一人よがりだ。