81-エラーがエラーを相殺してしまう

「プログラマが知るべき97のこと」の81個目のエピソードは、不具合に関する話です。ソフトウェア開発では、可能な限り不具合を減らす為に様々なテストを行います。テストにはクラスやモジュール単位で行うユニットテストもあれば、最終的にユーザが受入を判断するユーザ受入テストまで様々な粒度で、ソフトウェアが期待しない動きとなっていないかを検証します。
しかし、どんなテストをどれだけ実施したとしても、基本的にはテストが通るという事がソフトウェアが正しく実装されているかの証明となりません。例えば、あるメソッドがtrueを期待されるところでfalseを返す明らかな不具合があったとします。一方、そのメソッドを呼び出す側で、trueと判定される場合にやらなければならない処理があるとします。しかし、間違えてfalseの時に行うようコーディングされていたとしたならば、結果として期待される挙動になってしまいます。このようにエラーとエラーが相殺され、結果として正しい動きのようになる事があり得ます。
この問題はたくさんのモジュールが大量の不具合を抱えている場合に取り返しの付かない状態になります。納期に追われ、システムテストを通す事を目的としてコードを修正する、そんなソフトウェア開発が存在します。ある不具合を直すために別の所を修正すると、また新しい不具合が発生するでしょう。気付くと誰もメンテナンスできなくなってしまいます。プログラマは常にエラーがエラーを相殺するという事が起こりえるということを忘れてはなりません。
自分は、このようなエラーがエラーを相殺する事を防止するには、大きく２つの指針を立てる事が重要だと思います。１つ目の指針は、なるべく細かい粒度でテストをすることです。そう、ユニットテストです。エラーがエラーを相殺することを防ぐために最小の単位でユニットテストを行っていけば、早い段階で問題に気付くことができます。しかし、ユニットテストを細かい単位でやりすぎるとプログラムの内部構造に依存が高くなり、変更時のコストが高くなりすぎます。ユニットテストは、なるべく細かく、しかし変更に強い大きさで行う事が大切です。
２つ目の指針は可読性を高めるという事です。使われる側のメソッドの内部的な振る舞いが正しくないエラーと、使う側が正しく使わなかったというエラーでは、発生頻度は異なります。そして、メソッド・クラス・変数などが適切に名前を付けられていたならば、使う側のエラーはさらに減るでしょう。解りやすく正しい名前を付けると言うことは重要な事です。
笑い話のようにも思えますが、「エラーがエラーを相殺してしまう」ことは珍しい話ではありません。ソフトウェア開発の最終目標はソフトウェアのリリースです。完璧なソフトウェアを作ることはできませんが、我々は不具合の少ないソフトウェアを作る義務があります。そのためにはテスト手法を学ぶ事が必要です。

プログラマが知るべき97のこと