2017年06月30日

なぜログやエラー処理の組み込みは苦労するのか


初めての方はこちらを「はじめに

前回はコードの流用の原因について述べましたが、「設計における汎用性とは」にかかわる事はまだまだいくらでもあります。今回はプログラムにログやエラー処理を組み込む際の話です。

苦労とは


タイトルをもう少し説明します。
ログやエラー処理を組み込むというのは各関数にエラー処理やログの機能を組み込むという意味です。苦労するというのはこれらの処理が他の機能の作り込みに比べると今一つうまく行かなくて出来栄えが落ちる様な事を指しています。
勿論「全然苦労はしてない」という人もいるでしょう。しかし苦労する要素があるのは確かなのでそういう視点で読んでいただければと思います。

なぜ難しいのか


苦労するというのはそのだけ難しいという事ですが一体なぜ難しいのでしょう。
一つ大きな要因として考えられるのはログにしてもエラーにしてもどちらも主に内部的な機能という点です。つまりユーザーに向けた機能ではなく自分達に向けた機能という事です。自分達用なのでユーザー用の機能に比べると仕様にしろ設計にしろ審査が甘くなる可能性はあります。下手をすると特にレビューなどもされずに上司などから「入れといてくれ」と一言言われて担当者任せになるような場合もあるかもしれません。
そういう意味では一口にログやエラーといっても他の機能と同様にユーザー向けのものならばここだけ特異的に難しくなるという事は起きないのかもしれません。

あとエラーの場合なのですが少なくとも設計が終わらないとエラーの内容が確定できないという事はあるでしょう。場合によっては製造中にエラーの内容が変更になる事もあるでしょう。この点はおそらく難しさの要因になると思いますが、種類としてはプロジェクト推進やプロセスにかかわるものであって今回のテーマの範疇ではないと思われますのでここではこれ以上掘下げない事にします。

では今回のテーマの範疇での原因は何かと言うと、冒頭で「設計における汎用性とは」との関係だと宣言したのでお分かりかもしれませんが、ログにしろエラー処理にしろいずれにしてもすべての関数に共通的に組み込む必要がある為です。つまり他の関数に比べて一段下にしなければならないからです。その為例によって検討時に難しさが発生する訳です。
53N027_001.jpg

エラー処理について具体的に説明してみます。
一段下にするという事はその上に乗っかっている全ての関数の要求に応えなければなりません。そうすると例えばある関数ではメモリ上の処理だけなのでエラーコードを返せばいいだけかもしれませんが、別の関数ではDBに対する処理をするのでエラーコード以外にレコード番号とフィールド番号も返す必要があるかもしれません。またある関数ではUIの処理をするので同様に画面のどの入力に関するエラーかを返す必要があるかもしれません。この様に様々な役割を担う様々な処理の関数の全ての要求を満たす様な汎用性を持たなければならないという訳です。こういった検討が難しいという事になります。ログも同様です。

対策


対策といっても汎用性に関しては「設計における汎用性とは」で説明した通りです。あとは「内部的なもの」という扱いを排除する事です。計画の段階から仕様や設計に至る全ての場面でユーザー向けに提供する機能と同等の扱いをする必要があります。

一覧


メニュー

関連


なぜ汎用的にする必要があるのか
事例:ブログ投稿システム-出力部構造
設計における汎用性とは
なぜエラー表示が必要なのか


記事を広める



posted by 善 at 21:05 | Comment(0) | TrackBack(0) | 設計 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック