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

デバッグとは、プログラムの実行中に、通常はデバッグツールを使用して、プログラムの状態を調べ、異常な動作を引き起こすバグを見つけようとするプロセスです。

21
テスターが見つけるためのコードに意図的なバグを残す
弊社ではこれを行っていませんが、友人の一人が、プロジェクトマネージャーがすべての開発者に、製品がQAに移行する直前に意図的なバグを追加するように依頼したと言います。これがどのように機能するかです: 製品がQAに移行する直前に、開発チームはコードのランダムな場所に意図的なバグを追加します。これらのバグが最終製品に付属していないことを確認するために、元の動作中のコードを適切にバックアップします。 テスターに​​もこのことが通知されます。バグが存在し、それらを見つけられないことは無能の兆候と見なされる可能性があることを知っているため、彼らは一生懸命テストします。 バグ(意図的またはその他)が見つかった場合、それらは開発チームが修正するために報告されます。開発チームは、製品が第2レベルのQAに移行する直前に、コードの関連セクションに別の意図的なバグを追加します。プロジェクトマネージャーは、テスターは開発者のように考えるべきであり、変更が行われたセクションに新しいバグがあることを期待すべきだと言います。 まあ、これはそれがどのように行くかです。彼らは、このアプローチには次の利点があると言っています。 テスターは常につま先を向いており、狂ったようにテストします。これは、開発者が修正できるように、隠れた(意図しない)バグを見つけるのにも役立ちます。 テスターはバグをフィードします。バグを見つけられないと、彼らの士気に影響します。ですから、彼らに見つけやすいものを与えることは彼らの士気を助けるでしょう。 これらの意図的なバグの1つが最終製品に同梱されるシナリオを無視する場合、このアプローチの採用を検討する前に考慮すべきその他の欠点は何ですか? いくつかの説明: ソース管理で元のコードを適切にバックアップします。 テスターが意図的なバグを見つけると、開発チームはそれを無視します。テスターが意図しない(元の)バグを見つけた場合、開発チームは最初に意図的なバグが原因かどうかを確認します。つまり、開発チームは最初に元の作業コードでそれを再現しようとし、可能な場合は修正しようとします。 QAと開発チームの関係の問題を無視してください。私は、ワークプレイスではなくプログラマーにこの質問を具体的に尋ねました。QAと開発チームの間には良好な関係があり、勤務時間後には一緒にパーティーを行うことを考慮してください。プロジェクトマネージャーは、両方のチーム(Godsend)をサポートする準備が常にできている、素晴らしく、年配の紳士です。

9
1つのメソッドシグネチャを変更しましたが、現在25,000以上のエラーがあります。今何?
私は最近、非常に大きなアプリケーション(15M loc)で作業している新しい仕事を始めました。私の以前の仕事では、同様に大きなアプリケーションがありましたが、(良くも悪くも)OSGiを使用しました。これは、アプリケーションを独立して変更、コンパイル、デプロイできる多数のマイクロサービスに分割することを意味しました。新しいアプリケーションは、たった2つの.dllを備えた1つの大きなコードベースにすぎません。 ですから、このクラスのインターフェースを変更する必要があります。それが上司が私に要求したことだからです。彼らは当初、あまり一般化されていないいくつかの仮定でそれを書きました。しばらくの間、リファクタリングの問題は非常に密に結合されているため回避していました。インターフェイスを変更しましたが、現在25000以上のエラーがあります。エラーの一部は、「XYZPriceCalculator」のような重要な名前のクラスにあり、これは本当に壊れてはいけません。しかし、すべてのエラーが解決されるまで、アプリケーションを起動して動作するかどうかを確認することはできません。また、ユニットテストの多くは、そのインターフェイスを直接参照するか、そのインターフェイスを参照する基本クラスに結合されるため、それらを修正するだけでも非常に大きなタスクです。さらに、これらのすべてのピースがどのように組み合わされるかについては本当にわからないので、たとえ始めたとしても、物が壊れた場合にどのように見えるかはよくわかりません。 私は最後の仕事でこのような問題に本当に直面したことはありません。私は何をしますか?

