アカウント名:
パスワード:
という事を主な理由として、潜在的なバグ改修を行わない、という考え方は、一般的に、真っ当なものなのでしょうか。
え～と、NECの外注で仕事してますが、うちのプロジェクトには実運用ではあり得ないのでOKとなっているバグが、うなるほどあります。 数年前の一番最初の開発がこけた＆仕様がごちゃごちゃなので、下手に直すと危険なのです(^^; （設計支援
うちもNEC外注やってましたが、余りに多いバグの対処として、一部バグを前提としたプログラムってのがあります。 これらの物は相手のバグで間違った値を返してくるのを前提として書かれています。
場合によりますが、有り得ない事ではありません。 たとえば簡単な例として数値の配列と個数を渡して平均を返す関数があるとします。
int ave(int *val, int num) { return sum(val, num)/num; }
要点を掴みやすいように、とりあえず全部合計する関数をsum()としています。これにはバグが無いものと仮定。 これでnumに0を渡すと0割りのエラーですね。 本来であれば入力値のチェックをしてnumが0なら適切な処理をすべきでしょ
例として0での割り算が挙がっていますけど、仕様書に例外処理が書いていないから実装しない、もし問題が起こったら私の責任ではない、という人と、ここ0きたら実行時にエラーじゃん、私のコードでエラーが出るとは許せん!!こっそり例外処理入れちゃえって人。
PGからPMまでの意思疎通がうまくいっていて、PMが立派な人だったら、こういった問題は減るんでしょうかね。
前者ふたつはバグの話とはちょっと違うのではないかな。
ただ、最後の道路について言えば、路面整備の段階で穴や継ぎ目が残ってて高速で走行すると危険だと分かっていても、制限速度が低い道なら放っておきますね。「この道をそんな速度で走ることはありえない」って。
で、その後いろいろあって、その道の制限速度が引き上げられてしまったら?
今回のポイントは“ありえないから問題点を放っておいた”ことではなくて、状況が変わってありえるようになったときに問題点を“思い出せなかった”ことではないのかなぁ。 そういう問題点管理に手落ちがあるのは事実で責められても仕方がないんですが、責める点を間違うのは問題がぼやけてしまって良くないと思う。
実際には、放置していて結果として何も問題が起きない事の方が「とても多い」でしょうけども、それが「事実上あり得ないという理由が真っ当なものである根拠」になるとは思えません……。
今回のバグ(?)入りコードが放置されていた根拠は「事実上ありえ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
想像ですが。 (スコア:2, 参考になる)
正直言ってここまではよくあることだと思います。
（例えばドコモが無茶苦茶なデータを送ったらほとんどの携帯が
ハングするんじゃないだろうか･･･）
で、今回の改修により「実運用上ありえない」パターンが発生
してしまいダウンしてしまったと。
「次回修正」と
実運用上あり得ない (スコア:2, 興味深い)
政治の場でも、セキュリティ対策でも、何でも。「あり得ない事」などと簡単に言い切ってしまって後になって痛い目にあう、という事を何度と無く目にしていると、とても正常な判断が出来る人間が説明する理由ではないなあ、と感じてしまうのです。
実際には、放置していて結果として何も問題が起きない事の方が「とても多い」でしょうけども、それが「事実上あり得ないという理由が真っ当なものである根拠」になるとは思えません……。
バグ改修の優先度 (スコア:1, すばらしい洞察)
バグ改修を行わない、のではなく、バグ改修の優先順位を下げる、という判断がなされただけではないかと思います。
バグ改修を行うためには、発注元の了解を取り付けることが必要になりますが、その際、リリース前に検証したにもかかわらず、なぜそんなことが発生したのだ、という議論だけが先行して、実際のバグ改修がなかなか始まらないことがあります。また、そういった理由から、いったんリリースしてしまった後のバグ改修はあまり回数を行うことができない、といった負のバイアスが現場にかかるのも事実です。
そのため、いそぎでないバグ改修であれば次のリリースに含めて対応しようとする方向になるのも不思議ではありません。また、このバグが発見されるのが、その次のリリースのための機能追加の最中だったりしたら、そんな時期に検証のリソースはさけないため、とりあえず次のリリースまでもってくれ、と祈ることになるのでしょう。
やれやれ、なんかやりきれないな。
Re:実運用上あり得ない (スコア:1)
今回は特にあと２ヶ月でバージョンアップすることは
決まっていたでしょうから。
現場の人間としてはなおせる物ならすぐになおしたいんでしょうが
会社間レベルとかになってくると「事を荒立てない」という要素が
一番強かったりする。。。。
インフラと電化製品を一緒にするなという声が聞こえてきそうですが
末端の外注、子会社レベルになると机を並べていたりするわけで。(^^;)
#書いててやるせなくなってきますが
#他コメントにもあるように現状はこんなもん；
Re:実運用上あり得ない (スコア:1)
プログラムの不具合やテスト条件の不備を指摘したときにとてもよく聞く台詞です。
実際には、その「あり得ない」ケースが実によく発生します。
手抜きの言い訳ぐらいにしかとらえていません。
Re:実運用上あり得ない (スコア:0)
>「とても多い」でしょうけども、それが「事実上あり得ないという
>理由が真っ当なものである根拠」になるとは思えません……。
同意。
個々のロジックの組み合わせが運用上ありえないことはありますが、
全パターンをテストすべきだし、もし頻度が低くて対応が次期以降
の改修になるような場合でもその挙動は把握してリスト化しておく
べ
それはもう大量に！ (スコア:0)
え～と、NECの外注で仕事してますが、うちのプロジェクトには実運用ではあり得ないのでOKとなっているバグが、うなるほどあります。
数年前の一番最初の開発がこけた＆仕様がごちゃごちゃなので、下手に直すと危険なのです(^^;
（設計支援
Re:それはもう大量に！ (スコア:1)
（プログラム上ありえないはずなんだけど）っていうのは大量にもう。
現実ではそこまで戻してテストする余裕も無いし、問題なければ
見てみぬこともあるのではないかな？
問題あったらやるしかないかって感じですね。
バグを前提としたプログラム (スコア:0)
うちもNEC外注やってましたが、余りに多いバグの対処として、一部バグを前提としたプログラムってのがあります。
これらの物は相手のバグで間違った値を返してくるのを前提として書かれています。
Re:実運用上あり得ない (スコア:0)
場合によりますが、有り得ない事ではありません。
たとえば簡単な例として数値の配列と個数を渡して平均を返す関数があるとします。
int ave(int *val, int num)
{
return sum(val, num)/num;
}
要点を掴みやすいように、とりあえず全部合計する関数をsum()としています。これにはバグが無いものと仮定。
これでnumに0を渡すと0割りのエラーですね。
本来であれば入力値のチェックをしてnumが0なら適切な処理をすべきでしょ
Re:実運用上あり得ない (スコア:2, 参考になる)
あと類似ケースとしては、プログラムの一部を他のプロジェクトに流用してしまう人がいて、そのまま一人歩きしてしまい、思わぬ使われ方をした結果、トラブルが発生したこともあります。
そのため、無駄とわかっていても、関数単体レベルでどんな入力があっても致命的なエラー(ダウンするとか例外で落ちるとか)しないようにしたり、それができない場合はドキュメントに制約を明記したりするようにしています。
もっとも、他プロジェクトへの流用は、この問題の他にも、やり方によっては著作権や機密の問題も絡んでくるので、作った担当者と上司(場合によっては法務関連も)の許可制としている所もありました。
プログラマって２種類ありますよね (スコア:1)
どちらも現状は100%問題が発生しません。前者も後者もいろいろな意味で問題があるのでしょうけど。PGからPMまでの意思疎通がうまくいっていて、PMが立派な人だったら、こういった問題は減るんでしょうかね。
Re:プログラマって２種類ありますよね (スコア:1)
そうでない体制の場合、実際にバグであるとしてクレームがやってきたり責任を問われるわけで、クレーム防止のためにも後者を選んだ方がトータルでは短時間ですみます。(逆にそういう体制の場合は仕様変更になります)
そうなんでしょうけど、そんなPMは極少数しかいないですし。それに一人が把握できる範囲には限界もあるし。
あと、良くあるパターンとして、PGにシステムの全体像や背景が知らされていないため、仕様に対して違った解釈をされて、的外れなものを作っちゃったりとか。
Re:実運用上あり得ない (スコア:0)
> という事を主な理由として、潜在的なバグ改修を行わない、
> という考え方は、一般的に、真っ当なものなのでしょうか。
一般的に市場に流通しているモノ・商品のホトンドがそうですが なにか？
「包丁を使って 他人を刺す」
「自動車を凶器として 人を傷つける」
「法と道路事情を無視した
Re:実運用上あり得ない (スコア:1)
「自動車を凶器として 人を傷つける」
「法と道路事情を無視した 速度で自動車を運行する」
前者ふたつはバグの話とはちょっと違うのではないかな。
ただ、最後の道路について言えば、路面整備の段階で穴や継ぎ目が残ってて高速で走行すると危険だと分かっていても、制限速度が低い道なら放っておきますね。「この道をそんな速度で走ることはありえない」って。
で、その後いろいろあって、その道の制限速度が引き上げられてしまったら?
今回のポイントは“ありえないから問題点を放っておいた”ことではなくて、状況が変わってありえるようになったときに問題点を“思い出せなかった”ことではないのかなぁ。
そういう問題点管理に手落ちがあるのは事実で責められても仕方がないんですが、責める点を間違うのは問題がぼやけてしまって良くないと思う。
Re:実運用上あり得ない (スコア:0)
今回のバグ(?)入りコードが放置されていた根拠は「事実上ありえ