バグを修正するすべての手段を使い果たした場合の対処方法

私は、クロスプラットフォームモバイルアプリケーション（1人のチーム-だから自分自身）に取り組んでいるジュニアプログラマー（これまでの4か月のキャリア経験）です。

このプログラム/アプリにはかなり大きなバグがあります（30種類のヘッダーファイル、それぞれ独自のcppファイルもあります）。私はバグで何が起こっているのかを正確に追跡し、それを修正しようとしています（いくつかのハックを使用してそれを機能させることさえ試みました）が、約12以上のソリューション（問題の原因について考えていること） ）バグが何であるかを正確に追跡したり、バグを修正したりすることはできませんでした。

いくつかの幅広いテクニックのジュニアプログラマーにアドバイスはありますか（実行に行く、すべてのコードを紙に印刷し、ペンでそれを実行するなど）、このバグの支援に使用できますか？

バグのコンテキストをもう少し説明します。クロスプラットフォームAPI Mosyncを使用します。特定の一連のアクションを実行すると、現在の画面ではなく、以前に表示された画面がまだポインター/キープレスイベントを受信して​​いるという現在の画面は再描画されません。

特定のシーケンス：
-メニュー画面の表示-「前の注文ボタンを表示」をクリック
-前の注文画面の表示-「ファイルの読み込み」をクリックしてメニューボタンをクリックして配信画面を開く
-配信画面の表示-メニューボタンをクリックして
購入画面を表示-購入画面の表示-ここでのエラー、この画面への入力は表示されない/反応しない、リストビューはスクロールしない、ボタンはクリックに反応しない、リストビューのセルはクリックに応答しない

また、私は私の仕事を別の目で見て、バグを指摘したいと思っていますが、私が1のチームであると言ったように、私の上司は私に指示し、彼は会社を所有し、アプリのアイデアを持っていますが、 c ++や最近の言語も知らない（cobal？全部だと思う）。会社の知的コード/財産を侵害/誇示せずに2番目の目を取得する方法に関するアドバイスはありますか？

...そして、この有給インターンシップを辞めることは選択肢ではありません。契約では、12分の1契約の6分の1の前に退職すると、年収の30％を支払う可能性があります。

問題を100％再現できる場合は、最後のステップにブレークポイントを設定します（できるだけ早く）。コールスタック全体を調べてみると、どこかで予期しない値、または呼び出されるべきであるが呼び出されない値に達すると確信しています。

編集：

そして、あなたがウィットの最後に座ってバグを修正しようとしていて、あなたがいくつかの輝く光のアドバイスを得ることを望んでここに投稿しているなら、立ち去ってください。頭をきれいにして、後で（できれば明日または週末後に）戻ってきてください。特定の問題の解決策を探すのに丸1日を費やして、明日頭を明け渡して10分以内にそれを見つけるために多くの時間を費やしてきました。

デバッグとは、問題が何であるかを正確に切り分けて理解することです（修正の適用と比較して）

デバッグの際に注意する必要があるのは、さまざまな理論の後にジャンプしていることを確認し始める場合です。

通常、これらのタイプの状況をデバッグする最良の方法は、システムを小さな断片に分割し、各断片を分離して動作させ、壊れるまで複雑さの各要素を1つずつ追加することによる退屈な体系的アプローチです。次に、正確な問題を特定しました。この方法は少し面倒で前向きな作業に思えるかもしれませんが、複雑なソフトウェアのデバッグを試みている間、変数を削除し、脳を正気に保ちます。

これらは私が過去にやったことのほんの一部であり、明らかにすべての状況ですべてが機能するとは限りません。

1. それは単にコードだということを理解し、中にどこかにバグがあなたがいること（それだけで黒魔術ではない）があるCAN修正。
2. 休憩する。
3. コードを非常にゆっくりとステップ実行し、各ステップを分析して、それを理解し、それが何をしているのかを理解していることを確認します。
4. 問題を見るためにもう一組の目を取得します。
5. 眠りにつくと明日まで忘れて（頭をきれいにして）新鮮な視点で来てください）。
6. コードを印刷して、各行を分析し、余白にメモを作成し、すべての行のあらゆる意味を理解します
7. それが重大なバグではないが、ユーザーが知る必要のないエラーを引き起こしている場合、私はバグを（恥ずかしく、しかし正直に）捕らえて、それを飲み込んだ！危険ではなく、原因がわからない場合は、単にトラップして、ユーザーに何が起こったかを知らせないことがあります。クライアントのROIがすべてであり、価値がない場合もあります。
8. バグを口頭で伝えて、追い詰めて殺すことを伝えます。時には逃げるでしょう。:-)

私は通常、バグを解決するときにこのアプローチを使用します。

