本物のプログラマはデバッガを使用しますか？[閉まっている]

経験豊富なプログラマーが実際にデバッガーを使用する場合、および使用する場合はどのような状況で使用するか。その質問に対する答えでは、「数か月」前に言ったが、おそらく「年」を意味していた-私は実際にデバッガを使用していません。私の具体的な回答可能な質問は、どのような状況下で、経験豊富なプログラマーとしてデバッガーを使用しますか？

デバッガーを使用しないことは、経験不足の兆候だと思います。コードを1行ずつステップ実行することが、実行の流れを追跡するための最良の方法です。

デバッガーを頻繁に使用します。なぜなら、私は大規模なシステムで作業しているので、それが嫌だからです。 http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

コードがどれほど短く頻繁に読み取られても、バグが発生する可能性は常にあります。http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

間違いは人間であり、プログラムが正しいことを決して証明できないので、この困難なビジネスで自分自身を支援するためにデバッガ/自動テストなどのツールを使用してみませんか？

コードが十分に短い場合、簡単なテストが実行されます。また、それが短く、バグの性質を知っている場合は、コードを読むだけで十分です。ただし、コードベースが大きくなり、いくつかの言語が混在し、さらに3つの層が含まれる場合は、多くのレベルで優れたテストカバレッジと非常に優れたデバッガーを用意する必要があります。

だから、いつデバッガーが必要ないのですか？

私は最も賢いコーダーでも、経験豊富なコーダーでもありませんが、それでもデバッガーを使用する必要がない場合があります。それは次の場合です：

• コードは私のものか、よく書かれているAND
• 読みやすい言語で書かれている
• プロジェクト全体は小規模です。

デバッガに大きく依存するのはいつですか？

• 短い答え：多くの場合。
• アプリケーションがクラッシュしたとき。特に、それが展開されるとき。そのコンピューターにVS2010をインストールすると、「不明なエラー」とFileNotFoundException。
• サードパーティのライブラリがクラッシュしたり、不正な動作をしたとき。
• コードが不完全に書かれているとき。特に、過去10年間に10人のユーザーが同じファイルに触れた場合、そのうち7人は会社にいません。
• プロジェクトが大きい場合
• コードがかなりモノリシックな場合。
• 複数の層（GUI、SQL、BL）が関係している場合。

「デバッガ」は複数のツールを参照できることに注意してください。Visual Studioデバッガー、SQLデバッガー（主にストアドプロシージャ用）、およびSQLプロファイラーも使用します（どのSPが呼び出されているかを把握するため）。簡単なシステム管理者用のPythonスクリプトを書いていたこの口径のツールが必要でしょうか？いいえ。独自の小さなGUIベースのツールを作成した場合は？依存します。.Net WinFormsの場合-おそらくそうではありません。WPFの場合-はい。

とにかく「本当の」プログラマを定義するものは何ですか？速いの？知識がある？アルゴリズムが得意ですか？適切なドキュメントを作成しますか？まさにこの新しいタイトルに卒業したのはいつですか？いつ魔法の線を越えますか？

私は、既存の100年以上の努力で手を汚していないプログラマーは、複雑さと自身の制限（およびコード品質に不満を抱いている）に謙虚になる機会がなかったと思います。

私は個人的に私が利用できる最高のデバッガーを使用しようとしていますが、頻繁に使用する傾向があります。タスクが十分に単純で、デバッガーを必要としない場合-私はそれを使用しません。必要かどうかを判断するのにそれほど時間はかかりません。

...

理論的には、コードベースを非常に長い間読むことができたので、すぐに理解できました。ただし、実践的なアプローチが最も効果的です。また、私が見ているその愚かなコードを書き直したいことがよくあります。残念ながら、現在のコードベースをクリーンアップするには10年以上かかります。そのため、デバッガーを使用することは明らかな最初のステップです。500万行のコードのうちどれが機能しているのかを見つけた場合にのみ、ファイルを上下にスキャンして、そのクラスが何をしているかを理解しようとします。

「デバッガは好きではありません。決して持っていないし、おそらく決してそうしません。」— ライナス・トーバルズ

一方、彼はStack Overflowアカウントを持っていないので、彼の意見に興味があるかどうかはわかりません:)

