午前中に到着すると、昨日の夕方に出発したときでもソフトウェアが機能しなくなっていることがわかります。

職業はなんですか？最初に何を確認しますか？怒りを止めて問題に取り組むために何をしますか？あなたは同僚を非難し、彼らに直接行きますか？そのような状況に陥ることを避けるために何ができますか？

通常の容疑者は次のとおりです。

• 昨日は機能すると思っていましたが、1日の仕事を終えた後、機能しなかったことに気付かないほど盲目でした。

• 今朝は、昨日IDEキャッシュメモリの内容を参照できなくなりました。

• ワークステーションが昨夜再起動したか、毎晩のメンテナンス操作で/ tmpディレクトリがクリアされました。

• コードベースで何かが変更されました：昨日の最後のコンパイルと今日の最後のコンパイルの間に誰か（おそらく自分自身）が変更をコミットしたかどうかを確認します。

• サポートライブラリで何かが変更されました。それらのライブラリが再コンパイルまたはアップグレードされているかどうかを確認してください。原因は、特定のライブラリのプロジェクト内、または明らかに独立したパッケージの新しいバージョンが展開された場合の外部にある可能性があります。

• テスト環境で何かが変更されました：仮想マシンの新しいバージョン、変更されたスタブ、リモートデータベースサーバーの変更...

• コンパイルチェーンで何かが変更されました：Makefiles、IDEの新しいバージョン、コンパイラ、標準ライブラリの変更...

1）今日動作していない場合、昨日動作していませんでした。

あなたはそれが働いていると思ったが、そうではなかった。

2）問題があり、解決する必要があります。

誰がこれに責任があるのか​​、他人を非難するのは考えないでください。

昨日から今日まで何も変わっていない場合（質問を読んでいると思います）、実際に動作する前にコードをテストすることでより良い仕事をする必要があることを意味します。

この状況を回避するには、適切なテストとデバッグを行う必要があります。

「作業」を定義し、コードルーチンの境界をテストします。

• プログラムまたはコード機能を使用するユーザーの1人になることを試みてください。
• コードを許可された制限以上にプッシュし、実際に壊れるかどうかを確認します。

これを行う1つの方法は、夜間に広範なテストの自動セットを実行することです。これにより、翌日、何か問題が発生したかどうかを確認し、問題を修正できます。

非難に合格する誰かを見つけようとすることは非建設的であり、問​​題を解決しません。しないでください。

昨日は何かが機能していて、今は機能しない場合は、非決定的な動作（競合状態など）があり、昨日それが機能するのは幸運でしたか、またはその間に何かが変わったので、それを調べる必要がありますです。

どのケースがどのように正確にどのように修正できるかは、状況の詳細に依存しますが、原因を排除するために整然とすることは常に役立ちます。どの特定の原因が問題を引き起こしたかを見つけ、おそらくそれを修正する方法を書き留めて、今から3週間後に再び発生したときにそれを調べることができるようにします。

適切な診断ツール（デバッガー、プロファイラー、ネットワーク分析ツール）を使用することも大きな違いをもたらします。

私は一晩で変化するように見えたコードを使って作業しましたが、しばらくして結論を​​出したのは、悪意のある妖精が夜にコードベースにcい込み、昨日それが働いていたにもかかわらず、まったく機能しません。確かに、古典的なSchroedinbugスタイルでは、現在動作しないだけでなく、これまでにない方法があることは明白です。

時間が経つにつれて、実際にはピクシーがそれとは無関係である可能性があり、おそらく「家に帰る時間、それは十分に良い」最後のビルドは、おそらくそれに値する詳細なテストと注意を得ることができないことに気付きました。

午前中にこれに遭遇したときの私の最初の仮定は、私が通常自分の機能や作業中のソフトウェアのコーナーを担当しているので、おそらく私のせいだということです。私の2番目の仮定は、私はそのコーヒーを今すぐ手に入れるかもしれないということです。猿が明らかになる可能性があることを明白に明らかにしていない場合（これは時々）バックするか、チェックせずにビルドに持ってきたものをどこかにキャッシュします。最近のソース管理アクティビティを実行すると、私がやったことを明らかにする傾向があります。ビルドをクリーンアップすると、誤ったキャッシュバージョンが削除されることがよくあります。

時々それは本当に私とは何の関係もない-誰かがそれを言及せずに依存関係を更新した、WindowsUpdateは私のコードが機能しないように環境を変える何かをインストールした; 多くのバックグラウンドの可能性がありますが、通常は、ほとんどの人がそうであるように、私は基本的にばかです。

バージョン管理を使用します。diffを実行するか、VCSの非難機能を使用します。

• diff：すべてのVCS。異なるバージョンの違いを示します
• blame：たとえば、git。何を変更したかを行ごとに表示します

