パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

航空管制ダウンの原因はNECのバグ放置」記事へのコメント

  • バグ発見→部署内で議論→実運用上ありえない→現状

    正直言ってここまではよくあることだと思います。
    (例えばドコモが無茶苦茶なデータを送ったらほとんどの携帯が
    ハングするんじゃないだろうか・・・)
    で、今回の改修により「実運用上ありえない」パターンが発生
    してしまいダウンしてしまったと。

    「次回修正」と
    • という事を主な理由として、潜在的なバグ改修を行わない、という考え方は、一般的に、真っ当なものなのでしょうか。

      政治の場でも、セキュリティ対策でも、何でも。「あり得ない事」などと簡単に言い切ってしまって後になって痛い目にあう、という事を何度と無く目にしていると、とても
      • >という事を主な理由として、潜在的なバグ改修を行わない、という考え方は、一般的に、真っ当なものなのでしょうか。

        場合によりますが、有り得ない事ではありません。
        たとえば簡単な例として数値の配列と個数を渡して平均を返す関数があるとします。

        int ave(int *val, int num)
        {
          return sum(val, num)/num;
        }

        要点を掴みやすいように、とりあえず全部合計する関数をsum()としています。これにはバグが無いものと仮定。
        これでnumに0を渡すと0割りのエラーですね。
        本来であれば入力値のチェックをしてnumが0なら適切な処理をすべきでしょ

        • 例として0での割り算が挙がっていますけど、仕様書に例外処理が書いていないから実装しない、もし問題が起こったら私の責任ではない、という人と、ここ0きたら実行時にエラーじゃん、私のコードでエラーが出るとは許せん!!こっそり例外処理入れちゃえ
          • 例として0での割り算が挙がっていますけど、仕様書に例外処理が書いていないから実装しない、もし問題が起こったら私の責任ではない、という人と、ここ0きたら実行時にエラーじゃん、私のコードでエラーが出るとは許せん!!こっそり例外処理入れちゃえって人。
            どちらにするかは、開発体制でも異なると思いますが、問題が起こった時に、仕様にないから私の責任ではないとすることができる体制かどうかが大きいのではないかと。

            そうでない体制の場合、実際にバグであるとしてクレームがやってきたり責任を問われるわけで、クレーム防止のためにも後者を選んだ方がトータルでは短時間ですみます。(逆にそういう体制の場合は仕様変更になります)
            PGからPMまでの意思疎通がうまくいっていて、PMが立派な人だったら、こういった問題は減るんでしょうかね。
            そうなんでしょうけど、そんなPMは極少数しかいないですし。それに一人が把握できる範囲には限界もあるし。
            あと、良くあるパターンとして、PGにシステムの全体像や背景が知らされていないため、仕様に対して違った解釈をされて、的外れなものを作っちゃったりとか。
            親コメント

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

処理中...