私の具体的な回答可能な質問は 、どのような状況下で、経験豊富なプログラマーとしてデバッガーを使用しますか？

• コードを読み取って「デバッグ」できない場合。
• 特定の変数が特定の時間を持つ値を予測できない場合。
• あなたの場合はメンタルモデル、コードのは、あなたのコードによって与えられた出力に適合しません

編集：

私は、プログラミングの旅でデバッガーを使用する方法を知らないという幸運/不幸を経験しました。したがって、過去には、デバッガなしでデバッグする必要がありました。ただし、デバッガーの使用方法を学んだ後、バグを見つける際の生産性が100倍になりました。

現在の回答とは少し異なる視点を与えるため。多くの場合、リアルタイムコンポーネントを備えたシステムで作業する組み込みソフトウェアエンジニアとして、私はほとんどデバッガーを使用しません。

ときどきデバッガは素晴らしいツールになり、デスクトップでコードをビルドして実行できるときはいつでも、デバッガを常に使用します。

オンチップでは、リアルタイムの制約により、デバッガーを使用しようとすると大きな負担がかかります。実行を一時停止するとすぐに、システムの残りの部分のタイミングが動揺し、場合によっては致命的になります。通常、オンチップでは、クリティカルではないコードのprintfとタイムクリティカルなコードでのIOワグリングが、最良かつ実際に最も簡単なツールです。デバッガほどではありませんが、実際のシステムで作業する方がはるかに安価です。

経験豊富なプログラマーは、必要に応じてほとんど独占的にデバッガーを使用すると思います。実際にコードの実行を追跡するよりも、バグを追跡するより良い方法...

あなたは世界のスキートが間違いを犯さないか、すべてを知っているという仮定の下にありますか？状況によっては、最も些細なプログラムを除くすべてが予期しない動作をします。問題を調査する必要があることは当然です。そのため、選択肢は、スペクトルの一方の端でprint文を使用するか、もう一方で事後を調べるか、コードの実行中に何が起こっているかを調べて、真ん中を見るかです。

たぶんそれについてのより良い考え方は、経験豊富なプログラマがデバッガをいつ使用するかを知っていることです。スタックトレースを調べる依存関係の少ないコードでは、おそらく何が問題なのかを判断するのに十分です。しかし、コードが他のコードと連携している複雑なシナリオがあり、あなたが書いていないものを見るためにデバッガが必要です。

私はそうではなく、10年以上プログラミングを続けています。以前は、c / c ++でプログラミングしたときに使用していました。今、私はJavaでプログラムします。真実は、正しくロギングを行っている場合、ほとんどの熟練した開発者にとって十分なスタックトレースになることです。また、（良い）単体テストと機能テストを書いている場合、クラスのバグ全体を排除します。

誰も気にしない？私が知りたいのは、デバッガーを使用すると、長期的にはより良いプログラマーになるのを妨げるでしょうか？多くの経験豊富な開発者が作業を開始したとき、デバッガーの品質は低かったので、それらは障害となりました。より深い理解を妨げるのは松葉杖ですか？

一部のプログラマは、おそらく他の人よりも優れていて、デバッガーの必要性を発見し、デバッガーを作成しました（最初のデバッガーを作成したユーザーはわかりません）。その結果、生産性が向上したと確信しています。私はその動機が、より少ない人間がコードを書くことを可能にすることであったとは思わない。

まれに。

あなたのメソッドはあなたの心でコンパイルされ実行されるのに十分なほど小さく/単純でなければなりません、ユニットテストは機能性をカバーするべきです。バグを見つけたら、テストを書きます。実行して修正してください。

私はiveがASP.NETフレームワークのようなテストできないコードから予期しない動作をしたときにのみデバッガーを使用する傾向があります。

Smalltalkでは、ほぼ完全にデバッガーで開発します。

1. 失敗することがわかっているテストを作成します。
2. テストを実行します。失敗すると、デバッガーがポップアップします。
3. テストに合格するために必要なコードをデバッガーで作成します。
4. 実行を再開します。
5. 緑色のライトが点灯した場合は、新しいテストに失敗してステップ1に進みます。そうでない場合は、デバッガーで私が間違ったことを見つけて修正します。

