ソフトウェア開発におけるレアケース
商品としての販売するソフトウェアが、
自分自身が利用するために作るソフトウェアと大きく違うところは、
万が一のことを真剣に考えるという点にあると思う。
データが10万件あった場合の動作をどうすべきか。
ハードディスクがぶっこわれた時の復旧手順はどうすべきか。
システムを何年もほったらかしにした場合どうなっちゃうか。
そういうまずありえないことを真剣に考慮して、対策なり仕様を明文化しなければならない。
自分が使うソフトの場合、レアケースについては
それが実際に発生した時、問題に直面した時に対処すれば良い。
しかし他人がいつどんな状況になるかなんてわからないし、
問題に直面した時に対応しますなんていう契約は成立するわけがない。
ありえないと分かっていてもできることはやらなくちゃならないらしい。
レアケースはレアケースとして認識した上で黙っておいて、
顧客に文句言われたら「バグです、すみません、すぐに対応いたします」とか言うこともできる。
しかしバグと宣言してしまったら、品質がどうのこうのと騒がれる。
仕様と言うからには事前に明文化しなければならないし、
それをやると不必要に顧客に突っ込まれて不毛な時間を浪費することにもなりかねない。
ソフトウェア開発は「ありえない」度が高い条件を考慮するほど稼働がかかる。
まず使われることのないツールを作成するのに何日もコツコツと続ける作業。
作るだけでも面倒だが、試験は更に面倒だ。
「まずありえない条件」を再現しなければならないからだ。
作ったからには必ず保証しなければならない。
ありえない条件を考えちまった以上それを保証しなければならない。
職業プログラマと趣味プログラマはどっちが優れているかという以前にそもそも適正が違う。
末端の製造員に斬新なアイデアなど不要。
必要なのはこういう場合はどうするんだよ、という揚げ足を取る観点。
ソフトウェアは工業製品だ。
ソフトウェア開発は緊張はするが興奮はしない。
私にはあまり向いてないのかもしれない。
>末端の製造員に斬新なアイデアなど不要。
>必要なのはこういう場合はどうするんだよ、という揚げ足を取る観点。
そいつぁいかんな。基本的にチェックを自分自身でやるのは非常によろしく
無い方法なんで。まぁ、大抵の企業とか言うところは作業員同士でお互いにチェック
し合うんだろうから間違っているとは書けないんだがな。
いわゆる適材適所で、発想や腕の良い奴が実装を担当して、細かいところに突っ込みを
入れるのが生きがいの奴はチェックツールや人間チェッカーになるのが宜しい。
つことで、過度に揚げ足取りだけを集めてはいかんぞ。
ま、最近の利益追求で、ふ そ う 状態になるのは宜しくなさ過ぎるがな。
再現性の薄いバグ報告などされるともう大変ですね・・
特にローカルで完全にバグ状況を再現できる場合でではなく
ネット、パケット通信間の特定状況下におけるバグとかになると
バグ原因を調べる為の状況再現をするだけでも手間取る。
デバックしてるとイラついてきます・・
>>wiz
＞基本的にチェックを自分自身でやるのは非常によろしく
無い方法なんで。
当然メンバー間で相互にチェックしますよ。
その前に一度は自分でチェックするけどね。
＞いわゆる適材適所で、発想や腕の良い奴が実装を担当して、細かいところに突っ込みを
＞入れるのが生きがいの奴はチェックツールや人間チェッカーになるのが宜しい。
普通の会社はこれができません。
まず適材適所を見抜く能力を持ったえらい人がいないし、できることとやりたいこととはまた違いますしね。
>>GRIGIT
＞デバックしてるとイラついてきます・・
個人的には「欠陥がある」のを「取り除く」というのはけっこう楽しいです。
誰か言ってたけどデバッグはゲーム感覚。
目的がはっきりしてますからね。
それよりも万が一を考慮するのがだるい。
実際には自分からは進んでレアケースを考える事はしないんだけど、
こういう場合どうしようとか話合うのがだるい。
こういう場合対処しといてとか言われて、99%無駄で無駄で終わって欲しい作業をやるのがだるい。
なんと言うか他人のために頑張れないのですね･･･