優れたプログラマーになるには、デバッグスキルが重要ですか?


24

プログラマーは、他の品質とともに、優れたデバッグスキルを必要としますか?特定のプログラムでエラーを見つけることができなかったが、すべてのパズルとプログラムを解決できた応募者がいる場合、その仕事を検討する必要がありますか?

編集:-パズルは、通常の赤、青、赤青のボールのようなものです。プログラムは、配列内で連続したk個のゼロを見つけるようなものです。デバッグプログラムは、> =である必要がある条件のために失敗するものですが、代わりに>です。すべてが紙の上にあります。


13
彼はプログラムを実行することを許可されましたか、それともコードを見てエラーを見つけなければなりませんでしたか?
マイケルK

9
デバッグできる範囲内でのみコーディングできます。二人は私の本で手をつないで行きます。
デミアンカシエ

3
他の人よりも上手な人もいます。多くの場合、特にストレスの多いインタビュー中に、外国のコードの一部のエラーを見つけることは困難です。
leed25d

6
@Fanatic:自分のコードだけで作業している場合のみ。私が仕事で行うデバッグのほとんどは、他の人のエラーを掘り起こすことです。
メイソンウィーラー

3
@Manoj R、同じ時間で同じ問題を見つけることができると確信していますか?申請者が20分で紙に問題を見つけなかったからといって、彼女がGoogle(はい、Googleをクソ)を使い、数週間の練習を重ねてもうまくいかないのですか?
仕事

回答:


37

はい、非常に重要です

特定の候補については、コードベースxをデバッグするのに十分な知識がなかった可能性があります。

通常必要とされるのは非常に論理的な方法/アプローチを持つことだけなので、優れた問題解決者はデバッグできるはずです。


1
他のプログラミング、デバッグのスキルは経験が豊富で、才能とはあまり関係がありません。
ピーターB 14年

24

デバッグできない場合、あなたはプログラマーではなく、良いプログラマーです。

デバッグは、技術的なスキルだけでなく、分析能力や思考プロセスの実際の実用的なアプリケーションです。結果として、ホワイトボードやインタビューの質問よりもはるかに有用で関連性の高いテストとして評価します。

あなたが持っている仕事が理論の質問に答えるために一日を費やすことを伴わない限り、あなたは彼らが持っているどんなスキルでも適用できる誰かを必要とします。

ただし、デバッグ能力の公正なテストであるかどうかを自問する必要があります。実際の世界と同じように、コードを実行したり、ブレークポイントを設定したりできますか?どのようなエラーでしたか?コンパイラが拾い上げてフラグを立てるものですか?(その場合、それを見つける必要はないので、それはかなり無意味な質問です)?

それが紙に書かれたばかりの場合、それは基本的に詳細な読解テストであり、それはあなたの平均的な技術面接の質問よりもさらに抽象的なスキルであり、私はほとんど価値がないと主張します。


2
+1「デバッグ能力の公正なテストであると自問してください」-そうではなかったように聞こえます。公正なテストは、すなわち、自然、通常の作業環境に入れて(彼らはめったにサンセリフデバッガを作業していないことになります考慮して)デバッガで実行可能なコードが含まれているでしょう。
doppelgreener

11

主な採用ルール—間違いなくノーと言う。

多くの新しいコードを安価で実装する必要がある場合は、その人を入手できますが、個人的には検索を続けます。


7
私は長年多くの人を雇っており、私が雇ったほぼすべての「たぶん」候補者を後悔しています。
JohnFx

10

開発者が常にクリーンなコードを記述し(絶対に不可能)、「グリーンフィールド」プロジェクトでしか作業できない場合(そうでない場合)、そうでない場合、デバッグスキルは絶対に不可欠です。絶対に。私はデバッグしたくない開発者との経験があったので、彼らは怠け者になり、テストのためにQAにコードを投げかけました。しかし、それらの開発者はまったく長続きしません。

ソフトウェア開発は技術であり、問​​題解決のスキルです。これらの問題には、ビジネス上の問題と、その(および他の)コードの問題の両方が含まれます。ところで、多くのメンテナンスプロジェクトは特にバグの修正に関するものであるため、デバッグは絶対に不可欠なスキルです。


もう1つ追加したいこと...ここでのインタビュープロセスの一部は、候補者にアプリケーションのデバッグといくつかの小さな機能を追加するための演習を行うことです。このプロセスのすべての部分は同様に重要として扱われます。
マークフリードマン

7

「インタビュー質問」タイプのウェブサイトがたくさんあることを心に留めておいてください。そして、非常に多くの質問やパズルを勉強することは完全に可能です。あなたは一つのことができないために勉強はあなたが前に見たことがないコードをデバッグしています。デバッグ方法を知っているほど十分なコードを書いているか、していないかのどちらかです。それがエントリーレベルのポジションであれば、私は候補者を除外しませんが、彼らが言語の経験があると主張し、その中のコードをデバッグできない場合、それは確かに赤旗を上げます。


5

ジュニアプログラマとシニアプログラマの間に見た主な違いは、デバッグのスキルです。デバッグのスキルは、実践と経験によってのみもたらされるものです。

たとえば、Javaプログラムは対話モードのコンソールでは正常に動作するが、同じ入力にUnixパイプを使用しようとすると失敗するという奇妙なバグを考えてください。以前にこの問題に遭遇したことnew Scanner(System.in)がある場合、一度だけ呼び出されることを確認するためにチェックするかもしれません。バグは、パイプされたときにバッファを消費することですが、明らかに対話モードではそうではありません。私は、上級のプログラマがこのバグをより早く特定することを期待しています。おそらく、彼らがそれを以前に経験したことがあるか、過去にバッファリングに関する他の問題があったからでしょう。

パズルの解法と新しいコードの作成については、経験が重要ですが、これはジュニアレベルのプログラマーが上級プログラマーと同等以上のパフォーマンスを発揮できる場所です。つまり、インテリジェンスとスキルは、経験とは無関係に、より大きな効果を持つことができます。

新しいアイデアを持ち、チームの「ゲル化」を支援できるジュニアプログラマーに投資する立場にあり、新しいコードを書くのが問題ないようであれば、先に進んで採用してください。上級レベルのプログラマーを探している場合、このデバッグスキルの欠如は重大な警告サインである可能性があります。彼らは最初の1年を10回経験するだけの10年の経験があるかもしれません。

補足として、最初に10年の経験がなくてもデバッグを改善する方法があります。科学的原理を学び、失敗を再現、発見、修正する方法をよりよく理解する方法として、Andres Zellerの著書「Why Programs Fail:A Guide to Systematic Debugging」をお勧めします


したがって、デバッグは実践によって行われるものであり、学習することができます。また、候補を選択する際にあまり重視するべきではありません。
マノジR

1
明確にするために、上級開発者の場合は重く考える必要がありますが、ジュニア開発者の場合はそれほど重要ではありません。たとえば、大学を卒業して1年生のプログラミングを始めた人は、何かをデバッグするのに10倍の時間がかかる場合があります。しかし、ジュニア開発者に投資する正当な理由があります。
マクニール

5

環境によって異なります。数独やその他のパズルを終日プレイするなら、おそらくそれが良い候補でしょう。

ただし、コードにバグがある場合や、常に期待どおりに動作しない場合は、トラブルシューティングが得意な人に依頼することをお勧めします。

プログラマがどうあるべきかの理想ではなく、あなたが必要とするものを雇う。


3

プログラマーは、他の品質とともに、優れたデバッグスキルを必要としますか?

はい。

コードのデバッグは問題解決の一部です。完璧なコードとゼロバグを書いた開発者に出会ったことはありません。開発者は自分のコードをデバッグするか、他の人のコードをデバッグします。必需品です。

彼を仕事に就かせるべきか?

たぶん、それは依存します。

面接でプログラムをデバッグできないことは、申請者が面接で他のすべてのパズルやプログラムを完了することができた場合、おそらく契約を破るべきではありません。インタビューの深さと息に本当に依存します。

位置にはどのくらいのデバッグが必要ですか?たくさんの場合、申請者がデバッグの質問にどれだけうまく答えることができるかにより大きな重みを付ける必要があります。しかし、デバッグに関する質問が1つだけ聞かれたとおっしゃっていたので、そうではないようです。


2
+1デバッグを繰り返すために必要ですが、面接中に対処する必要はありません。
ガウラブ

3

プログラマは優れたデバッグスキルを必要としますか?

はい。そうは言っても、多くの人が紙のコードを奇妙で馴染みのない経験であると思うので、インタビューの方法論(すなわち、クイズ/テストスタイル)を完璧ではない(大丈夫、欠陥)と考えてください。

以来デバッグがあるプロセスではなく、答えや結果(例えば間違い)、私は能力をデバッグする候補者を評価するためのより良い手段として、インタラクティブな対話や議論を使用してお勧めします。ほとんどの人は非公式のアドホックデバッグシステムを使用しますが、良い候補者は一般に同様のパターンを持ち、システムや仮定、要件を理解するための質問をして、問題を分離し(しばしば分割して征服し)、系統的に比較します要件へのコード、および予想される入力/出力を評価するのではなく、行き当たりばったり、それが動作するまで無計画に一度物事の束を変更します。

また、インタビュー中のパズルの問題については、特に書面で、候補者が参照の枠組みの適切な仮定を持っていないかのように留保を表明します(トリック)、パズルは彼らに解決できないかもしれません。すなわち、多くのインタビューパズルは正しい道をたどることに苦しんでいますが、人生は複雑であり、最も創造的な思考は、特定の事前調理済みのパズルではうまくいかない可能性のある問題を予想される解決策で解決するために驚くほど斬新なアプローチをとる人たちです。すべてのトランペット奏者がジャズを演奏することを期待するようなものです。これは、質問を非対立的(圧力が創造性を混乱させる可能性がある)インタラクティブな議論として尋ねることによって管理できます。繰り返しになりますが、私にとっての答えは、良い思考プロセスが表現されていることを確認することです。大声で考えるように彼らに頼む必要があるかもしれませんが、これは私の経験でより生産的である傾向があります。

私はZellerのWhy Programs Failを読んだり評価したりしていませんが、Agansによるデバッグは、アドホックデバッグプロセスをより構造化された、具体的で組織的な努力に固めるのに役立つ短いクイックリードとして推奨できます。デバッグがより効率的になります。また、コピーを印刷して、キュービクルまたは回避策であるデバッグルールのポスターに貼り付けてください。これは、何もうまくいかないように思われる悪い日を思い出させるものです。悪い日はほとんどありません。また、書面ではない場合は精神的にフォローしようとすることで、積極的にデバッグする時間を減らします(読む:混乱して頭をかく)。


素晴らしい答え。私は文字通り何日も最も単純なバグ修正の検索に費やし、文字通り数分で厄介なバグの修正につまずきました。優れた開発者には合理的な戦略が必要です。そして、それはアプリに大きく依存します。大量のprint / logステートメントを入力したり、シンボルを使用してバージョンを実行したりしても、アプリで問題が発生しないとしましょう。それで何?申請者は、少なくとも何らかの一貫性のある戦略を明確にできる必要があります。
SnoopDougieDoug

2

プログラマーが優秀で間違いを犯さない限り、デバッグは不可欠だと思います。私はそれが不可能だとは思いませんが、現在の一般的な言語やツールでは想像できません。

インタビューでそのような場所に置かれるというコンセプトは嫌いです。候補者が緊張している場合(そうでない場合)、プログラマはそのような問題を日常的に処理できる可能性があるので、彼/彼女は空白の筆を描くことができます。それから、もしそれがよく知られているインタビューやcomp-sciテストの問題であれば、候補者は結果を暗記するかもしれませんが、新しい問題を自分のやり方で考えることはできません。また、候補者が言語に精通していない場合、彼は苦労する必要があります。優れたプログラマーは自分が何を入力するのかを知っているため、多くのバグは困難であり、彼の脳はコードを読んでいる間、ショートカットを取得します。意図が何であるかを知っているので、Cスタイルの=の==は検査で使用されるはずでしたが見つかりません。私の脳はそれを読んで解析のショートカットを取るでしょう。


1

プログラミングの問題解決の大部分であり、問​​題を解決するには、症状や矛盾だけでなく中核の問題を知る必要があります。デバッグは、コアの問題を特定する技術です。

  • コアの問題を特定する
  • フローをよりよく視覚化できる

などなど。


1

エラーを指摘し、その人がどのような反応をするかを確認するために、状況にもう少し追加します。彼らは、「D'oh!私は馬鹿だ、とても馬鹿だ...」タイプについて過度に無関心であり、「ええ、どんな男でも」キャンプで、またはそこに積極的に耳を傾けていましたかある種の謝罪や、彼らが解決すべきはずの何かを台無しにしたことを示す発言が間違っている?将来の状況で考えてみてください。