1. バグを再現するための素敵なステップバイステップを作成します
2. ステップごとに簡素化
3. バグはコードのどこで発生しますか？どんな機能が関係しているのですか？
4. バグが発生したときにコードが選択するパス、つまりコールチェーン。
5. 場所に焦点を合わせます。そうでない場合は大丈夫です。次に、エラーが発生した場所を正確に見つけるまで、これを何度も繰り返します。
6. なぜこれが起こるのですか？

この時点では、問題に焦点を当てる過程で多くのことを学んでいるので、何が起こったのかは通常明らかです。または、フォーラムで質問できるかなり集中的な質問があります。

次に、問題を修正し、手順1で作成した手順を使用して、バグが修正されたかどうかを確認します。

以前のアドバイスはすべて優れており、その多くはバグ/エラーに関する仮定を検証し、デバッグプロセスに従ってエラーを特定することを目的としています（バグの周囲の環境を調べたり、コード内で直接調べたりすることもあります）。

このアプローチは、年功や専門知識に依存するかどうかにかかわらず、常に機能するとは限りません。問題に目を向けるだけでよい場合もあります。問題をレビューする誰かを見つけるか、セッションをデバッグします。多くの場合、コードを話すだけでエラーにつながります。

他の人が言ったように、1）確実にそれを再現でき、2）デバッガーでそれが発生するところまで前進します。

何らかの理由でそれができない場合、バグを示さない別のバージョンのコードを必要とする他の2つの方法があります。

1. 両方のバージョンのコードをデバッガーで並行して実行します。悪い人が良い人とは異なる何かをするまで、彼らを歩かせてください。

2. 良いバージョンと悪いバージョンのコードを交互に実行します。持っている差分やバージョンの違いの他のいくつかのリストを。次に、どちらかのバージョンのコードを少しずつ変更して、もう一方のコードにより厳密に一致するようにします。悪いものが良くなった場合、または良いものが悪くなった場合、変更を取り消して小​​さな変更を加えます。このようにして、私はバグを見つけます。私はそれを「問題の両側に乗り、中心に向かって取り組む」と考えています。この方法では、デバッガーは不要です。

問題が再現することは困難である場合、私はそれがとき、私は、そのようなスタックダンプとして、得ることができるよう多くの情報として必要ない起こります。そのため、これらの診断を取得できることを確認し、問題が発生するのを待って、それを見つけるのに十分な情報を得ることを望みます。

若手プログラマーとして手作業で作業するように割り当てられている場合、自分ですべてを処理できると考えている人が少なくとも1人います。

次に、上司に助けを求める前に、スクラップペーパー、バグの追跡に使用した手順/方法のリスト、それまでの経過、各方法を放棄した理由、および学んだことを書き留めます。各試行で。また、プロジェクトについてこれまでに学んだことを要約してください。

これを書き終えたら、何ができるかが目がくらむほど明らかになるはずです。存在する場合は、バグを再現するために、それ自体が明らかになったものに従うだけで、修正してみてください。そうでない場合は、上司と話すことができる基盤があります。あなたがしたことを示さずに彼らの助けを求めると、彼らはあなたに否定的な印象を与えるかもしれません。

しかし、頭を片付け、週末の後に戻ってきたら、誰の助けもなしにすぐに解決できるかもしれません。それは常に起こります。

方法はかなり異なるため、再現がどれほど難しいかを知る必要があります。欠陥を確実に再現するには、欠陥の原因を自動化します。デバッガーとデバッグトレースを使用します（トレースは競合状態の種類の欠陥への影響が最も少ないです）。整然としてください。一度に1つのステップで、各ステップがより多くの情報を提供します。すでに知っていることを確認している場合でもです。驚きの結果が得られたら、やめて、先に進む前に100％理解してください。それは痛々しいほど遅いですが、十分な時間を与えれば常に最終結果に到達します。

あなたがそれを再生産できない場合、あなたは問題を抱えています。あなたはそれを修正したことをどのように確認しますか。デバッグコードを入れて、そのままにしておきます。最終的に、「Closed：DNR」は有効なオプションですか？（再生産しませんでした/できませんでした）。ビジネスでは、最終的にはコスト/利益の決定になります。

ライブラリが正しいとは思わないで、正しいことを確認してください。

休憩を取って、コストと修正の必要性について実用的になり、何よりも他の人にあなたのそばに座って助けてくれるよう頼んでください。

ここにはたくさんの良い答えがあります。他のいくつかのヒント：

