ソフトウェアの品質は作ったプログラマへの信頼度に依存する

プログラミング（Programming）とは、プログラムのソースコードを作成することにより、人間の意図した処理を行うようにコンピュータに指示を与える行為である。 ソフトウェア工学においては、ソフトウェア開発工程の一部として扱われる。

プログラミング (コンピュータ) - Wikipedia

ふとしたきっかけからWikipediaの「プログラミング」を見つけ、読みふけってしまいました。プログラミング技術に関する説明が簡潔にまとめられています。関連して「プログラム」「プログラマ」「要求分析」「デスマーチ」などへのリンクが張られていて飽きないのですが、きりがないので今回はprogrammingに絞ることにします。：）

どれもなかなか興味深いのですが、特に以下の5つの属性の下りが印象に残りました。

ソフトウェア品質を確保する方法は様々だが、以下の5つの属性が最も重要である。
効率性
信頼性
頑健性
移植性
可読性

多くのプログラマがこれについて持論を持っていると思われますので、この記事ではyasuhoなりの持論を書いてみます。

ソフトウェア品質を確保する5つの属性

効率性

速度・効率・バイナリサイズ等については必ずしも最速・最小を求める必要はなく拡張性や利便性など他の要素も考えた上でベストと考えられるポイントを目指すべきであると考える。

利用する環境や言語は開発が進むほど変更することが難しいので、設計の初期の段階での見極めが重要。企画段階では出来るだけ多くの知識と経験を持つ人を動員できるといいだろう。

信頼性

何をもって「正しく」動くかどうかを判断することは難しい。たとえ動作が仕様通りであったとしてもそれに違和感を感じる人は必ずいるだろう。全ての人が納得する論理というものが存在しないように、全ての人が満足するソフトウェアも存在しない。

ソフトウェアの振る舞いが信頼できるかどうかはある一定のポリシーに従ってデザインされているかどうかであると思う。使っていくうちに「たぶんこの機能はここにあるな」とか「こうすればこう動くだろうな」という予想がしやすく、かつ期待通りに動くプログラムは使っていて安心できるし、信頼されやすいのではないだろうか。

頑健性

エラー処理はソフトウェアの最も難しい処理の一つだと思う。想定外の事象が発生した時どうリカバリーするか。プログラムが動作できないほどの致命的な問題なら単純に終了すればいいかもしれないが、可能であれば正常な状態への復帰を試みるべきである。例えばリソース不足時のリトライ、構文ミス部分以外の表示、など。やりすぎると新たなエラーを産むので注意が必要。

大事なことはエラーの原因と解決策をユーザに分かりやすくすること。次のアクションが明確であれば、人は安心するものだから。

移植性

たとえ他のプラットフォームに移植する必要のないソフトウェアであっても、移植性をよくすることは大切だと思う。移植性をあまり考慮していないソフトウェアは、言い換えると他のサブシステムや環境への依存性が高く、影響を受けやすいということである。ソフトウェアアップデートなどによる影響を少なくするためプログラムは他サブシステムとの結合部分を最小限にすべきであるとyasuhoは考える。

可読性

ソースコードが汚いからと言って必ずしもソフトウェアにバグが多いわけではないが、コードの可読性が低いということはプログラム内に多くの論理矛盾を含んでいる可能性が高いと思われる。通常プログラムは複数のプログラマが作るものであるから、それぞれがソフトウェアの設計ポリシーや方針を理解していないと、それぞれが違う論理のもとにプログラムを設計してしまう。そういったコードを読んで理解するのはなかなか大変だ。

もちろんプログラミング経験が少ないために読みにくいコードを書いてしまう場合もあるだろう。その場合も上記設計ポリシーが生きてくる。一番最初に書かれるコードは重要だ。最初に参考にするコードがよいものであれば、新人プログラマのコードもよくなってくるはず。

ソフトウェアの品質って何だろう？

よいソフトウェアを作るということは難しいです。上記はコーディングにおける注意点にすぎません。ソフトウェアの品質を決定するには他にも多くの要因があって、それぞれが複雑に絡み合っていることは業界の方ならよくご存じだと思います。そもそもいい悪いを決定づけるのは明確な指針がなくて、個人の主観によるところが大きい気がします。

じゃあソフトウェアの品質って何だろう？yasuhoが考えるに、それはソフトウェアを作った人への信頼がどの程度あるかということじゃないかと思うんですね。

プログラムは必ずミスをします。要求も人が多ければ多いほど際限がありません。バグが出た時、プログラマがすぐに直してくれたら嬉しいですよね。「こうなったらいいな」ということが次期バージョンで実現されたら、やっぱり嬉しいに違いありません。

とはいえ、何でもかんでも要求通りにすることがよいわけではありません。機能追加が多すぎると操作方法が煩雑になってきて、使っている方もだんだん分からなくなってきます。

大事なことは最初にソフトウェアの設計ポリシーを決めておくことではないでしょうか。機能追加をする時もポリシーに照らし合わせれば検討しやすいはずです。UIや全体のデザインも目標とすることがブレなければ、統一されたものになっていく。

こういった努力って、使っているユーザにも伝わっていくと思うんです。ソースコードは見えなくても「たぶんこれはこんな理由で変えたんだろうなあ」なんて分かるじゃないですか。バグがどのくらいの頻度で修正されているとかも見えるしね。

結局のところ、ソフトウェアが信頼できるかどうかは、裏でプログラムを作っている人に対する信頼なんじゃないかな、って思うのです。