プログラミングインタビュー：プログラムのデバッグ方法は？
私は最近インタビューで次の質問をされました：
C++プログラムをどのようにデバッグしますか？
まず、プログラムに構文エラーと意味エラーがある可能性があることを説明しました。コンパイラは修正可能な構文エラーを報告します。セマンティックエラーについては、さまざまなデバッガを使用できます。具体的には、コマンドラインであるgdb、およびGUIを備えたVisual Studio IDEのデバッガーと一般的なコマンドについて説明しました。また、コードのデバッグバージョンとリリースバージョン、アサーションをデバッグビルドに使用する方法、例外が自動クリーンアップとプログラムを有効な状態にするのにどのように役立つか、ロギングがどのように役立つか（例：std :: clogを使用）についても話しました。
この答えが完全かどうか知りたい。また、構造化された方法で他の人がこの質問にどのように答えるのか聞きたいですか？
ありがとう。
そのようなあいまいな質問への答えは完全ではあり得ません。
これは、わざと曖昧になるように設計された質問の1つに聞こえます。過度のワッフルを避けて、質問の焦点を狭めるように依頼するべきだったと思います。あなたが述べたように、最初にエラーを構文と意味論に分類し、次にそこから答えを分岐します-しかし、両方が徹底的に議論することをすでに望んでいると想定しているので、あなたは単に話を続けました。
はい、あなたの言ったことは大丈夫ですが、インタビューの質問に答えた場合、誰もあなたに伝えることができません。
個人的には、「なぜC++の問題の種類をデバッグしているのですか？」 （Segmentation Faultは、ご存知のようにUnexpected ...とはかなり異なりますが、常に明確にする必要がありますインタビューでのあなたの仮定）そしてそこからそれを取り、私がそれを正確にそして大部分全体で答えることができるように質問が十分に絞られたら。次のように考えてみてください。「私の車が動かない、理由を教えてください」と彼らがちょうどあなたに言ったと想像してください。ほんの少しの情報で本当に答えようとしますか？
非常によく似た質問をするインタビュアーとして、私はいくつかの光を当てることができます。
まず、インタビューでは、2つのタイプの質問がよくあります。（1）何かを知っていることを証明します（実際には、これらはかなり明確な「正しい」と「間違った」回答を持っています）。（2）頭蓋骨を開いて、あなたの心がどのように機能するかを見せてください（これらにはもっと多くの灰色の色合いがあり、多くの非常に異なる答えがすべて良いことがあります）私は、「正しい」答えを探していないときにインタビュー対象者が確実にわかるようにして、彼らの考えを知りたいだけです。私にとって、この質問は2番目のカテゴリにあります。
「C++プログラムをどのようにデバッグしますか？」または、「C++プログラムをデバッグするにはどうすればよいですか？」。これは、2番目の質問に対する回答であったためです。一般に、インタビューでは、一般的な内容（つまり、コードのリリースバージョンとデバッグバージョンがあります）を聞き、次にあなたが個人的にそれをどのように使用したか（つまり、「プロジェクトXYZ Shroozlebobクラスが適切に初期化されていなかったため、デバッグバージョンのコードをデバッガーにロードしました... "）。もちろん、もしあなたのような答えが返ってきたら、例を求め始めたでしょう。面接対象者が面接に精通しているとは思いません。私は彼らが知識豊富なプログラマであることを期待しています。
私にとって、この質問に対する正しい答えは1つではありませんが、いくつかの答えは他の答えよりも優れています。あなたが私にあなたの答えを与えて、私が例を求めて、あなたが何も提供できないなら、私はあなたがあまり実際のデバッグ経験を持っていないと仮定しなければなりません。しかし、あなたが言ったことの良い例を私に教えてくれれば、それは良い答えになるでしょう。
私は@mhに敬意を払いません。これはトリックな質問ではありません。これは、デバッグと開発プロセス全般に関する議論を始めるための試みだったと思います。
あなたの答えは、特にアサーションと例外に関する部分の良い出発点です。しかし、もっと深く掘り下げることもできます。単体テストを書いていますか？そうでない場合は、そうする必要があります。バグは単体テストで検出されましたか？そうでない場合は、新しいテストを追加する必要があります。バージョン管理システムを使用していますか？ （繰り返しますが、そうする必要があります。）その場合は、最近のコミットログを確認して、バグの原因となった可能性のある変更を確認してください。以前のバージョンのバグを再現して、バグが導入された正確な時点を見つけることをお勧めします。
あなたのコードはきれいですか？ （Robert C. Martinによる「クリーンコード」を参照）。わかりやすい名前と明確な目的を持つ小さなクラスと関数がある場合は、コードを見るだけでバグを見つけることができる場合があります。そうでない場合は、問題のコードの一部をリファクタリングして、コードをより明確にし、エラーが発生しにくいようにするのが良いタイミングかもしれません。
ちなみに、バージョン管理と単体テストに関する質問は、文字どおりインタビュアーに尋ねるべきです。インタビューは、あなたを評価するのと同じくらいあなたが彼らを評価することについてです。
私はそれは完全ではないと思いますが、ジュニアのポジションには確かに受け入れられます。最も強力なデバッグツールは、コードを理解し、何をすべきか、何をすべきかを正しく推論できることです。しかしこれは野心的なことであり、私たちは皆不足しています。私たちはいつも、これまでに見たことのないコードをデバッグすることになります。デバッガはそのために最適です。また、ロギング機能をアプリケーションに組み込み、優れたドキュメントと明確なコードを記述することについても話しました。また、Valgrind、systrace、gprofなどのツールやWindows、またはJava同等のものに言及するのもよいでしょう。
見逃した場合があります。プログラムはエラーを出さないかもしれませんが、要件が誤って解釈されたため、これを反映するようにソフトウェアを変更する必要がある場合があります。プログラムに関する限り、何も問題が発生していないため、コンパイラーは例外をスローしません。
また、さまざまな種類のバグ、コンパイル時、実行時、および要件の変更から始めますが、次に、どのような種類のバグに直面しているかという質問にドリルダウンしますか？これはコード、データ、またはインフラストラクチャの問題ですか？ソースになる可能性のある場所はいくつかあります。プログラム用に書かれたテストを調べて、これがどこかでカバーされているのか、見落とされているのかを確認したいと思います。
それは私にとってセミトリック質問のようにひどく聞こえます-あなたを捕まえて、より単純な答えがするときに過度に複雑な答えをするようにあなたを罠にかけるように設計されています。
問題が何であるかを見つけ、再現ケースを取得し、デバッガーを使用し、完了したら回帰テストを行います。そのような単純な。
あなた自身の答えがこれの多くに触れているので、それは受け入れられるかもしれません。
この質問をしているのなら、もっと高いレベルの答えを探しているでしょう。 「バグ」とは、プログラムが実行していることとプログラムが実際に実行していることの間のギャップです。バグを見つけるための主要なツールは科学的な方法です。何が起こっているかについて理論を立てられるまで、デバッガー、ログ、コード変更などを使用して実験を実行します。次に、可能な限り多くのケースを使用してその理論をテストし、再度、意味のあるツールを使用します。理論に反証できなくなるまで繰り返します。何が起こっているかがわかったら、関連する変更を加えてから、修正をテストします。
含まれるツールは、バグと環境によって異なります。 「プログラムをどのようにデバッグしますか？」と質問すると、「デバッガ」の答えが返ってきます。私は大きな時間を延期します。ソフトウェアの作成方法を尋ねられたときに「エディターを使用して」と答えるようなものです。デバッガーはツールであり、業界のすべてのツールと同様に、品質は異なり、存在しない場合もあります。 "Visual Studio"は、Microsoftショップを見ている場合にのみ機能します。デバッガの接続が許可されていない物理デバイスで、問題がリリースモードでのみ発生する場合、あなたは麻痺しますか？
インタビュアーとして私が探しているもう1つのことは、特定の条件が与えられたときに何を探すべきかについての知識があることを示す問題に関する質問です。複数のスレッドを持つアプリでシステムがフリーズした場合のアプローチは何ですか？リリースモードとデバッグモードで動作が異なる場合のアプローチは何ですか？特定のコード行に結び付けることができないランダムなクラッシュが発生した場合のアプローチは何ですか？メモリリークを追跡するためのアプローチは何ですか？
もちろん、回答ではこれらすべてのケースでツールについて言及する必要がありますが、ツールはプロセスの副次的なものです。
この質問は曖昧すぎるとは思いません。インタビューするとき、ソフトウェアエンジニアリングプロセスについての深い会話につながることが多いため、このような質問が大好きです。それが起こるとき、あなたはあなたが適切な人を持っていることを知っています。 「完全な」答えや「正しい」答えなどはありません。重要なのは、質問を正しくすることではなく、質問を踏み台にして能力を示すことです。インタビュアーとして、あなたが「正しい」答えをオウムで返すことができると私が知っているよりも、これらの機会をあなたに与えることに興味があります。