必要なときにデバッガーを使用します。それは毎日ではありませんが、時々起こります。コードをステップ実行して正確に何が起こるかを確認する方が良い場合があります。

デバッガーの使用はますます少なくなっていることを認めなければなりません。私はDelphiで10年以上開発してきました。PL / SQLでストアドプロシージャも記述します。数ヶ月以来、私もPHP開発者です。

何年も前に書かれたあいまいなコードを見つけて、それを修正する必要がある場合、これらのケースのいずれかで主にデバッガーを使用します。コードを読みにくい場合、プログラムの正確な動作方法を見つけるのに役立つことがあります。PHPではほとんど必要ありませんが、イベントベースのDelphiでは、複雑なフレームワークを取得するときに役立つことがあります。

しかし、あなたが言うように、デバッガーの使用は例外です。ほとんどの問題は、コードを読んで、自分（または他の誰か）が犯した間違いを修正するだけで解決されます。

しかし、それはコードをステップスルーするために行く。例外が発生したときにコールスタックを頻繁に使用し、変数を検査するためにブレークポイントをどこかに置くことがあります。しかし、とにかく徹底的なリファクタリングを必要とするコードの一部ではほとんど常に。

私はときどきデバッガなしでコーディングしますが、それは銃を突きつけられたときだけです。8051またはZ80のレガシー埋め込みガンジ。

私見、あなたはデバッガと複雑なジョブにログオンする必要があります。一度は他の代替ではありません。アプリがドライバーに詰め込んでいる場合（たとえば、コードでできることはハードウェアとやり取りしてセマフォを設定することだけ）、ロギングシステムは役に立ちません。

デバッガは、アプリが記述した方法に従って正常に動作しているシステムエラーを解決できませんが、通信プロトコルエラーが断続的に発生するため、システムは動作しません。

だから、バカで目立つバグやハードウェアのコックアップを取り除くためにデバッガが必要です。断続的なシステム統合のバグをキャッチするには、適切なログが必要です。

両方持っていなければならない-私は得ることができるすべての助けが必要です！

これらの手順が失敗した場合にのみ、デバッガーを使用します。

1. 再現可能なエラーを取得します。考えて。多くの場合、これで十分です。
2. スタックトレースとログを確認します。
3. 問題のあるコードの周りにログを追加します。

これらの手順は、すべてのケースの95％を処理します。つまり、デバッガーを使用することはめったにないので、使用すると情報が多くなりすぎる傾向があります。なりて、関連のない詳細に行き詰まってしまいます。これは、マルチスレッドのリアルタイムシステムで作業する場合に特に当てはまります。

したがって、適切に配置されたロギングステートメントは大いに役立ちます。

非常に経験豊富なプログラマーは非常に古いプログラマーと同じであり、デバッガーが常に利用可能ではなく、時にはあまり良くないときに戻ってプログラミングを学び、習慣を形成したということでしょうか？

printfのデバッグが非常に上手になった場合（80年代に戻った場合、あまり良い選択はありませんでしたが、本当に上手になりました）、おそらくデバッガーはそれほど追加しません。

それは個人的な選択の問題です。

正直なところ、デバッガはプログラムの実行の任意のステップでRAMの状態を知るのに役立つ特定の状況で役立つと思います。

デバッガーの主なユーティリティは、プログラムを停止することなくプログラムを停止することです。この機能は非常に重要です。

これら2つの機能は別として、デバッガーは本当に必要だとは思いません。作成する複雑なプログラムには、何らかの「冗長」モードが必要です。つまり、printfまたはstd :: coutで実行していること、選択した内容、その他の多くのパラメーターを伝えます。

あなたがプログラムを作成し、ユーザーがそれを使用する際に問題を抱えていると想像してください。

デバッガーは、あなたの車の電動ステアリングのようなものです。1つ持っている方が快適ですが、ドライブが良くなることはありません。

プログラムとは設計とロジックに関するものであり、ツールが物事を追跡するのに役立つ方法では、優れたプログラマーにはなりません。

Plusデバッガーは、コンパイルされた言語に役立ちますが、解釈された言語にはあまり役立ちません。