上級開発者がOOPの設計パターンを知っていると期待するのは合理的ですか？[閉まっている]

上級開発職の就職面接のための質問を準備しています。仕事にはオブジェクト指向設計が含まれ、既存のソフトウェアは設計パターンを使用するため、候補者に、知っている、使用した、使用した方法、使用した理由を説明するように依頼しますそれらを使用するなど。しかし、以前のインタビューで、デザインパターンについて少なくとも5〜10年の経験を持つ上級開発者に聞いたとき、聞いたことのある人はほとんどいませんでした。20人の開発者のうち2人が単一のデザインパターン（それぞれシングルトンとMVC）を命名できると思います。

だから私の質問は次のとおりです。これらの質問をするのは理にかなっていますか？または、これはあなたが新しい採用者がすでにそれらを知っていると期待できないほど曖昧な主題ですか？

上級開発者がデザインパターンの経験を持っている必要がありますか、またはデザインパターンはトレーニング中にすべてのまともな開発者がそれらを選択できるほど単純なトピックであると言いますか？もしそうなら、代わりに彼らの設計能力を測定するためにどのような質問をしますか？

追加 これまでの回答を読んだ後、いくつかの説明をする必要があります。

• この仕事は、OOP / OODの経験がある.NET開発者向けです。
• 以下のような既存のコードの使用クラス名IParameterGraphVisitorとIStorageFactory多くの場所で
• デザインを説明する語彙がない場合、作成したオブジェクト指向デザインの過去の経験についてどのように人々に尋ねますか？それが私がやりたいことであり、私が思いつくことができるのは「ホワイトボードに最後のプロジェクトのデザイン/オブジェクト階層を描いてください」だけです。

彼らはそれらを知っている可能性があります。彼らは単に「デザインパターン」としてそれらを知らないかもしれません。すなわち、彼らはそのようなことの学術用語に精通していないかもしれません。「ステートマシン」と見なすのは、経験のある年長のプログラマにとっては、単に問題に対する常識的なアプローチかもしれません。たとえば、「デザインパターン」にあまり注意を払ったことはありませんでしたが、ステートマシンとは何かを知ったとき、長年それをやっていたので笑わなければなりませんでした。私がそんなに学者だと知っているのは誰ですか？私は常に「デザインパターン」ではなく、基本的なコーディングスキルだけを考えていました。

重要なのは、経験豊富な開発者が物事の教科書の用語を知っていることではありません。代わりに、クラスをどのように構成するか、またはタスクにどのようにアプローチするかを尋ねます。

あなたの期待は、シニアOO開発者にとって非常に合理的です。Design Patternsを知らなくても、年月が経っても経験が自動的にもたらされるわけではないことを彼/彼女自身と呼んでいる人は誰でも:-(パターン-新しいアイデアを学び、自分自身を改善し、ベストプラクティスを採用することに興味がなかったことを示しています。

上級開発者がデザインパターンの経験を持っている必要がありますか、またはデザインパターンはトレーニング中にすべてのまともな開発者がそれらを選択できるほど単純なトピックであると言いますか？

IMOの経験は非常に重要です。理論的には、まともな開発者であれば、本のデザインパターンやウィキペディアを読んで、15分で基本的な概念を理解できます。ただし、概念を適切に適用するには、苦労して得た経験が必要です。パターンに夢中になるのは簡単です。パターンを可能な限りすべてのコードに詰め込もうとすると、l'art pour l'artになります。また、「パターンは特効薬ではなく、機能する可能性のある最も単純なものを使用してください」と言って簡単に削除できます。パターンを使用して実際の問題を解決するタイミングと方法、およびパターンを使用しない場合を学習することで、両極端の中間点を見つけるには何年もの経験が必要です。

代わりに、設計能力を評価するためにどのような質問をしますか？

上記に合わせて、これらの質問をリストに追加するだけです。

• 設計パターンの欠点は何ですか（一般的に、そして明示的に言及されているものの）。
• それらを使用しない場合、およびその理由は？

更新

@GrandmasterBには、一部の開発者が名前を知らずに特定のデザインパターンを使用している可能性があるという点が優れています。ある意味、彼はこれが用語/コミュニケーションの質問であるという点で正しいです。しかし、コインのもう一方の側面は、それが実際に用語/コミュニケーションの質問であることです:-)つまり、デザインパターンの主な利点の1つは、開発者に共通の語彙を与え、コミュニケーションを大幅に改善することです。（の基本的な考え方を説明してみアダプタを言葉自体、またはその同義語「ラッパー」らを使用せずに！）だから、しかし、才能と知識の豊富なA候補は、かもしれ広く受け入れられている用語（複数可）を知らなくても、彼はコミュニケーションの問題を紹介しますあなたのチームで。

上級開発者？間違いなく。ジュニアがすべきです。私は15歳で、このテーマに関する正式な教育を受けていません。彼らがそれらを知っていると期待することは合理的であるだけでなく、もし彼らが知っていなければ受け入れられません。彼らがオブジェクト指向プログラミングについて何か知っていると仮定すると、彼らはおそらくそうするでしょう。

面接では、候補者が仕事をするために知っておくべき重要なことを尋ねるべきです。

Gang of Fourのパターンの名前を知る必要がある場合、それは有効な要件です。

一方、プログラムアーキテクチャの適切な実用的な知識を表示したい場合は、問題を与えて、どのようにコードを構成するかを尋ねた方が良いと思います。適切なパターンソリューションを提供してくれれば、使用する名前に関係なく、彼らがそれを知っていることを証明できます。

私がシニア職にインタビューするときはいつでも、彼らはQ＆Aよりも「実用的」になる傾向があります。プログラミングのスキルと快適さの明確なデモンストレーションが必要です。また、カプセル化、アルゴリズム、結合/結合などの概念を適用する方法のより一般的なスキルを意味するCS概念の強固な基盤が必要です。複数の言語とパラダイムの経験と知識。

専門分野に依存します。組み込みC開発者が設計パターンについて多くを知っているとは思わないでしょう。Javaまたは.NET開発者について話している場合は、設計パターン、特にそれらに夢中になりすぎないようにする方法に精通している必要があります。

あなたがOOPで年功序列を求めていると仮定すると、答えは間違いなくイエスです。デザインパターンは、OOP言語の辞書です。

さらに、10年の経験を持つまともなOOPプログラマーが標準API、ライブラリ、および開発フレームワークで広く採用されている設計パターンである設計パターンに名前を付けることができないことは、今日では不合理です。

インタビュー中にこの質問をしてきましたが、何年も経ちましたが、候補者がそのトピックについて満足のいく答えを提供できなかったとき、それは圧倒的です。

はい、しかし質問することによって彼らの理解を引き出す必要があります 聞いたことのあるデザインパターンを列挙するように人々に求めるのではなく、デザインの質問を。私は、PoEAA、GoF、およびいくつかの関数型プログラミングパターンで説明されているパターンに非常に満足しています。

「テキストエディターを設計してください」のような質問があり、「画像などの埋め込みオブジェクトをどのようにサポートしますか？太字で斜体ですか？元に戻しますか？」おそらく最終的には、コマンドパターン、複合パターン、記念パターン、および短い会話でも他のいくつかのパターンを認識するのに十分な音が聞こえるでしょう。

設計パターンを発見して説明したので、設計上の意思決定を伝える共通の言語を使用できます。

残念ながら、デザインパターンのすべての使用について説明し、正当化する必要があった人のために働いていました。面白くない。しかし、ほとんどの深刻な開発者は、偶然または設計により、最も一般的に使用されるOOパターンの名前を知っています。

合理的。間違いなく。必要。いや

候補者に設計パターンを知っているかどうかを尋ねます。全体として比較検討するいくつかの基準の1つです。全体像を見落とさないでください。

はい、多くの開発者は知らないうちにいくつかのデザインパターンを使用しています。

それが私が質問する理由ではありません。

他の開発者と迅速かつ効果的にコミュニケーションできることを知っておくことが重要です。ホワイトボードで20分間、ステートマシンの説明をして、「以前使用したが、何を呼ぶべきかわからなかった」ことだけを知りたくありません。これは生産的ではありません。

また、リファクタリングプロセスにも役立ちます。コードをちらっと見ると、偶然に何らかの形のファクトリパターンを実装するかもしれませんが、GoFファクトリパターンは時の試練に耐えてきました。そのため、工場出荷時のパターンであり、まだ別のfpではありません（ホイールの再発明は好ましくありません。ソフトウェアのJoelには、そうすることの欠点がたくさんあります）。

設計パターンの重要性を使用および認識しているチームは、コミュニケーションと生産性を向上させます。チームがユニットとしてdpを使用しない場合、チームは関連性を失います。

私自身の経験から言えば、私はかなり長い間デザインパターンを無視していました。私はそれらが存在することを知っていました、私はそれらについて読んだことがありません。最終的に弾丸を噛んだ後、私はずっとデザインパターンをずっと使っていたのに気づきました、そして、私はそれを理解しなかった、または私のデザインソリューションが実際に共通の名前を持っていることを知りませんでした。

特定のデザインパターンがソリューションにうまく適合し、開発者がそのパターンに似たものを思い付くという一連の問題を思いつきます。もしそうなら、素晴らしい。特定のパターンを解決するのではなく、適切ではないときにパターンにソリューションを適合させようとするデザインパターンの知識を持っている多くの開発者を見ているので、デザインパターンを使用する開発者を知らずに雇いたいと思うかもしれませんよく問題。

パターンの名前とパターンの説明、たとえばGang of FourのFactory Patternなどを考えれば、候補者はパターンがどのようなシナリオになるかを考え出せるはずです。合理的なアプローチ。

5〜10年の経験を持つ開発者と上級開発者がいます。それらはまったく同じものではありません。はい、あなたが上級レベルで採用していて、人々がデザインパターンを知って使用することを期待しているなら、私はそれらに精通していない上級者を採用しません。これは、左結合を理解していないデータベーススペシャリストを雇うようなものです。これは、真のシニア開発者にとって非常に基本的なものです。私はおそらくジュニアを雇うでしょう。

はい、確かに彼らはこの用語に精通している必要があり、いくつかのパターンに名前を付けることさえできるはずです-しかし、理論的知識と経験を混同しないでください。

インタビューの前にデザインパターンをブラッシュアップし、簡単な説明でそれらをガラガラ言うことができる多くの人々がいます-しかし、それは単なる理論です。それを使用するタイミングを見つけることができる、または正式なパターンの知識がなくても古典的なデザインパターンの方法で問題を解決できる本当の上級開発者です。

チェックするための最良の方法は、彼らにあなたの前で何かをデザインさせ、徹底的な質問をすることです。上級開発者は、抽象化レベルで自然に考えることができる人です。これらは、デザインパターンを「作成」する人々です。

ジャグリングを頼むことなくジャグラーを雇うことについて話すピープルウェアのクラスのように-彼らはあまり意味がないと言うからといって..それらを試してみてください。

すでに述べたように、流行語を暗記しなくても大丈夫だと思います。しかし、これは上級職なので、最悪のソリューションを使用する代わりに、問題を最適に解決するためのパターンをいつ適用するかを知っておく必要があります。したがって、パターンを使用して解決する必要のある問題（たとえば、クラスをハードコーディングせずにオブジェクトを作成する方法、実装の詳細がなくてもオブジェクトの要素にアクセスする方法など）を提供し、彼らはそれを攻撃します。

間違いなく彼らはパターンを知っているべきですが、必ずしも流行語ではありません。