16
バグをより速く解決する方法はありますか?私はちょうど上司から警告を受けました[終了]
上司から、月曜日にパフォーマンスに関する否定的なレビューを受けると言われました。彼は、なぜ私がそんなに遅いのか、そしてなぜ私のバグ修正率がそんなに低いのかについて私に話したいと思っています。 私はプログラミングと問題の解決が大好きですが、実際に仕事は本当に難しいと感じています。 私は実際に約10年間プログラマーです。しかし、これは私の最初のマルチスレッディング組み込みLinuxの仕事です-私はここに2年来ましたが、私がまだ苦労していることは誰にとっても明らかです。そして、私は非常に士気を失い、社会から疎外されたと感じているので、仕事を始めたときの多くの火を失いました。 誰も同じような状況に陥ったことはありますか?また、バグ修正率をどのように上げますか? 更新:レビューがありました。私は3か月間の「従業員開発プログラム」(Dunkが言及したタイプの)に参加しました。これを好転させることができるかどうかわからない。しかし、先に進まなければならない場合でも、この経験から多くのことを学びました。 別の更新 最初のレビューから約6週間です。同じ状況に直面している人への私のアドバイスは、批判を受け入れ、あなたの過ちから学ぶのに十分謙虚であることです。そして、愚かに見えることを恐れないために。たくさんの質問をしてください。あなたが学ぼうとしていることを人々に知らせ、理解するまで尋ね続けます。しかし、うまくいかないように準備してください。私はコードのポートフォリオを構築しています...そしてそれをベストショットにします。 さらに別の更新 将来の雇用者に私のstackoverflowプロファイルを参照することができないのではないかと心配しているので、これをここに置くのをためらっています...しかし、とにかく、この質問を読んでいる人にとって興味があるかもしれませんが、実際には数週間前の仕事。私は必要なすべてのスキルを磨く最中です-ここで与えられたアドバイスから多くを取りました。

21
デバッガーの使用を避ける利点は何ですか?
私のキャリアの過程で、一部の開発者はデバッグツールを使用しないことに気付きましたが、問題が何であるかを把握するために誤ったコードをチェックします。 多くの場合、デバッガーなしでコード内のエラーをすばやく見つけることができるのは良いスキルですが、デバッガーがタイプミスなどの小さな間違いを簡単に見つける場合、問題を探すのに多くの時間を費やすことは生産性が低いようです。 デバッガなしで複合システムを管理することは可能ですか?お勧めですか?「サイキックデバッギング」を使用することで得られるメリットは何ですか?
101 debugging 

17
診断して修正する前にすべての欠陥を再現することを主張するのは合理的ですか?
私はソフトウェア製品会社で働いています。当社の製品を実装する大企業のお客様がおり、サポートを提供しています。たとえば、不具合がある場合は、パッチなどを提供します。つまり、かなり典型的なセットアップです。 最近、製品のクラスター化された実装での同時データベースアクセスに関係するログファイルでお客様が発見した例外に関してチケットが発行され、私に割り当てられました。したがって、このバグの発生には、この顧客固有の構成が重要になる可能性があります。顧客から得たのは、ログファイルだけです。 私がチームに提案したアプローチは、顧客と同様の構成設定でバグを再現し、同等のログを取得することでした。ただし、バグを再現する必要はありません。過度に時間がかかり、VM上のサーバークラスターをシミュレートする必要があるため、彼らは私のアプローチに同意しません。私のチームは、単純に「コードをたどって」スレッドおよび/またはトランザクションに対して安全でないコードがどこにあるかを確認し、単純なローカル開発で動作する変更を行うことを提案します。バグの起源。 私にとっては、目に見える形の顕在化(実行時の再現)ではなく、抽象的な設計図(プログラムコード)で作業するのは難しいようです。そのため、一般的な質問をしたいと思いました。 すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか? または: 私が上級開発者であれば、アプリケーションを実行したり、さまざまなユースケースシナリオを実際にテストしたり、ステップスルーしたりするのではなく、マルチスレッドコードを読んで、すべてのユースケースシナリオでそれが何をするかについての心構図を作成できるはずです行ごとにコード?または、私はそのような作業環境を要求するのに貧弱な開発者ですか? sissisのデバッグはありますか? 私の意見では、インシデントチケットに対応して提出された修正は、可能な限り元の環境に近くなるようにシミュレートされた環境でテストする必要があります。それが本当に問題を解決することを他にどのように知ることができますか?それは、エアバッグが実際に機能することを実証するためにダミーで衝突試験することなく、車両の新しいモデルをリリースするようなものです。 最後になりますが、私に同意する場合: 私のアプローチが合理的で、保守的で、より防弾であることをチームに納得させるために、チームとどのように話し合うべきですか?

9
IDEなしでどのようにデバッグしますか?[閉まっている]
IDE(現在はGoをいじっています)を探すたびに、Vi、Emacs、Notepad ++などを推奨する人でいっぱいのスレッドが見つかります。 IDE以外で開発を行ったことはありません。私は甘やかされてきたと思います。IDEなしでどのようにデバッグしますか?ロギングのみに制限されていますか?
61 ide  debugging 