自分や上司のせいである以外にバージョン管理がない場合は、ファイルの変更日を確認し、OSのログ機能を調べることができます。

それとは別に：すべてを再コンパイルし、補助ライブラリも必ず再コンパイルしてください。

もちろん、エラーの原因を見つけた場合は、落ち着いて、変更が行われた理由を尋ね、問題を説明し、あなたを満足させる解決策を提案してください。彼女/彼に大声を出さないでください、それはあなたの生産性にとって有害で​​す。

変更がまったくない場合は、システムで何が変更されたかを確認します。たとえば、最近Mac OSコンピューターは一部の構成が無効になったApacheの新しいバージョンに更新されました。

さて、ここでは、今日ではなく「昨日機能した」コードの実際の例を示します。今月の初めからです。

問題のアプリケーションは、日付ごとにデータベースから情報を取得します。デフォルトの動作は、当日のデータを取得することです。これは8月8日に正常に機能しましたが、9日に失敗しました。これ以前にテストされていません。また、9月9日と10月10日に機能していました...

別の手がかりは、私たちが英国にいること、問題のデータベースが米国にあったことです...

だから、最初にチェックするものについてのあなたの質問に対する私の答えは、日付と月のフィールドを混ぜると完全に動作するが、月に1日だけであるため、日付のフォーマット方法を再確認することです:-)

バグを修正します（ただし、通常は行います）。その後、誰が原因であるかを見つけたら、彼らに丁寧なメールを送り、何が悪いのかを知らせます。

すべてのコーダーは間違いを犯し、あなたが非難を始めた場合、同じことを次にするときに真剣に裏目に出ます。（おそらくこのバグでさえあなたのものでした）

いくつかのバグから大したことをする必要があるのは、それらが不注意であると疑われる場合のみです。

... 回帰テストを実行し、失敗したテストに焦点を当てます。

実際に、去る前に昨日やることを忘れていたことが起こります。

持ってないの？わかりました。責める？まあ... それはうまく いくかもしれない

何かが機能しなくなったときに最初にすることは、自分自身に問いかけることです-何が違うのですか？変化したこと？

昨夜何かが機能したが今朝失敗したとき、明らかに変わったのは- 日付と時刻 :)

私が取り組んでいるロジックの一部が日付に依存していて、時間の経過によって影響を受ける可能性があるかどうかを試してみてください。それがそのような問題の原因である回数は驚くべきことです。

それが失敗した場合、ここで提供されている他のすばらしいアドバイスを必ずフォローアップする必要があります。

ちょっとした答え（書くこと）ですが、要点を得るにはちょっと長いです：プログラムが失敗する理由：アンドレアス・ツェラーによる体系的なデバッグのガイド（少しアカデミックに見えるかもしれませんが、そうではありません）

単体テストが失敗したときに継続的インテグレーションエンジンによって送信されたメール（または特定の問題を監視していない場合はログページ）の後にメールボックスを調べ、ビルドの直前に誰がチェックインしたかを確認します。

その後、彼または彼女と話をしてください。

今日コードが失敗するのは2つの理由だけですが、昨日は機能しました。

データを見てください

テストしていない、または考慮していないデータに何かがあります。データが適切に検証されないか、予期しない論理条件が発生するまで、ロジックのエラーが明らかになりませんでした。これは、バグが昨日そこにあったが、有効なデータの下に隠れていることを意味します。

私はかつていくつかの注文入力コードを数週間問題なく実行していました。ある日家に帰ると、死んでしまいました。翌日の調査で、一連の関数呼び出しにバグが隠されていることが明らかになりました。弱い型付けの言語では、long intを使用する必要があるときに整数を宣言しました。言語は、数値が整数に収まる値を超えたために変換できなくなるまで、2つの間の変換を自動的に行いました。システムは注文番号32768で失敗しました。

変更点を見る

それが働いてから変わったものを見てください。ITセクションはOSの更新をプッシュしましたか？別のコーダーがプログラムで使用するコードを変更しましたか？ユーザーの許可は変更されましたか？多くの場合、変更点を見つけると、バグが見つかります。

バイナリチョップ

難しいJavaScriptエラーに対して特にうまく機能します。基本的にコードの半分をコメントし、エラーが発生するかどうかを確認します。エラーが発生した場合は、そのコードの半分で行います。半分にまた続けてください。

コードが適切にカプセル化されている場合、これは時間を節約できる素晴らしいストレス解消ツールです。

有罪コードを見つけたら、多くの場合、独自のテストページでエラーを特定する価値があります。

そしてもちろん、そのような状況に陥ることを避けるために何ができるでしょうか？

この質問に対処するために、継続的インテグレーション（CI）を検討することをお勧めします。簡単に言うと、CIは開発者が頻繁に（1日に数回）開発者がすべてのコードを統合してテストするプロセスです。アイデアは、別のモジュールを壊す1つのモジュールへの変更がすぐに見つかるということです。

