プログラマーは、他の品質とともに、優れたデバッグスキルを必要としますか?特定のプログラムでエラーを見つけることができなかったが、すべてのパズルとプログラムを解決できた応募者がいる場合、その仕事を検討する必要がありますか?
編集:-パズルは、通常の赤、青、赤青のボールのようなものです。プログラムは、配列内で連続したk個のゼロを見つけるようなものです。デバッグプログラムは、> =である必要がある条件のために失敗するものですが、代わりに>です。すべてが紙の上にあります。
プログラマーは、他の品質とともに、優れたデバッグスキルを必要としますか?特定のプログラムでエラーを見つけることができなかったが、すべてのパズルとプログラムを解決できた応募者がいる場合、その仕事を検討する必要がありますか?
編集:-パズルは、通常の赤、青、赤青のボールのようなものです。プログラムは、配列内で連続したk個のゼロを見つけるようなものです。デバッグプログラムは、> =である必要がある条件のために失敗するものですが、代わりに>です。すべてが紙の上にあります。
回答:
デバッグできない場合、あなたはプログラマーではなく、良いプログラマーです。
デバッグは、技術的なスキルだけでなく、分析能力や思考プロセスの実際の実用的なアプリケーションです。結果として、ホワイトボードやインタビューの質問よりもはるかに有用で関連性の高いテストとして評価します。
あなたが持っている仕事が理論の質問に答えるために一日を費やすことを伴わない限り、あなたは彼らが持っているどんなスキルでも適用できる誰かを必要とします。
ただし、デバッグ能力の公正なテストであるかどうかを自問する必要があります。実際の世界と同じように、コードを実行したり、ブレークポイントを設定したりできますか?どのようなエラーでしたか?コンパイラが拾い上げてフラグを立てるものですか?(その場合、それを見つける必要はないので、それはかなり無意味な質問です)?
それが紙に書かれたばかりの場合、それは基本的に詳細な読解テストであり、それはあなたの平均的な技術面接の質問よりもさらに抽象的なスキルであり、私はほとんど価値がないと主張します。
開発者が常にクリーンなコードを記述し(絶対に不可能)、「グリーンフィールド」プロジェクトでしか作業できない場合(そうでない場合)、そうでない場合、デバッグスキルは絶対に不可欠です。絶対に。私はデバッグしたくない開発者との経験があったので、彼らは怠け者になり、テストのためにQAにコードを投げかけました。しかし、それらの開発者はまったく長続きしません。
ソフトウェア開発は技術であり、問題解決のスキルです。これらの問題には、ビジネス上の問題と、その(および他の)コードの問題の両方が含まれます。ところで、多くのメンテナンスプロジェクトは特にバグの修正に関するものであるため、デバッグは絶対に不可欠なスキルです。
ジュニアプログラマとシニアプログラマの間に見た主な違いは、デバッグのスキルです。デバッグのスキルは、実践と経験によってのみもたらされるものです。
たとえば、Javaプログラムは対話モードのコンソールでは正常に動作するが、同じ入力にUnixパイプを使用しようとすると失敗するという奇妙なバグを考えてください。以前にこの問題に遭遇したことnew Scanner(System.in)
がある場合、一度だけ呼び出されることを確認するためにチェックするかもしれません。バグは、パイプされたときにバッファを消費することですが、明らかに対話モードではそうではありません。私は、上級のプログラマがこのバグをより早く特定することを期待しています。おそらく、彼らがそれを以前に経験したことがあるか、過去にバッファリングに関する他の問題があったからでしょう。
パズルの解法と新しいコードの作成については、経験が重要ですが、これはジュニアレベルのプログラマーが上級プログラマーと同等以上のパフォーマンスを発揮できる場所です。つまり、インテリジェンスとスキルは、経験とは無関係に、より大きな効果を持つことができます。
新しいアイデアを持ち、チームの「ゲル化」を支援できるジュニアプログラマーに投資する立場にあり、新しいコードを書くのが問題ないようであれば、先に進んで採用してください。上級レベルのプログラマーを探している場合、このデバッグスキルの欠如は重大な警告サインである可能性があります。彼らは最初の1年を10回経験するだけの10年の経験があるかもしれません。
補足として、最初に10年の経験がなくてもデバッグを改善する方法があります。科学的原理を学び、失敗を再現、発見、修正する方法をよりよく理解する方法として、Andres Zellerの著書「Why Programs Fail:A Guide to Systematic Debugging」をお勧めします。
プログラマーは、他の品質とともに、優れたデバッグスキルを必要としますか?
はい。
コードのデバッグは問題解決の一部です。完璧なコードとゼロバグを書いた開発者に出会ったことはありません。開発者は自分のコードをデバッグするか、他の人のコードをデバッグします。必需品です。
彼を仕事に就かせるべきか?
たぶん、それは依存します。
面接でプログラムをデバッグできないことは、申請者が面接で他のすべてのパズルやプログラムを完了することができた場合、おそらく契約を破るべきではありません。インタビューの深さと息に本当に依存します。
位置にはどのくらいのデバッグが必要ですか?たくさんの場合、申請者がデバッグの質問にどれだけうまく答えることができるかにより大きな重みを付ける必要があります。しかし、デバッグに関する質問が1つだけ聞かれたとおっしゃっていたので、そうではないようです。
プログラマは優れたデバッグスキルを必要としますか?
はい。そうは言っても、多くの人が紙のコードを奇妙で馴染みのない経験であると思うので、インタビューの方法論(すなわち、クイズ/テストスタイル)を完璧ではない(大丈夫、欠陥)と考えてください。
以来デバッグがあるプロセスではなく、答えや結果(例えば間違い)、私は能力をデバッグする候補者を評価するためのより良い手段として、インタラクティブな対話や議論を使用してお勧めします。ほとんどの人は非公式のアドホックデバッグシステムを使用しますが、良い候補者は一般に同様のパターンを持ち、システムや仮定、要件を理解するための質問をして、問題を分離し(しばしば分割して征服し)、系統的に比較します要件へのコード、および予想される入力/出力を評価するのではなく、行き当たりばったり、それが動作するまで無計画に一度物事の束を変更します。
また、インタビュー中のパズルの問題については、特に書面で、候補者が参照の枠組みの適切な仮定を持っていないかのように留保を表明します(トリック)、パズルは彼らに解決できないかもしれません。すなわち、多くのインタビューパズルは正しい道をたどることに苦しんでいますが、人生は複雑であり、最も創造的な思考は、特定の事前調理済みのパズルではうまくいかない可能性のある問題を予想される解決策で解決するために驚くほど斬新なアプローチをとる人たちです。すべてのトランペット奏者がジャズを演奏することを期待するようなものです。これは、質問を非対立的(圧力が創造性を混乱させる可能性がある)インタラクティブな議論として尋ねることによって管理できます。繰り返しになりますが、私にとっての答えは、良い思考プロセスが表現されていることを確認することです。大声で考えるように彼らに頼む必要があるかもしれませんが、これは私の経験でより生産的である傾向があります。
私はZellerのWhy Programs Failを読んだり評価したりしていませんが、Agansによるデバッグは、アドホックデバッグプロセスをより構造化された、具体的で組織的な努力に固めるのに役立つ短いクイックリードとして推奨できます。デバッグがより効率的になります。また、コピーを印刷して、キュービクルまたは回避策であるデバッグルールのポスターに貼り付けてください。これは、何もうまくいかないように思われる悪い日を思い出させるものです。悪い日はほとんどありません。また、書面ではない場合は精神的にフォローしようとすることで、積極的にデバッグする時間を減らします(読む:混乱して頭をかく)。
プログラマーが優秀で間違いを犯さない限り、デバッグは不可欠だと思います。私はそれが不可能だとは思いませんが、現在の一般的な言語やツールでは想像できません。
インタビューでそのような場所に置かれるというコンセプトは嫌いです。候補者が緊張している場合(そうでない場合)、プログラマはそのような問題を日常的に処理できる可能性があるので、彼/彼女は空白の筆を描くことができます。それから、もしそれがよく知られているインタビューやcomp-sciテストの問題であれば、候補者は結果を暗記するかもしれませんが、新しい問題を自分のやり方で考えることはできません。また、候補者が言語に精通していない場合、彼は苦労する必要があります。優れたプログラマーは自分が何を入力するのかを知っているため、多くのバグは困難であり、彼の脳はコードを読んでいる間、ショートカットを取得します。意図が何であるかを知っているので、Cスタイルの=の==は検査で使用されるはずでしたが見つかりません。私の脳はそれを読んで解析のショートカットを取るでしょう。
エラーを指摘し、その人がどのような反応をするかを確認するために、状況にもう少し追加します。彼らは、「D'oh!私は馬鹿だ、とても馬鹿だ...」タイプについて過度に無関心であり、「ええ、どんな男でも」キャンプで、またはそこに積極的に耳を傾けていましたかある種の謝罪や、彼らが解決すべきはずの何かを台無しにしたことを示す発言が間違っている?将来の状況で考えてみてください。
タイムリーにデバッグすることは素晴らしいスキルです。これは、修正されたときに修正される問題を誰かに与えることとは少し異なります。システムを保存するために積極的な対策が必要な場合があります。ほとんどの企業は、会社が使用している会計ソフトウェアのバグを修正している間、ほとんどの企業が数週間販売を停止することを望まないため、認識されるべきです。
デバッグは重要なスキルです。実際には、トラブルシューティングは非常に重要なスキルであると言います。誰かが問題を定義する方法(どのユーザー情報を求めるか、どのログを調べるかなど)、問題を再現する方法、問題を診断するために利用できるデータソース、デバッグする方法、1つの問題を修正する方法を知っている必要があります他の何かを壊すことなく。ただし、インタビュー中にそれを判断することは困難です。
私は彼に見つけるべき本当の問題と利用可能なツールを使用する機会を与え、彼が問題を見つけるためにどのような手順をとったか、割り当てられた時間内に問題を見つけられなかった場合に彼が他に何をするかもしれないか尋ねます。あなたは本当に組織的に問題を攻撃し、デバッガーとグーグルよりもツールキットに多くのツールを持っている人を本当に探しています(ジュニアレベルでは、両方を最低限試す必要がある場合を除きます)これらの2つのことを試してみると、おそらく有能ではないか、少なくとも私は彼にチャンスを与えません)が、おそらくまだ多くの高度なトラブルシューティングツールはありません)。
トラブルシューティングスキル(パズルはまったく質問しません)やデモプログラミングスキルよりも、トラブルシューティングスキルに重点を置きます。良いコードを書くことも、必要な修正を行うこともできない、うまくトラブルシューティングできる開発者を見たことはほとんどありません。いくつかのコードをまとめて「動作する」製品を得ることができる人がたくさんいますが、彼らの生活がそれに依存している場合は問題を解決できませんでした。ほとんどの場合、彼らはしないので、実際に彼らが何をしているかを理解していないか、解決しようとしている問題を理解していない。優れたトラブルシューティング担当者は、症状だけでなく実際の問題を特定する方法を知っています。彼らは、新しい開発の問題を定義するためにどのような質問をするべきかも知っています。
デバッグは、ソフトウェアで特定のテストが行われ、バグが発見された後に行われるソフトウェア開発の段階です。ソフトウェアのバグを検索して修正する行為です。多くの場合、バグを見つけるには通常、修正に時間がかかります。
これは、コンピューターのアプリケーション/システムに固有のバグ(脆弱性)を削除するプロセスです。これが行われない場合、ハッカーはバグを利用し、さまざまな悪意のある活動を行う可能性があります。
1)脆弱性が一般に公開され、開発者とベンダーの収益、ビジネス、評判が失われる可能性があります。
2)ワームは、悪用可能な脆弱なシステムを検索するため、それらのサーバーに自分自身をコピーします。例えば。2003年1月、Slammer WormはMS SQL Serverの脆弱性を利用しました。
3)ワームが言及されている場合、ウイルスをどのように忘れることができますか。ウイルスはまた、わいせつな露出の主な目的のためにプログラムに存在するバグを利用する開発者によって失われます...
4)そして、プログラムが適切にデバッグされていない場合、消費者はお金の価値を得ることができなければ、決して完全に維持するつもりはありません。その場合、汚い仕事をするのにハッカーさえ必要ありません。あなたは、古き良き公衆を信頼するかもしれません。