タイムリーにデバッグすることは素晴らしいスキルです。これは、修正されたときに修正される問題を誰かに与えることとは少し異なります。システムを保存するために積極的な対策が必要な場合があります。ほとんどの企業は、会社が使用している会計ソフトウェアのバグを修正している間、ほとんどの企業が数週間販売を停止することを望まないため、認識されるべきです。


1

デバッグは重要なスキルです。実際には、トラブルシューティングは非常に重要なスキルであると言います。誰かが問題を定義する方法(どのユーザー情報を求めるか、どのログを調べるかなど)、問題を再現する方法、問題を診断するために利用できるデータソース、デバッグする方法、1つの問題を修正する方法を知っている必要があります他の何かを壊すことなく。ただし、インタビュー中にそれを判断することは困難です。

私は彼に見つけるべき本当の問題と利用可能なツールを使用する機会を与え、彼が問題を見つけるためにどのような手順をとったか、割り当てられた時間内に問題を見つけられなかった場合に彼が他に何をするかもしれないか尋ねます。あなたは本当に組織的に問題を攻撃し、デバッガーとグーグルよりもツールキットに多くのツールを持っている人を本当に探しています(ジュニアレベルでは、両方を最低限試す必要がある場合を除きます)これらの2つのことを試してみると、おそらく有能ではないか、少なくとも私は彼にチャンスを与えません)が、おそらくまだ多くの高度なトラブルシューティングツールはありません)。

トラブルシューティングスキル(パズルはまったく質問しません)やデモプログラミングスキルよりも、トラブルシューティングスキルに重点を置きます。良いコードを書くことも、必要な修正を行うこともできない、うまくトラブルシューティングできる開発者を見たことはほとんどありません。いくつかのコードをまとめて「動作する」製品を得ることができる人がたくさんいますが、彼らの生活がそれに依存している場合は問題を解決できませんでした。ほとんどの場合、彼らはしないので、実際に彼らが何をしているかを理解していないか、解決しようとしている問題を理解していない。優れたトラブルシューティング担当者は、症状だけでなく実際の問題を特定する方法を知っています。彼らは、新しい開発の問題を定義するためにどのような質問をするべきかも知っています。


1

どの仕事にも4〜5つの主要なスキルがあり、プログラミングも同じです。プロフェッショナルレベルでは、すべての主要な基本スキルが必要です。5つのうち4つを持っている場合でも、あなたを引き留めます。

顧客を提示し、説得し、明確にし、資格を得ることができるが、取引を成立させることができない営業担当者を想像できますか?彼らはそこにあり、あなたはあなたの販売チームにそれらを望んでいません。

デバッグは間違いなく、プログラマが欠かせないコアスキルです。


0

このようなコーディングスタイルがあり、最小限のデバッグが必要です。3行のコードが完成したら、それを実行してテストします。多くの場合、いくつかの変数を出力します。場合によっては、不要な結果や動作が発生したときに、デバッグの代わりにコードに多くのダンプを入れました。私は非常にまれな実際のデバッガーを使用します。奇妙ですが、本当です。


0

デバッグは、ソフトウェアで特定のテストが行​​われ、バグが発見された後に行われるソフトウェア開発の段階です。ソフトウェアのバグを検索して修正する行為です。多くの場合、バグを見つけるには通常、修正に時間がかかります。

これは、コンピューターのアプリケーション/システムに固有のバグ(脆弱性)を削除するプロセスです。これが行われない場合、ハッカーはバグを利用し、さまざまな悪意のある活動を行う可能性があります。

1)脆弱性が一般に公開され、開発者とベンダーの収益、ビジネス、評判が失われる可能性があります。

2)ワームは、悪用可能な脆弱なシステムを検索するため、それらのサーバーに自分自身をコピーします。例えば。2003年1月、Slammer WormはMS SQL Serverの脆弱性を利用しました。

3)ワームが言及されている場合、ウイルスをどのように忘れることができますか。ウイルスはまた、わいせつな露出の主な目的のためにプログラムに存在するバグを利用する開発者によって失われます...

4)そして、プログラムが適切にデバッグされていない場合、消費者はお金の価値を得ることができなければ、決して完全に維持するつもりはありません。その場合、汚い仕事をするのにハッカーさえ必要ありません。あなたは、古き良き公衆を信頼するかもしれません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.