たとえば、MVCには、PAC、3層など、多くの非常に類似した選択肢があります。数年前、MVCのもう1つの一般的な流行語は「モデル2」でした。私は実際にそのパターンを完全に知っている非常に優秀な開発者を知っていますが、それに対する現在の流行語がMVCであることを知りませんでした。

非常に簡単に：それらを使用している場合は、候補者に尋ねる必要があります。彼らがパターンを知っている場合、それはいくつかのプラスポイントを追加する必要があります。しかし、特に彼らが良いOODスキルを示している場合、必ずしも彼らを非難すべきではありません。保守プロジェクトに携わっている開発者は、設計パターンに精通している開発者と比較して、設計パターンについて多くを知ることはほとんどありません。また、大学でデザインパターンを教えられているかどうかにも依存します。私の経験では、そうなる可能性は低いです。ほとんどの大学とプライベートコースはOOPを教えますが、OODは教えません。彼らがDPを研究した可能性はさらに低い。

個人的には、プロジェクトで必要になるまでDPを勉強していませんでした。そのときでさえ、私は、本に記載されている正確な方法ではないにしても、少なくとも同様の方法で、いくつかのパターンを使用していたことがわかりました。彼らが成文化されたことを知って驚きました。DPを知らない場合は、優れた設計スキルを探してください。DPを知っている場合は、デザインは優れているが、それでもテストする可能性があります。彼らはDPについてのちょっとした話題を持っているかもしれませんし、インサイダーから発見され、それらを適用せずにいくつかのパターンを研究しただけかもしれません。

あなたがあなたと一緒に仕事に応募する人々が、彼らが業界標準であるかどうかに関係なく、あなたの仕事スロットで必要とされるものを知っている（または学ぶ）ことを期待することは合理的です。そうでなければ、平凡に自分を非難します。ただし、実際に必要でない場合は、ある程度の知識（またはスキル）を仕事の要件にすることに注意してください。

ほぼ同じ背景を持つ2つの候補者がいて、1つはデザインパターンについて話すことができ、もう1つはそうではないとします。それは彼らが仕事でどのように実行しようとしているかについて何を教えてくれますか？

既存のソフトウェアは設計パターンを使用すると言います。それは利点ですか？もしそうなら、どのように？書かれた新しいソフトウェアが既存のパターンに準拠すること、または新しいパターンが導入されることがあなたの目標ですか？どうして？

次の状況で設計パターンを知らない上級開発者を考えることができます。

1. デザインパターンに関する書籍は1冊のみです。そもそも彼らを人気にした本です。人がこの1冊の本を読んでいない場合、デザインパターンについて知らないか、聞いたことがあるかもしれませんが、それらが何のためにあるのかを正しく知らない可能性があります。
2. 代わりに、彼らはUMLのようなものを知っている必要があります...
3. インターネットからデザインパターンに関する適切な情報を見つけるのは簡単ではありません。デザインパターンの知識が豊富な適切なWebページにアクセスできれば幸運です。本が古くなっているため、1995年以降にソフトウェアに単純にアクセスすると、デザインパターンの本を知らない人がいるかもしれません。

オブジェクト指向以外の環境の開発者がオブジェクト指向の設計パターンを知っている必要があるのはなぜですか？Cobolのみ、PL / SQLのみ、Progress 4GLのみなどを行っているショップで働いていました。OO設計の原則はそこには関係ありません。パターン。

パターンカタログから気付かずに引用できることも、あなたを優れた開発者にするわけではありません（実際、私の経験では、これまで見た中で最悪のコードの一部を生成します）。しかし、それは「上級開発者」のマークになると期待するものです。私はこの業界で15年間働いていますが、パターン図を描くように依頼しないでください。あまり時間を与えたことがないので、する必要はありません。特定の名前を付けずに機能するものを見つけるのに十分な経験を積んでおり、正式な定義が必要な場合は、どこを調べるべきかを知っています（そして、はい、私は自分のライブラリにリファレンスブックを持っています）。それは経験豊富な開発者のマークであり、いくつかの教科書を詰め込むことで得られる暗記的な知識ではありません。