21
「昨日はうまくいきました、誓います!」あなたは何ができますか?[閉まっている]
午前中に到着すると、昨日の夕方に出発したときでもソフトウェアが機能しなくなっていることがわかります。 職業はなんですか?最初に何を確認しますか?怒りを止めて問題に取り組むために何をしますか?あなたは同僚を非難し、彼らに直接行きますか?そのような状況に陥ることを避けるために何ができますか?

5
リバースデバッグがほとんど使用されないのはなぜですか?[閉まっている]
gdb は2009年にリバースデバッグのサポートを実装しました(gdb 7.0を使用)。2012年まで聞いたことはありません。特定の種類のデバッグの問題に非常に役立つことがわかりました。前に聞いたことを望みました。 私が間違っている場合、私を修正しますが、私の印象は、テクニックがまだほとんど使用されておらず、ほとんどの人がそれが存在することを知らないということです。どうして? 逆デバッグの使用が一般的なプログラミングコミュニティを知っていますか? 背景情報: Stackoverflow:リバースデバッグはどのように機能しますか? gdbは「リバースデバッグ」という用語を使用しますが、他のベンダーは同一または類似の手法に対して他の用語を使用します。 MicrosoftはそれをIntelliTraceまたは「履歴デバッグ」と呼びます Omniscient Debuggerと呼ばれるJavaリバースデバッガーがありますが、おそらくJava 6では動作しません 他のJavaリバースデバッガーがあります OCamlのデバッガー(ocamldebug)はタイムトラベルと呼びます
56 debugging 

10
テストのテスト方法は?
コードをテストして、コードをより正確にします(実際、不正確になる可能性は低くなります)。ただし、テストはコードでもあり、エラーが含まれることもあります。また、テストにバグがある場合は、コードが改善されることはほとんどありません。 テストで考えられる3種類のエラーを考えることができます。 プログラマーが目前のタスクを誤解し、テストが実行すべきだと思ったとおりにテストを実行する場合の論理エラー。これは誤りです。 基礎となるテストフレームワークのエラー(例えば、漏れやすいモックの抽象化)。 テストのバグ:テストは、プログラマーが考えていることとは少し異なっています。 タイプ(1)のエラーを防ぐことは不可能と思われます(プログラマーが...賢くならない限り)。ただし、(2)および(3)は扱いやすい場合があります。これらのタイプのエラーにどのように対処しますか?それらを避けるための特別な戦略はありますか?たとえば、テスト作成者の前提条件のみをチェックする特別な「空の」テストを作成しますか?また、壊れたテストケースのデバッグにどのように取り組みますか?

17
人のデバッグスキルを確認または評価する方法 [閉まっている]
コードを簡単にデバッグできる人をどのようなスキルが決定しますか?しばらく前、私の友人が比較的優秀なプログラマーとのインタビューを実施しました。プログラマーが雇われました。彼は良いコードを書き、フレームワークとデザインパターンを理解できました。彼が見逃していたのは、デバッグスキルです。彼はまったくデバッグできず、彼または他の誰かのコードの問題を見つけることは彼にとって大きな苦痛でした。 それ以来、人のデバッグスキルをどのように評価または推定できるかを考えています。 それで最初の質問は、人がソフトウェアを効果的にデバッグできるかどうかを決定するスキルは何ですか? 2番目:インタビュー中にこれらのスキルをテストする方法ですか?

7
ソフトウェアのテスト方法は欠陥のあるデータに依存していますか?
ソフトウェアエンジニアリングでは、バグを修正するコストが、バグが発見された後の開発で指数関数的に増加することはよく知られています。これは、Code Completeで公開され、他の多くの出版物で採用されているデータによってサポートされています。 ただし、このデータは存在しなかったことがわかります。Code Completeが引用したデータは、明らかにそのようなコスト/開発時間の相関関係を示しておらず、同様の公開された表は、いくつかの特殊なケースで相関関係を示しました。 これを裏付ける、または反論する独立したデータはありますか? そして、もし本当なら(つまり、発見された最近のバグのためにこの指数関数的に高いコストをサポートするデータがない場合)、これはソフトウェア開発方法論にどのように影響しますか?

