タグ付けされた質問 「bug」

これは「知識を共有する」質問です。あなたの成功や失敗から学ぶことに興味があります。 役立つ情報... バックグラウンド： コンテキスト：言語、アプリケーション、環境など バグはどのように識別されましたか？ バグを特定したのは誰ですか？ バグの再現はどれほど複雑でしたか？ 狩り。 あなたの計画は何でしたか？ どのような困難に遭遇しましたか？ 問題のコードはどのようにして最終的に見つかりましたか？ 殺害。 修正はどの程度複雑でしたか？ 修正の範囲をどのように決定しましたか？ どのくらいのコードが修正に含まれていましたか？ 死後。 根本的には根本的な原因は何ですか？バッファオーバーランなど 30,000フィートからの根本原因は何でしたか？ プロセスには最終的にどのくらい時間がかかりましたか？ 修正によって悪影響を受けた機能はありましたか？ どのような方法、ツール、動機が特に役立ちましたか？...ひどく役に立たない？ もう一度やり直せたら？............ これらの例は一般的なものであり、すべての状況に適用できるわけではなく、おそらく役に立たない可能性があります。必要に応じて味付けしてください。

31 experience  bug 

スプリアスウェイクアップに関するウィキペディアの記事によると 「スレッドは、条件変数にシグナルを送っていなくても、待機状態から目覚めさせることができます」。 私はこの「機能」について知っていましたが、同じ記事で実際に何がそれを引き起こしたのかは知りませんでした 「スプリアスウェイクアップは奇妙に聞こえるかもしれませんが、一部のマルチプロセッサシステムでは、コンディションウェイクアップを完全に予測可能にすると、すべてのコンディション変数操作が大幅に遅くなる可能性があります。」 修正する価値のないバグのように聞こえますが、そうですか？

30 multithreading  bug  features 

完璧な人はいませんし、私たちが何をしようとも、時々バグを含むコードを作成します。新しいソフトウェアの作成時と既存のコードの変更/保守時の両方で、発生するバグの数を減らすためのいくつかの方法/手法は何ですか？

30 bug 

ユーザーが設計上のものについてバグレポートを提出するのは悪い兆候ですか それは通常、アプリケーションが混乱したり不明瞭であることを意味しますか、それとも特に明記しない限り、1回限りのユーザーの間違いまでそれをチョークする必要がありますか？ （実際にはそのような報告はありません。これは、設計上の「バグ」の存在が悪いことであるかどうかについての純粋に仮説的な質問です。）

29 bug  users 

アランJ.ペルリスによる次のような引用があります。 エラーのないプログラムを作成するには2つの方法があります。3番目のものだけが機能します。 私は最近友人からこの引用を聞いたが、その背後にあるより深い意味を理解することができなかった。 ここでPerlisは何について話しているのですか？

29 bug  quotations 

コンパイラの作業が本質的にソースコードをマシンレベルのコードに変換することである場合、コンパイラに不具合、つまり障害のある「翻訳」が存在する可能性があります 通訳についても同じことが言えます。必要なコンテンツを出力できない場合がありますか？ コンパイラ/インタープリターのバグを聞いたことはありませんが、存在しますか？

28 compiler  bug  interpreters 

この質問は少し抽象的ですが、誰かが私を正しい方向に向けてくれることを望んでいます。 私の質問は、元の開発時間に関連するソフトウェアプロジェクトのバグにどれだけの時間を費やすことができるかです。膨大な数の決定要因が存在することを認識していますが、典型的なまたは平均的な内訳を望んでいました。 たとえば、プロジェクトAの完了に40時間かかり、さらに10個のバグを修正する場合、このプロジェクトの比率は4：1になります。 別のプロジェクト（B）が完了するのに10時間かかり、バグでさらに8時間かかる場合、比率は5：4になります。 これは文書化/研究された概念ですか？ 更新 すべての有益な答えをありがとう。関係するすべての変数と環境要因のため、この種のメトリックに標準を設定することは不可能であることを理解しています。回答を割り当てる前に、このメトリクスに同意済みの名前があるかどうかを知りたいので、さらに調査することができます。メトリックを自分で生成するために必要な測定値を理解し、最終的にプロジェクトのベースライン標準を思い付くことができるポイントに到達したいと思います。

26 bug  time 

シナリオ： 本番にプッシュします プッシュは複数のことを壊しました その同じビルドはqaまたはdevを壊しませんでした 開発者は、製品にアクセスできません。 物事を機能させるには、上から多くのプレッシャーがあります。 詳細： ZendでAPI駆動型のPHP / MVCアプリケーション。 少数のサーバーに展開されました。 私の質問： 調査中に、何かが間違っているという予感があるとしましょう。しかし、私は確かに知りません。そしてもちろん、実稼働環境でテストすることはできません。その考えに基づいて修正案を提案している場合、問題が何であるかを理解する前に、それを試して適用し、機能するかどうかを確認するのが賢明でしょうか？

24 bug  production 

テスト中にエラーが発生するテスターがいますが（これまでのところ）、すぐに頻繁に報告します。私たち（開発者）は、テスターが問題を再現しようとしておらず、（尋ねられたときに）問題を再現する方法を見つけることができないことを後で発見します。 今、これらはまだバグです、私はそれらを無視したくありません。しかし、再現手順がないと、ちょっと行き詰まります。スタックトレースがある場合もあります（ただし、これはコンパクトなフレームワークであり、行番号がないため、しばしば有用ではありません）。しかし、ある場合、スタックトレースを取得してコードをクラックし、推測を開始できますが、テスト可能な「修正」にはつながりません。 このようなシナリオでは何をしますか？

