かっこいいソースコードより、理解しやすいソースコード

趣味でプログラミングを楽しんでいる場合はどうでも良いのですが、仕事でのプログラミングは、メンテナンス性がとても大事です。

プログラムのメンテナンス性というと、「立派なドキュメント」「ソースコードに豊富なコメント」などを想像する人が多いかもしれませんが、そういう人はおそらくプロのプログラマーではなく、プログラミングを自分でできない・やらない人でしょう。プログラムはソースコードが真です。ソースコード以外は信用できません。なぜなら、ドキュメントやコメントは、正しいことを確認する方法が、目視チェック以外にないからです。ソースコードはコンパイラが文法をチェックし、さらに、そのままプログラムの動きとなって現れます。

さて、メンテナンス性の高いソースコードとは、どういうものでしょうか。まず、システムの規模によって多少異なる面があります。システムの規模が大きい場合は、多人数で一つのシステムを作り上げますので、多人数が関与しても問題が起きにくいようなソースコードが重要です。オブジェクト指向などはまさにこのためにあるようなもので、制約が多い言語を使い、想定外の使い方はできないように開発を進めていくことがメンテナンス性も高めます。

基本的に一人で作り上げていくようなプログラムの場合は、自分自身が全体を把握できるため、制約が多い言語を無理して使わなくても、想定外の組み方は避けることができます。人によって好みや主張が異なる部分ですが、私は「シンプル・イズ・ベスト」だと考えています。一人で作るプログラムは大抵、単機能で高性能あるいは短時間で作り上げることを要求されることが多く、凝ったことをしている暇はありません。シンプルな作りにしておけば、他の人が流用したい場合にも、簡単に理解して使ってもらうことができます。

「シンプルなソースコードなど簡単だ」と思うかもしれませんが、実際はそうでもなく、多くのソースは変に凝りすぎて本人以外が理解に苦しむ状態になっていて、凝ったソースほど、実は仕様変更や機能拡張の時にも苦しむことが多いものです。凝りすぎたものはバグも取りにくく、性能もUPしにくかったりします。

私の理想は、「ソースを流し読みするだけで、やりたいことが見えてくる状態」です。あまりにもたくさんのソースファイルを探さないと理解できない状態や、難解すぎるソースは読む気がしません。言語ごとに様々な制約やスタイルがあるものですが、それをあえて無視して、とまでは言いませんが、無理に従うことより、シンプルに読みやすいソースを書く方が、作る時間も短く、バグも残りにくく、性能も出しやすいと思っています。

ProDHCPのOEMをソリトンシステムズさんが決めてくれた一番のポイントは、ソリトンさんの技術のリーダーの方がソースコードを眺めて「これなら理解できる」と感じたことだそうです。シンプルで読みやすいソースコードは、とても大事なことなのです。私が作ったプログラムが大きな問題も出ずに、インターネットの重要な箇所などで使われている最大のポイントは「ソースがシンプル」ということだと思っています。私は頭が悪いので、そもそも難しいソースは書けないのが幸いだった、という感じですね！？