11
並行性:設計にどのようにアプローチし、実装をデバッグしますか?
私は数年前から並行システムを開発してきましたが、正式なトレーニングが不足している(つまり学位はない)にもかかわらず、このテーマをかなりよく理解しています。少なくとも最近話題になっているいくつかの新しい言語があります。これらは、ErlangやGoなど、並行処理を容易にするように設計されています。並行性に対する彼らのアプローチは、システムをスケーラブルにし、複数のコア/プロセッサ/マシンを活用する方法に関する私自身の経験を反映しているようです。 しかし、あなたが何をしようとしているのかを視覚化し、少なくとも元のビジョンに近いことを確認するのに役立つツールはほとんどないことがわかります。並行コードのデバッグは、並行処理用に設計されていない言語(C / C ++、C#、Javaなど)では悪夢のようです。特に、開発環境の1つのシステムで簡単に発生する状態を再現することはほとんど不可能です。 それでは、並行性と並列処理に対処するシステムを設計するためのアプローチは何ですか?例: 並行処理できるものとシーケンシャルにする必要があるものをどのように把握しますか? エラー状態を再現し、アプリケーションの実行中に何が起こっているかを表示するにはどうすればよいですか? アプリケーションの異なる並行部分間の相互作用をどのように視覚化しますか? これらのいくつかについては私自身の回答がありますが、もう少し学びたいと思います。 編集 これまでのところ、多くの良い入力があります。リンクされている記事の多くは非常に優れており、私はすでにそれらのいくつかを読みました。 並行プログラミングでの私の個人的な経験から、シーケンシャルプログラミングとは異なる考え方が必要だと思います。精神的な格差は、おそらくオブジェクト指向プログラミングと手続き型プログラミングの違いと同じくらい広いでしょう。この一連の質問では、回答に体系的にアプローチするために必要な思考プロセス(理論)にもっと焦点を当ててほしい。より具体的な回答を提供する場合、例を提供するのに役立ちます-あなたが個人的に経験したこと。 バウンティの目標 何をすべきか教えてはいけません。私はすでにそれをコントロールしています。あなたが何をするか教えてください。これらの問題の解決方法を教えてください。

8
デバッグコードを常に残すか、常にデバッグするか、デバッグ時にのみ追加し、バグが見つかったときに削除する必要がありますか?
1つは、バグを特定するときにデバッグコード(printステートメントなど)を追加するだけです。そして、それを見つけたら、デバッグコードを削除します(そして、そのバグを具体的にテストするテストケースを追加します)。私はそれが実際のコードを乱雑にしているので、デバッグしていない限りそこに場所がないと感じています。 どうやってやるの?デバッグコードをそのまま残しますか、または廃止されたときにデバッグコードを削除しますか?
35 debugging 

9
あまりにも多くのアサートを書くことは可能ですか?
私は執筆の大ファンです assert開発中に発生する可能性のあるケースをキャッチする方法としてC ++コードでチェック。プログラムのロジックバグが原因で発生する可能性があります。これは一般的に良い習慣です。 しかし、私が書いたいくつかの関数(複雑なクラスの一部である)には5つ以上のアサートがあることに気づきました。それぞれが関数の事前条件と事後条件について考える必要があり、それらは本当にバグをキャッチするのに役立つので、それはまだ素晴らしいと思います。ただし、多数のチェックが必要な場合にロジックエラーをキャッチするためのより良いパラダイムがあるかどうかを尋ねるために、これをそこに置きたかっただけです。 Emacsのコメント:Emacsが私の選択のIDEであるため、アサートステートメントを少しグレー表示にして、提供できる混乱を軽減します。.emacsファイルに追加するものは次のとおりです。 ; gray out the "assert(...)" wrapper (add-hook 'c-mode-common-hook (lambda () (font-lock-add-keywords nil '(("\\<\\(assert\(.*\);\\)" 1 '(:foreground "#444444") t))))) ; gray out the stuff inside parenthesis with a slightly lighter color (add-hook 'c-mode-common-hook (lambda () (font-lock-add-keywords nil '(("\\<assert\\(\(.*\);\\)" 1 '(:foreground "#666666") t)))))

8
最も効果的にコードをデバッグする方法は?[閉まっている]
コードに忍び寄るバグは最小限に抑え、それが書かれている通り、完全に解消されないことができます-プログラマがあり、多くのだろうが反対し、人間だけを。 コードでエラーを検出した場合、それを取り除くために何ができますか?貴重な時間を最も有効に活用し、それを見つけようとする時間を短縮し、より多くの時間をコーディングできるようにするには、どのようにアプローチする必要がありますか?また、デバッグするときは何を避けるべきですか? ここで、バグの防止については話していないことに注意してください。バグが発生した場合の対処方法について説明しています。これは広い分野であり、言語、プラットフォーム、ツールに大きく依存している可能性があります。もしそうなら、考え方や一般的な方法などの回答を網羅してください。
33 debugging 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.