ローマの品質

こんにちは。最近岩盤浴にハマッている kyagi です。

現在あるアプリケーションの保守/開発を行っているのですが、そのひとつにエラー処理のリファクタリングがあります。抜けているエラー処理を追加したり、エラーメッセージのマクロを整理するといった作業です。

一般的にアプリケーションのエラーケースは大きく 「環境」、「ユーザ」、「プログラム」の 3 つの原因に分けられると言います(*1)。

• 環境による問題　= サービス接続失敗やディスクに空きがない状態、またはファイルやディレクトリのアクセス権限の不足といったケース。詳細な情報を提供すれば、システム管理者は解決できる。

• ユーザエラー = 認証失敗や二重起動といったケース。正しい手順を伝えて再試行してもらえば、ユーザ自身で解決できる。

• プログラムの欠陥 = ヌルポインタ参照やハッシュの値がないといったケース。このエラーが起きた場合、ユーザやシステム管理者はお手上げ状態のもの。

該当のアプリケーションの動作を簡単に言うとサーバに接続し、認証処理を行った後、処理を行うというものです。作業を行うかたわら、エラーケースを整理するために以下のようなマインドマップ(*2)を作成しています。

こうすることで、どの枝のエラーケースが多い/少ないといったことが一目瞭然で把握できます。抜けているケースを類推したり、実際に追加したり、それぞれのケースエラーメッセージや返り値を割り振るのにも役立ちます。

また、このマップに従ってエラー系のマクロを #define などで定義していけば grep を使ってソースコードから簡単にエラー発生箇所を検索したり、全体で何種類のエラーが何個定義しているのかということを算出することが可能になります。

エラー系の処理は実装において後回しにされがちなことが多いですが、アプリケーションの品質を底上げするためにはここをしっかりと作りこんでおくこ とが重要だと思います。試験工程時に参照してテストケースを充実させることもできますし、運用以降の問題発生時にも原因解析の大きな力となってくれます。

どちらかというと日の当たらない、地道な作業ですが、ローマも(*3)、品質も、一日にして成らずと考えて、せっせと作業する日々が続いています。

(*1)
「アジャイルプラクティス  達人プログラマに学ぶ現場開発者の習慣」より抜粋。

(*2)
マインドマップは記事用に適宜、省略したり、修正しています。

(*3)
「愛なしには世界は世界でなく、ゆえにローマもローマではないだろう」というゲーテの言葉がありますが、ソフトウェア開発においては、

• 「愛」→「エラー処理」
• 「世界」→「アプリケーション」
• 「ローマ」→「品質」

と読みかえると結構当たっているかもしれません。(^_^;