【第13回】「良い設計」には異常系が少ない

今回は少し専門的な話を。

「プロが書くプログラムは、7割が異常系だ」

昔、私がこの業界に入った頃、ある人にそう言われたことがあります。

すべてのプログラム動作のうち、エラー発生しないで処理が正常終了する「正常系ステップ」は開発時にさほど考慮は必要なく、簡単に作り上げることができる。

しかし処理中になんらかのエラーが発生することを正確に想定し、その対処のためのステップをしっかり書くのがプロの仕事だ。ということでした。

確かに昔はメモリの使い方などでかなり「野蛮な」プログラムを書くことができた上に、ハードウェアもネットワークも今よりずっとショボく、

「ひとつの処理が他の処理とぶつかってエラー起こす可能性」とか、

「処理中にハードウェア関連のエラーが発生して強制終了し、データの整合性が保てなくなる可能性」などがわりと高かったのは事実です。

だから「プロのプログラムは７割が異常系」もあながち間違いではなかったのですね。

ちなみに私が現役バリバリのプログラマだった頃、この「異常系ステップ」というのがどうも嫌いで、なにより「エラー発生したのと同じ状況を作って異常系ステップの動作が正しいかを確認する」というテストにいつも悩まされました。

すごく手間が掛かるんですよ。「そんな状況、１０年に一度起こるかどうかだろ！」というエラー状況の再現に。

でも、時代は変わりました。

メモリエリアを破壊するような原始的なプログラムは書こうと思っても書けず、ハードウェアもネットワークも格段に性能向上して信頼性も増しました。

だから、今なら断言できます。

「良い設計をすれば、プログラムの異常系ステップは極端に少なくできる」と。

（アーキテクチャやフレームワーク選定も「設計」に含みます）

異常系を誘発するようなデータはそもそもインプットできなくする。とか、

プログラム内部での処理分岐を極力減らした設計にする。とか、

やり方は色々あるでしょう。

「そもそも異常系があまり存在しない設計をする」ということが、品質向上のための一番の近道ではないかと私は考えています。