27-死ぬはずのプログラムを無理に生かしておいてはいけない

「プログラマが知るべき97のこと」の27個目のエピソードは、例外処理とアプリケーションの続行に関する話です。このエピソードでは、例外に対するアプローチについて安直な例外の握りつぶしは避けるように書かれています。

try-catchブロックをコードベースに大量に入れれば、「例外が発生しても絶対に止まらない」というアプリケーションを作る事が可能なはずです。ただ、これは、もう死んでいる人の体を釘か何かで固定し、無理矢理立った状態にしているようなものですが…。

このエピソードにあるような経験は、誰もがあるのではないでしょうか？自分も何度も経験しました。明らかに例外の握りつぶしが行われているコードはたくさんあります。メンテナンス時には何とか正常な例外処理に修正したい気持ちになりますが、そのコードが既にリリース済みの場合はまず変更することができません。例外を正しく投げるように修正した瞬間、アプリケーションが動かなくなるのです。仕方ないのでログにだけは吐こうとするでしょう。しかし、開発現場によっては「警告メッセージがログに出た、どういうことだ、バグを入れたな、修正しろ！」とプロジェクトマネージャ*1が怒り心頭になるのです。本来はバグとして適切なハンドリングが必要な部分に、修正はできないからせめて情報だけでも・・・とアプリケーションの品質をあげようとして徒労に終わります。当然のようにモチベーションはがた落ちです。
では、どうしてそんな状況になるのでしょうか？
原因は大きく２つあると思います。１つは例外＝バグ＝悪という単純な思考パターンで、特にプロジェクトマネージャ*2が考えているケースです。例えば、HDDのエラーについて一般的な業務アプリケーションのソフトウェアで考慮することはないでしょう。そのレベルのエラーまで考慮していたら予算内で作れるわけないからです。しかし、ファイルの入出力ではHDD障害に起因する例外が発生する可能性はあります。これはソフトウェアのバグではありません。クライアントからすればシステムの不具合には変わりませんが、システムがハードウェア障害に完全な対応が必要だったなら、別の方法で対応するべきでしょう。そのようなフローを全く引かずに、ソフトウェアのバグとして責任を押しつけられる傾向があります。そんな業界の空気から、プロジェクトマネージャは「絶対にバグを出すな、例外なんか出したらただじゃおかんぞ」となるのです。
２つ目の原因は、実装者の意識とスキルが足りないことです。プログラマであれば、例外について学び、基礎的な事は知っているはずです。そして、「例外を握りつぶしてはいけない」ということも聞いたことはあるはずです。しかし、悲しいことに現実の開発現場では「例外は握りつぶせ」と教える先輩PGもいます。以前、上司であるPGと例外について話したことがありますが、このエピソードにある話と全く同じ展開と結論でした。

したがって、プロジェクトマネージャも例外についてテストと共に理解を深める必要があります。スケジューリングや見積もりも重要ですが、品質について最終的な責任を負うのはプロジェクトマネージャでしょう。ソフトウェアがどのように作られ、障害やバグについてどんなパターンがあるかは知っていて当然です。
プログラマにとって、例外処理は大きな目安になるスキルです。正常系の処理は簡単な一方で、準正常系・異常系の処理は複雑で、様々な状況を予測する能力が必要です。コードについても、正常系の処理は数行に対して準星情景・異常系の処理が数十行というケースもありえる話です。テストについて言えば、正常系１つに対して準正常系・異常系は複数あるのが自然です。さらに厄介なのが準正常系・異常系については重要度があり、どれが重要かを判断する必要があります。そして、それらをプログラマはコードに効率良く書く必要がありますが、正解はありません。
プログラマとして成長するために例外処理とテストは欠かせないスキルです。その為には、たくさんのコードを読み、書いて学ぶ必要があるのです。

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

*1:自称だと思います

*2:繰り返しますが、自称です