22 bug  testing 

オフバイワンエラーは、最も一般的ではないにしても、最も一般的なプログラミングエラーの1つであるようです（/software/109/what-are-common-mistakes-in-codingを参照してください）、および従来の知恵）。 これらが非常に一般的である理由は何ですか、それは人間の脳がどのように機能するかと関係がありますか？ 1つのエラーで餌食にならないようにするにはどうすればよいですか？

20 coding  bug 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 理由を説明し、（誤）機能が実装されている言語をリストしてください。 嫌いなものではなく、有害な機能と思われるものを投稿してください。

20 programming-languages  bug  features  mistakes 

少しのバックグラウンド：私は10人の部門の2人のプログラマーのうちの1人です（残りはアーティストと管理職です）。私たち2人は、物事を順調に進めるために必要なすべてのコーディングを行い、出てくるプロジェクトを開発します。私は約4年前からプログラミングを行っていますが、これが彼の最初の「本当の」仕事です（彼の言うとおりです）。通常、私たちはいつでも異なるプロジェクトに取り組んでいます。 数か月前、私は後のプロジェクトで使用するクラスのセット（決して完璧ではない）を開発しました。そのプロジェクトの大部分は、GUIインターフェースを設計およびプログラムするために（請求のため）彼に委任されました。彼は新しいので、私は設計を少し手伝い、残りの部分で必要な場合は助けを求めるように言いました。彼は数週間前にインターフェースを完成させましたが、それは少し遅いですが、それが機能することを示すためにデモしました。 私が取り組んでいるプロジェクトの次の部分は始まっています。次のステップから始めるためにインターフェースを開いたところ、すぐに問題にぶつかりました（少し遅かったのは、控えめな表現、一般的なアクションのエラーなどでした）。いくつかの問題についてコードを調べ、エラーチェックのないタイプの仮定（Pythonにあります）、元のコードに追加されたGUIへの参照などを見つけるO(n^n)必要がO(n)あります。 今、私は間違いなく彼に何が間違っていたのか、どのようにそれを修正するのかを教えたいと思っていますが、彼はすでに次のプロジェクトに移っており、これは数週間前でした。「戻って正しいことを！」と言って怖いです。（もちろん助かります）厳しすぎるので、その間にやるべき他のプロジェクトがまだあります。私は今のところ自分でコードを修正し、将来的に物事をキャッチしようとする必要がありますか？

19 code-reviews  bug 

これは少なくとも一度は私に起こりました。私はコードベースのある部分に取り組んでおり、別の部分に小さなバグを見つけました。そのバグは、私が現在やろうとしていることを完了するのを妨げます。バグの修正は、単一のステートメントを変更するのと同じくらい簡単です。 その状況で何をしますか？ バグを修正し、現在の作業と一緒にコミットします 現在の作業を別の場所に保存し、別のコミットでバグを修正してから作業を続行してください[1] あなたがすることになっていることを続けて、コードをコミットします（たとえそれが ビルドを壊します いくつかのテストに失敗します）、バグを修正します（そして ビルド 別のコミットでテストに合格する） [1]実際には、これは、元のリポジトリを他の場所に複製し、バグを修正し、変更をコミット/プッシュし、作業中のリポジトリにコミットをプルし、変更をマージし、作業を続行することを意味します。 編集：私は本当に意味を反映するために3番を変更しました。

19 bug  version-control 

このプロジェクトでは、ゼロバグ（別名ゼロディフェクト）方法論で作業します。基本的な考え方は、バグは常に機能よりも優先度が高いということです。ストーリーの作成中にバグがある場合は、ストーリーを承認するために解決する必要があります。古いストーリーのスプリント中にバグが見つかった場合は、バックログに次に配置して解決する必要があります-最優先事項。 私が解決と言っている理由は、バグを常に修正するとは限らないからです。それほど重要ではないので、「修正しない」と宣言することもあります。全体的に素晴らしいですね。私たちは高品質の製品を出荷しており、巨大なバグのバックログの形で「こぶ」を運んでいません。 しかし、このアプローチが正しいかどうかはわかりません。深刻なバグをできるだけ早く修正する必要があり、重要ではないバグを破棄する必要があることに同意する傾向があります。しかし、重要ではあるが新機能ほど重要ではないバグはどうでしょうか？それらは適切な優先順位でバックログにファイルされるべきだと思う傾向があります。 より明確にするために例を挙げます-私のプロジェクトでは、flexで書かれたUIを使用します。すべての画面解像度で同じサイズで開くウィザード画面があります。ウィザードウィンドウを拡張すると、ページの1つが見栄えがよくないことがわかりました（ウィザードはすべてを表示でき、スクロールバーを必要としないにもかかわらず、消えない垂直スクロールバーがあります）。このバグは見苦しいと思います。修正する必要があると確信しています。しかし、私たちは厳しいスケジュールにあり、多くの機能を備えているので、カットを加えてリリースすることはできないと考えています。私たちはそのようなバグに耐えることができると感じています。修正する必要はありますが、他の機能よりも優先度が低くなります（したがって、完了できない場合は、少なくとも重要な機能を除外しませんでした）。だが、 「修正できない」とマークしたくないが、最も重要ではないバグに対処する方法について意見を聞きたいと思います。

18 agile  scrum  bug  backlog 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 例外をバグと呼ぶ場合、そもそも例外ではなく単にバグと呼ぶだけではどうでしょうか？ コード内で例外と呼ばれ、発生するとすぐにバグと呼ばれます。それでは、そもそもそれをバグと呼んでみませんか？ 回答やコメントをありがとうございます。

18 bug  debugging  issue-tracking  exceptions  exception-handling