【 小規模システムのプログラミングのテスト、デバックの味噌 】
先回は、携帯サイト・ユーザーインターフェース設計の難しい点を述べました。
今回は、プログラミングのテスト、デバックをするとき
大規模システム開発の手順(教科書)どおりではやっていけないので、ではどうするか?
と言うことについてお話します。
Webアプリは、静的なHPサイトと違って、
プログラミングしただけでは、ダメで必ずテストが必要である。
本来、プログラム仕様の設計書に沿ってロジックをプログラミングしているのであるから、
その大元である仕様書に沿ってテストケースを漏れなく洗い出してテストデータを作成する。
そのデータをプログラムの単体テスト、そして連結テスト、総合テストと一連の流れの中で、逐一、慎重に石橋を叩いてチェックし、デバックをしていく。
その労力と手数は、プログラミングをするに匹敵すると同じ期間と費用が掛かる。
そこで、問題であるが、
どこまでやるか? である。
本来であれば、すべてやるのが正論である。
また、その苦労の結果は安心と保証ということで報われるであろう。
しかし、
小規模システムで、業務システムの重要性の程度にもよるが、何が何でも、規則どおり万全を期すまでやっていたら、日が暮れてしまう。
そこで、このように考える。
8割は2割の法則
もともと、
ロジックの8割は、イレギュラーな普段は起こりえないことに対して設けているロジックであり、ほとんど頻繁に使っているロジックパスは2割である。
この法則は、完ぺきではないが、大方のところ、実態と合致しているようである。
まあ、この世界のほぼ常識的な知見ですね。
よって、
その頻繁に、日常使うロジック(2割)は厳重にテストしておくことでシステムの信頼度を確保できる。
残りの8割の到底、通常の業務運用で行っている手順で起きえないロジックパスであれば、重要性を加味して、ほどほどにしておく。
そのような妥協点もある程度は許容範囲としてみておくこともよいと思う。
もっとも、その見極めは経験の積み重ねによるところが大きいので、不安の場合は経験豊かな諸先輩方にご相談させることです。
但し、
心配が一瞬でも頭によぎる個所があれば、必ず、潜在バグが潜んでいるとみて潰しに掛かることである。
当のプログラマーが心配なのを放っておくのは、事故(トラブル)が起きた時、無責任と言われる。
そして、
そういういわく付きの個所は、必ずと言っていいほど、ほぼ問題を起こす。
プロとして情けないことになる。
心配がある個所は放置しては絶対にいけない。そういう箇所は、必ず、後々禍根を残すことになる。
少なくとも自分で「クリアー」したと晴れ晴れした気持ちで納得できるものに仕上げなくてはならない。
それでも、突然のトラブルは起きるときには、起きるものである。
システムにはどんなに厳重に、しっかりとテストしたつもりでも潜在バグは残るものであるから。
大規模な複雑なシステムであればあるほど、そのリスクは大きい。
その意味で、コンピューターシステムは、
大変な利便性(光)を我々人類に与えたが、それに相応するリスキー(危険)な影の部分も大きくしていることを常に自覚すべきである。
「光が強ければ強いほど影も濃くなる」の喩えがある。
システムエンジニアはリスクに敏感である必要があり、その察知能力に長けていないと、いつかは、その報いを受けることになりかねない。
肝に銘じておくべきことです。
次回のお話をお楽しみに!
--------------------------------------------------------------------