UIが単独で動作することはほとんどありません。バグの再現に必要な最小限の機能セットでテストプログラムを構築します。UIが適切に設計されている場合、失敗しているUIコンポーネントを分離し、テストプログラムでそれらを分離して実行できる必要があります。それでも問題を再現できますか？その場合、問題はUI構造またはフレームワークにある可能性があります。UI構造を確認してください-特に不可視の要素に注意してください。そのListViewをクリックしたときに何が起こるのか、それが応答しないのか、どのイベントハンドラーが呼び出されるのかを正確に学習してみてください。UIフレームワーク自体にバグが存在する可能性があることに留意してください-その結論にジャンプしないでください。ただし、完全に除外しないでください。簡単なテストは、Mosyncのバージョンをアップグレードし、症状が収まるかどうかを確認することです。

失敗した場合：テストプログラムには何が残っていますか？残りのすべてのコンポーネント、特に実行中のスレッドを理解します。バックグラウンドでデータベースのメンテナンスを行っているものはありますか？ある種のファイルスプーラ？NSAユーザー行動監視コード？UIはこれらのコンポーネントの一部で動作していますか（おそらく舞台裏で）？UIはどのバックグラウンド操作に依存していますか？

バグの難しさを考えると、かなりの時間を費やしているはずのコードを読んでいる間に、バグをあいまいにする可能性のあるいくつかの悪い習慣に注意してください。具体的には、これを見ますか？

try {
    SaveTheWorld();
} catch (std::exception& ex) { /* oh it didn't work, let's just ignore it */ }

それは信じられないほど悪いプラクティスであり、そのため、かなり当たり前です（クラッシュしなかったように見えます！）。少なくともログに記録するために、それを行っているコードは必ずアップグレードしてください-できれば偽の例外処理を完全に削除してください。（経験則から、例外がわからない場合、例外を処理する準備ができていません。）CスタイルのAPIとやり取りする場合は、エラーコードの戻り値がドロップされていないかどうかを確認し、対話しているあらゆるツールからエラーステータス情報をチェックしています。

テストプログラムがどのように障害を適切に処理しているかを確認し、作成したログを読みましたが、バグを強調するものは何もありません。プローブできるインターフェイスを探してください。内部で発生するはずのネットワークトランザクションはありますか？もしそうなら、Wiresharkでそれを打ちます。データベーストランザクション？クエリロギングを試すか、データベースサーバーのステータスを確認してください。ファイルシステムまたはネットワーク共有がヒットしていますか？中間ファイルを確認するか、デバッガーを使用してI / Oをトレースします。ハードウェアI / O？モニターおよびプローブ。経験的であること。UIは、予期しないバックグラウンド操作でハングアップする可能性があります。

最後に：パニックに陥らないでください。クールに保ち、試したことを追跡します。それでも見つからない場合は、雨の日に追跡するには「既知の問題」になる必要があります。そのように進めなければならない場合、多くの資料がその決定を正当化することを望むでしょう。

物事のスキームでは、再現可能なバグは（比較的）簡単です！どうして？バグが消えるまでいつでもコードを最小限にハックダウンでき、その後、どのコードが原因であるかを把握するために戻ることができるからです。それが一つの方法です。再現性があり、そこに生き物がいます。あなたはそれを突いて、それを試してみることができます。必要に応じて分析することもできます。

最初の目的は、コードでバグが発生している理由を理解することです。最初に修正しようとしないでください。理解してみてください。理解せずに修正しようとすると、ハッキングされて、技術的な問題が発生する可能性があります。

アプリの動作を1行ずつステップスルーします。変数値を監視します。制御の流れに注意してください。振る舞いは、あなたの理解がそれがそうあるべきであるとあなたに告げるものから最初にどこで逸脱しますか？オペレーティングシステムがアプリにイベントを送信する方法を理解していますか？「ブラックボックス」の問題に悩まされている場合、コンパイルされたライブラリ/フレームワークのソースを入手して、必要に応じてより深いレベルでステップスルーできますか？

バージョン管理システムで、このバグが発生しないコミットがありますか？（バージョン管理を使用していますよね？）そのようなコミットがある場合は、履歴をバイナリ検索して、バグが発生した正確な場所を見つけることができます。

あなたの目的は、（1）理解-原因を特定し、そのために、（2）調査し、アプリの動作を詳細に理解することを試みる必要があります（3）問題を解消してから、デルタを調べて理解することで問題を切り分けますそれを可能にした

しかし、あなたが本当に立ち往生しているなら、間違いなく数週間そこに座ってはいけません。組織内の誰かにも伝える必要があります。特定のポイントを超えることができる場所で助けを求めますが、確かにあなたは進行中の障壁にぶつかったと感じていることを経営者に伝えるのはあなたの義務です。しかし、すべてを学習と理解に焦点を合わせたさまざまな角度からヒットすれば、おそらくこれを解決できるでしょう。