開発者であるということは、半分以上の時間はデバッガーになる必要があることを意味し、時には自分のコードのために、他の時にはコード レビューやペア プログラミングの場合に仲間を助ける必要があります。開発者にとって必要なスキルであるにもかかわらず、デバッグはキャリアのどの時点でも誰にでも教えられるものではないため、非常に難しいと考えられています。 デバッグが難しそうに見えるのは、その仕組みのためではなく、初心者にとってどこから始めればよいかを理解するのが難しいためです。間違いなく、時間の経過とともにより多くのコードを作成して確認することで習得できる芸術ですが、今日この記事で説明するいくつかの推奨事項を使用して、直感を早い段階で開発できます。 始めましょう。 問題の再現 問題をデバッグする際の最悪のシナリオは、バグを確実に再現できない場合です。これは、デプロイされたシステムまたは開発者ステージ ボックスで異なる動作パターンにつながる、競合状態、外部システム、または環境問題などのいくつかの要因が原因で発生する可能性があります。 これは、テスターと開発者の両方に帰着し、バグの再現方法をより具体的にすることができれば、より良い結果が得られます。また、問題とそれを実証する方法を見つけたら、それを再現し、理解して解決するためのすべての詳細を、バグ追跡システムに載せてください。これは、実装された修正を検証するのに役立つだけでなく、他の開発者がバグの原因と解決策を理解するのにも役立ちます。 問題を再現する手順を説明する際に従うべきいくつかの簡単なヒントを次に示します。 言及する可能性が高いほど、より多くの調査の道が開かれるため、具体的にするようにしてください. 入力が必要な場合は、常にいくつかの例またはサンプル値を含めてください。また、ユーザー入力に指定された制約または規則についても言及します。これは、問題の原因である可能性が高いため、確認する価値があります。 常に環境の詳細 (オペレーティング システム、ブラウザーの種類、ブラウザーのバージョン) を指定してください。これは特に、異なるブラウザーが異なる動作を表現できる Web アプリケーションの場合に当てはまります。 関連するクラッシュ レポート、ログ、注釈付きのスクリーンショットなどを含めて、アプリケーションの予想される動作と実際の動作の違いを適切に説明し、デバッガーに誤解の可能性を残さないようにしてください。 問題を自動テストに変換する この手順は、常に可能であるとは限りません。可能な場合もありますが、実用的ではないか、実際には必要ではありませんが、実装する価値がある場合もあります。このコンテキストでの自動化されたテストは、単体テストや統合テストなど、開発ユース ケースで既にテストに利用されているものであれば何でもかまいません。単体テストは頻繁に実行されるように設計されているため、可能な限り単体テストを選択することをお勧めします。これにより、問題がすぐに再発するかどうかがわかります。 問題の原因を特定しようとしている間に合格する単体テストをたくさん書いていることに気付くかもしれません。場合によっては、現在の状況以外では意味をなさない単体テストを作成していることに気付くかもしれませんが、それでも、問題の原因を突き止めるのに役立つテストを作成しても害はありません。現在の問題ではないからといって、後で問題が見つからないというわけではありません。また、コードがどのように動作するかについてのドキュメントとしても役立ちます。単体テストは、多くの場合、システム内のどの層が問題を引き起こしているかを判断するための優れたアプローチです。 本番コードと同じ勢いで単体テストをリファクタリングします。コードの重要な部分を実際にテストしている巨大な単体テストがある場合は、それを小さなテストに分割してみてください。運が良ければ、元の問題に基づく大規模な失敗した単体テストが、複数の成功したテストと 1 つのマイナーな失敗したテストに分割される可能性があることに気付くでしょう。 早い段階で問題を見つけて 1 行で解決できる場合でも、可能な限り単体テストを作成して検証してください。コードを修正するときに間違いを犯すことは、最初にコードを開発するのと同じくらい簡単であり、テスト ファーストの原則は依然として適用されます。 物事がうまくいくと期待しないでください 問題をデバッグしている場合は、どこかが意図したとおりに機能していないことが明らかであるため、少し偏執的である必要があります。そうしないと、問題は発生しません。問題がどこにある可能性があるかについて心を開いて、関連するシステムに関する知識を持ってナビゲートする必要があります。 ここでの主な目標は、「問題はそこにあるはずがない」と主張しないようにすることです。信じられないなら証明してください。それがどれほど不可能に見えても、そうであると思われる場合は、それをさらに掘り下げてください。 コードの目的を明確にする コードの目的が不明な場合は、それが問題の原因であるかどうかに関係なく、時間をかけて理解してください。いつでもいくつかのテストを配置して、それが何をするかを文書化することができます。動作が正しいかどうかわからない場合は、助けを求めてください。明確になったら、テスト、XML 文書、または外部文書のいずれを使用する場合でも、知っていることをすべて文書化してください。 一度に 1 つの問題を修正する コードの一部が非常に悪い場合、元の問題をデバッグしているときに他の問題を発見する可能性があります。そのような場合、最初に取り組まなければならない問題を決定し、その問題に専念することが重要です。 完璧な世界では、1 つの問題を解決し、コードをバージョン管理に検証してから、次の問題を修正します。これにより、コードのどの変更が後で動作のどの変更につながったかを簡単に判断できます。これは、1 つの問題を修正すると他の問題が発生することが判明した場合に重要です。 コードをデバッグに役立てる ログはデバッグに非常に役立ちます。デバッガーが役に立たないかもしれない地面からの情報を提供できます。ただし、デバッグと同様に、ロギングも注意深い技術です。正しく行わないと、可能な限り最善の方法で支援できない可能性があります。そのため、コードで例外がスローされた場合は常に、例外のメッセージだけでなくスタック トレースもログに記録するようにしてください。 例外は基本的に、ログに記録せずに黙って飲み込むべきではありません。これらは、ユーザー入力または構成設定を確認する最も簡単な方法である場合があります。このような状況では、ロギングは真の友となります。 同様に、コードを不正な入力に耐えられるようにします。不良入力の検出が早ければ早いほど、問題の発見が容易になります。値がいくつかの方法で処理された後にのみ期待値が得られる場合、問題の原因を突き止めるのは難しい場合があります。コントラクトは、ここで制約を定義するのに役立つ可能性があります。それ以外の場合は、将来問題が疑われる場合は、警戒して検証を追加する必要があります。 デバッガーについて学ぶ ジェダイがライトセーバーなしでは偉大になれないのと同じように、デバッガーの機能を知らずに優れた開発者になることはできません。最新のデバッガーには多くの機能があり、開発者が気付いていないためにほとんど使用されていません。たとえば、条件付きブレークポイントまたはデータ構造のユーザー定義表現は、1 日続くデバッグ セッションと 10 分間だけ続くデバッグ セッションの違いを生む可能性があります。 すべてを暗記する必要はありませんが、デバッガーで何ができるかについての適切な考えと、ステップ オーバー、ステップ イン、ブレークポイントの設定、実行の再開などの基本的な機能に関連するショートカット キーに関する十分な知識が重要です。 . 人々を巻き込む デバッグは、士気をくじく可能性があるため困難であり、文書化されていないコードの迷宮で作業すると、すぐに身体的疲労につながる可能性があります。これを考えてみましょう：行き詰まったら、休憩を取って、散歩に行って、コーヒーを食べたり、チョコレートバーを食べたりしてください。 他の誰かを含める必要がある場合でも、恥ずかしがらないでください。コードの動作が信じられないように思われる場合、またはどこを見ればよいかわからない場合は、尋ねてください。他の人が何をしているかに注意してください。彼らから学び、以前に観察した袋小路に向かっているように見える場合は警告します。何を観察したか、何を考えているかを彼らに知らせてください。ディスカッションでヒントが得られるかもしれません。 最後までテスト 問題を解決したと思ったら、できる限りのことをして (理にかなった範囲で) テストしてください。明らかに、単体テストが最初の呼び出しポートになるはずです。問題を切り分けるために導入した単体テストは成功するはずですが、他のすべてのテストも成功するはずです。 高レベルの問題は、多数の低レベルの問題によって引き起こされることがよくあります。最初の低レベルの問題を見つけて修正し、高レベルの問題がなくなると想定するのは簡単です。場合によっては逆のことが起こります。より重大な低レベルの問題の結果として、高レベルの動作が悪化します。その場合、すべてが正しく機能していることを確認するまで、修正とテストを続ける必要があります。 潜在的なエラーの監査 グループで問題が発生することがよくあります。たとえば、あるインスタンスで誰かがユーザー入力に対して十分なエスケープ/エンコーディングを行うのを忘れていたことに気付いた場合、別のインスタンスでも同じ問題が発生する可能性があります。可能性のある問題をすべて一度に迅速に監査する方が、完了したばかりの同じ調査を他のエンジニアが実施するなど、個々の問題を個別の問題として提起するよりもはるかに安価です。 同様に、パッチの結果を考慮してください。短期的には修正できない可能性のある別の場所で問題が発生する可能性はありますか?パッチやアップグレードに影響はありますか?製品ライフサイクルのこの段階で重要な修理ですか?通常、何が問題なのかを突き止めることは常に価値がありますが、場合によっては、コードを壊したままにしておいた方が安全な場合もあります。場合によっては、原因ではなく症状に対処する「応急処置」の修復を行う可能性があります。これは、バグ レポートをそのままにしておくべきだという意味ではありません。 修正の提案がある場合は、パッチ ファイルを作成してバグ レポートに追加してみてください (もちろん、どのファイルのどのバージョンにパッチを適用する必要があるかを明確にします)。少なくとも、後で時間を無駄にしないように、バグ レポートで調査の詳細な説明を提供してください。 「次のリリースを解決する」(またはそれに相当するもの) のバグ ステータスは、「これを実際に修正する可能性は低いですが、一度に 1 つずつリリースを遅らせます」ではなく、それを示す必要があります。 結論 これらの推奨事項は、1 日か 2 日でプロのデバッガーになることはできませんが、忍耐と適切な実践に従えば、正しい方向への出発点として確実に役立ちます。高品質のコードは偶然ではなく、忍耐と精度が必要です。 この記事は以上です。上記のデバッグのヒントについてどう思うか教えてください。プロのデバッガーになるためのアプローチ、ヒント、コツを下のコメント欄に自由に追加してください。 読み続けます！