実際には、CIを採用しているほとんどのチームはCIサーバーを使用しています（Wikipediaのリストを参照）。通常、CI Serverは、SCMリポジトリを監視し、変更を検出するとビルドを開始するようにセットアップされます。ビルドが完了すると、一連の自動化されたテストを実行し、ビルドとテストの電子メールやWebページを介して結果を投稿し、その変更がビルドの原因となります。うまくいけば、何かがビルドやテストに支障をきたすとき、あなたが見るべき非常に小さな変更セットしか持っていないので、それはより速く解決されます。

どのCIサーバーを使用するかについては他にも質問がありますので、興味のあるものを見つけさせていただきます。個人的に、私はジェンキンスの大ファンです。

[壊れていることについてどうすればよいですか。]

他の人がすでに言っているように、何が壊れたかを見つけて、それを修正しようとします。非難をかけるために時間を費やすことは、問題を解決しないために費やされる時間です。

私の自然な反応は常に他人を非難することですが、時間が経つにつれて、通常は私に責任があることに気付くようになりました。上記のすべての優れたコメントに加えて、最終的な理由が何であったかを自分で記録することが重要です。他のチームメンバーと共有されているWiki、プライベートTwiki、Evernote、ログブック、または良い思い出を使用するかどうかは関係ありません。重要なことは、答えを見つけた（そして仕事に戻りたい！）理由を記録することです。

おそらく動作しなくなった場合、動作していない、つまりハングしたり、特定のエラーダイアログをユーザーに返したりする症状を特定したと考えられます。

問題の唯一の説明が「機能していない」場合、最初に行う必要があるのは、問題の症状に関する詳細情報を収集することです。

次に、ログまたは問題の再現の試み、あるいはその両方を介して、考えられる原因を探し始めます。システムのセットアップ方法に依存します。

次に、それらを除外し始めます。

それは私が休暇を取るときに通常起こることです:-)

もっと真剣に、私は最初に彼らに言います：

• 私はそれを見て、何が間違っているのか、何が根本的なのかを調べます

• 何が起こっているのかを見る機会があったら、30〜60分後にベースに触れます

その時間が経過すると、何が起こったのか、まだ修正されていない場合は修正にどれくらいの時間がかかるのか、該当する場合はどのデータが失われた可能性があるのか​​の見積もりを危険にさらすことができますできれば）。

非難部分については：

• それが単なる同僚のタイプミスである場合、それを言及する必要はありません。たわごとが発生し、バグからの恐怖が彼に教訓を教えた可能性が高く、できれば、彼は再びそれをしないでしょう。

• 彼が意図的に私に彼に言わないことをした場合（例えば、本番サーバーのrootパスワードを新しい人に与え、監督なしで直接変更するように彼に言う）（はい、すでに起こった...）、私はそれに言及する必要があります。

通常のバグトレース方法が機能せず、すべてが完全に混乱している場合、簡単に復元できるバックアップがあると素晴らしい場合があります。

これは私がローカルで、午前8時から午後6時まで1時間ごとに自動的に実行するものです。

rdiff-backup /path/to/mystuff /path/to/mybackup

簡単ですね。

何かを復元する必要がある場合は、

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-backupは、異なるファイルのみを保存します。Linux、mac、winでrdiff-backupを使用できます。

もちろん、これが唯一のバックアップではありません。ただし、ローカルバックアップを作成するのは非常に簡単で安価な方法です。

さて、これを通常のバグ修正方法としてはお勧めしませんが、他のすべてが失敗した場合はフォールバックです。

バグはすでに存在している可能性がありますが、外部要因またはシステムの深い問題によって隠されています。

これは私に起こりました。プロジェクトの2つのビルドの間に発生したバグ。文字通り、私たちが行った唯一の変更は、基礎となるライブラリの1つのより新しいビルドに更新することでした。

当然、私たちはそれらを非難しました。しかし、彼らが行った唯一の変更は、より高速なコンパイルのためにいくつかのヘッダーをリファクタリングすることでした。システムを壊してはいけないことに同意しました。

多くのデバッグの後、問題は私のコードに何年も潜んでいた不正なポインタのバグであることが判明しました。リファクタリングによって実行可能ファイルの配置が変更されるまで、どういうわけかトリガーされませんでした。

正しく使用されていたため、昨日は機能していました。

他の人が物を壊す良い方法であると思わない方法で物を使うことがわかります。

良いテスト環境が得られるので、一日の早い段階でコードを更新するのは常に良いことです。

バックアップ！

ブレークポイントを設定して一時停止し、データをチェックすると、どこでどのようにデータが悪化しているのかを正確に特定できます。