抽象化（LINQなど）の使用がなぜタブーなのですか？[閉まっている]

私は独立した請負業者なので、新しいギグのために年に3〜4回インタビューしています。私は今、そのサイクルの真っin中にあり、インタビューがうまくいったように感じたにもかかわらず、機会を求めて断られました。今年も同じことが何度か起こりました。

今、私は完璧な人ではなく、すべての組織に適しているとは思っていません。とはいえ、バッティング平均は通常よりも低いので、最後の面接者に建設的なフィードバックを丁寧に尋ねると、彼は配達しました！

インタビュアーによると、主なことは、低レベルの有機的に成長したアルゴリズムではなく、抽象化（LINQなど）の使用に過度に傾いているように見えたということです。

表面的には、これは理にかなっています-実際、これらのインタビューでもLINQについて口説き、インタビュアーが.NETであってもLINQについてあまり知らなかったため、他の拒否も理にかなっていますみんな）。

だから今、この質問が残っています：「巨人の肩の上に立つ」ことになっていて、私たちが利用できる抽象化（LINQのような）を使用することになっているなら、なぜそれをタブーと考える人がいるのでしょうか？追加のコストなしで同じ目標を達成する場合、「既製」のコードをプルすることは意味がありませんか？

LINQは、それがあってもことを私には思われるで抽象化、単純にすべての抽象化で同じ 1は、まったく同じ目的を達成するために書くでしょうアルゴリズム。カスタムアプローチの方が優れているかどうかを確認できるのはパフォーマンステストだけですが、LINQのようなものが要件を満たしていた場合、そもそも独自のクラスを作成する必要はありません。

ここでLINQに注目するつもりはありません。私は、JAVAの世界には匹敵するものがあると確信しています。なぜ、一部の人々が抽象化を使用するという考えに非常に不快になり、彼ら自身が書いていないのかを知りたいのです。

更新

Euphoricが指摘したように、Javaの世界にはLINQに匹敵するものはありません。 したがって、.NETスタックで開発している場合、常にそれを使用してみてはどうでしょうか。人々がそれが何をするのかを完全に理解していない可能性はありますか？

不利なのは、抽象化自体の使用だとは思いません。他にも2つの説明があります。1つは、抽象化はすべて一度に漏れることです。正しいかどうかに関係なく、基礎となる基礎を理解していないという印象を与えた場合、それはインタビューにあまり反映されない可能性があります。

他の可能な説明は、ファンボイ効果です。LINQについて興奮して話し、それを使用せず、現在使用する予定もない会社とのインタビューで繰り返し取り上げると、古いテクノロジーの使用に不満を感じ、不満を感じることさえあります。また、ある製品に対するあなたの熱意が、他の製品に目をくらませているという印象を与えます。

非LINQショップで満足していると本当に思うなら、彼らが何を使っているのか尋ねてみて、それに応じて答えを調整してください。LINQを好む一方で、手元にあるあらゆるツールを使用する能力があることを示します。

一部の.NETプログラマー、特に古典的なVB / ASPまたはC ++のバックグラウンドから来たプログラマーは、LINQ、MVC、Entity Frameworkなどの新しいものが好きではありません。

私が観察したことを基にすると、このグループの元VB'erは、10年以上前に最初に書かれたデータアクセスレイヤーやその他のコードをまだ使用している可能性があります。また、「n層」などの古い流行語を使用し、.NET Framework 2.0以外のことについては何もまったく理解しておらず、それについて何も学びたくない。

C ++ 'ersは、クールなアルゴリズムのコーディングが大好きな学問志向のプログラマーである傾向があります。彼らは自分でコーディングしなかったものに依存することを嫌います。これらの人々の中には、インタビューを受けた人を劣等感を感じることを喜んでいる人もいます。

インタビューをしているときに、このような組織に出くわす可能性があります。しかし、新しいメソッドを使用している人に出会うこともあります。いくつかの悪いインタビューがあなたを失望させないでください。

マイクロソフトには、ホットな新技術が登場してから5年、10年、または20年後にそれらを忘れてしまった長い歴史があります。LINQは、一部の人々にとっては別のもののように見えるかもしれません。彼らは、Microsoft が SQLを非推奨にすることはできないが、LINQはSilverlightに従っていることに気付くでしょう。ですから、あなたは厳しい経験に起因するパラノイアを見るかもしれませんし、現代のテクノロジーに取り残され、それをresする人々だけを見るかもしれません。

追加のコストなしで同じ目標を達成する場合、「既製」のコードを引き出すことは意味がありませんか？

常に追加料金が発生します。

既製のものの学習曲線は常にそこにあります。更新（および依存関係）を取得する際の苦労は常にあります。内臓にねじ込むことができないことは常にあります。

LINQの場合、最初のもののみが実際に適用されます。多くの人は、「奇妙な」コードを読みにくく、デバッグしにくいと考えています。sqlに似た構文は、登場して以来私が働いてきたすべてのプロのギグであり、ほぼすべての人格に対応しています。LINQ to SQL（およびその他のデータソース）には、いくつかの落とし穴があり、最適化オプションが限られています。

これらは、サードパーティのツールと特にLINQに対する一般的な議論です。とはいえ、LINQは非常に便利なツールであり、ほとんどの状況で優先されるはずです。ここで発明されていない泣き声、そして抽象化は認知的不協和音の強打に強く支持されるべきではありません。

彼らはLINQを知らないか、学ぶことができませんが、「明らかに」優れた開発者なので、LINQは価値がないはずです。これはよくあるtrapです。

他に考慮すべきことは、クールな新技術に対するあなたの熱意は、人々に不快感を与え、周りにいることを望まないということです。あなたは彼らに「力を与えている」のではありません。なぜなら彼らではなく、この技術を知っているのはあなただからです。たとえ彼ら自身がそれを認識していなくても、彼らはすでに多くの時間を費やしてきたものを強化する候補者を探しているかもしれません。

あなたは、「あなたが悪いことをしているかもしれないし、私が周りにいることが証明される」というサブテキストを与えるのではなく、「あなたが何をしていても、私はあなたがそれを達成するのを助けたい」と言う態度を提示したいそれ。"

これについての私の見解（そしてTBHは、それらのインタビュアーが何を考えていたかわからないので、私は推測しています）は、彼らが彼らのチーム、彼らの働き方に合うようにあなたを雇うべき理由を説明するためにしばしばインタビューに行くことです。

あなたは完璧な開発者、ロックスタートコードの神になることができますが、それはあなたがやりたいこと（いくつかのクールなテクノロジーのゴブリンについて過度に熱心に話していることによって強調されている）があなたについて単純に彼らに伝えている場合、絶対に何も意味しません彼らが望むものに適合します。何らかの理由でアップグレードできない古いスタイルのデータアクセスシステムがある場合、その保守方法を忘れてしまった人は必要ありません。彼らが新しいものを開発していて、本当にそのクールな新しい技術をどこにでも本当に置きたいなら、彼らが将来のコードのメンテナンスやスタッフのトレーニングで大きな問題を抱えていることは明らかです。

フリーランサーとして、これは彼らがパーミーを雇っていた場合、はるかに問題です。パーマでは、既存のコードとプラクティスの範囲内で、新しい作業方法のトレーニングと開発は悪いことではありません-あなたは物事を改善するために長い間そこにいるでしょう。フリーランサーでは、彼らは本当にあなたが望むものを与えることはありません。あなたは彼らがやりたいように彼らの仕事をするためだけにあり、あなたの仕事は他のことをするのではありません。（同意しない-正社員になる）

おそらくLINQ自体とは何の関係もありません。私は出てきた候補者を拒否し、Haskellですべてがより良く書けることを説明しました。Haskellはしません。同じことは、会社で使用されていない技術にも当てはまります。通常、何か良いものと言っても問題にはなりません。問題は、あなたがあまりにも熱心で熱心なときに起こります。

Linqを使用していない人から聞いた正当な懸念が1つあります。それは、「実装が見えないからといって、高価ではないということではありません」ということです。

次のスニペットを取得します。

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

ここで開始されたLINQはたじたじです。どうして？というのは、このコードが見栄えが良くエレガントだからといって、ひどく非効率的というわけではないからです。Count（）は、述語とともに、その親列挙型のすべての要素を評価し、述語がtrueを返した時間を合計します。したがって、このN ^ 2（inputListとotherInputListのカーディナリティNがほぼ等しい場合）だけでなく、それは絶対的な最悪の場合のN ^ 2です。otherInputListのすべての要素は、入力のすべての要素に対してトラバースされます。代わりに、最初のステップはCountの代わりにAny（）を使用することです。これは本当に知りたいことであり、答えが「はい」であることが判明するとすぐに終了するためです。の個別の値を保存するHashSetを設定するotherInputListObject.OtherPropertyことも役立ちます。アクセスはO（N）ではなくO（1）になり、二次の最高の複雑さではなく、最悪の場合の複雑さ。

したがって、これらの素敵なエレガントなメソッドには背後に深刻なコストがあり、それらのコストがわからない場合は、O（my GD）複雑性アルゴリズムを将来の雇用主の高性能中央ファイルサービサーに非常に簡単にコーディングできますまたは、次回微調整が必​​要になる場合のメインのランディングポータルページ。あなたがそれをした後にあなたを発射すると、あなたがしたことを元に戻しませんが、あなたがそれをするだろうと彼らがそれを妨げると思うならばあなたを雇わないでください。したがって、これを回避するには、それらが間違っていることを証明する必要があります。これらの方法が何を行うか（自分自身を知る必要があることを意味します）とその複雑さ、および効率的な（NlogN以上の）時間で答えに到達する方法について話し合います。

もう1つの懸念は、古き良き「あなたの唯一の道具がハンマーであるとき」という議論です。このLinqのファンボーイにインタビューするインタビュアーの場所に身を置いてください。候補者はLinqが好きで、それを使いたいと思っており、これが最高のものだと考えています。与えられたプログラミングの問題はすべてLinqで解決されたため、候補者はそれなしではコーディングできなかったように思えるかもしれません。それが使用できない場合はどうなりますか？まだたくさんの.NET 2.0コードがあります。アップグレードされた場合、サーバー、ユーザーワークステーションなどの面倒なアップグレードが必要になるため、すべての拡張機能を使用できます。インタビュアーとして、私はあなたが効率的なソートをコーディングできるか、必要であれば2.0のソート方法を使用できることを示してもらいたいと思います。甘い。重要な点がわからないインタビュアーは、他のことに対する適性をあなたに見せようとはしません。彼らはあなたがそれを持っていないと仮定して先に進みます。

これは少し長くなりましたが、誰かに役立つかもしれないので、私はそれをさせます。

実際に、先月20件強のインタビュー（電話と対面の組み合わせ）を経験して、似たようなことに遭遇しました。指を置くことができなかったことが予想外に起こっていました。

しかし、私が気づいたことの1つは、過去5年または6年のインタビューサイクルの中心であったことは、明らかに議論されておらず、短期間ではないことです。OOP分析/設計の基礎、パターン（設計とアーキテクチャの両方）、より高度な/抽象化指向の.net機能（ラムダまたはLINQを含む、ジェネリック、シリアル化/データバインディングなど）、さらには通常、好まれる方法論（アジャイルとウォーターフォール、またはアジャイルのフレーバーについて誰も気にしないようだ）とツールまたはORMの選択、またはコラボレーションまたはソース管理管理の好ましい手段の話題。まったく言及されていない場合もありますが、ほとんどすべての場合、明らかに問題ではありません。

複数のインタビューや、無関係な業界のさまざまな無関係な企業で注目されたのは、次のようなものでした。

• 時代遅れ/時代遅れの慣習と「石器時代に戻る」制限に対する奇妙な固定。VS2003での原始的なWebアプリの開発と同様に、.netの時代の範囲内での明示的な機能の使用をさらに禁止する不条理な制限のリストを...まるでそれが現代の開発者の能力の本当の尺度であるかのように...思い出す能力9年前のパラダイムと制限は、非現実的/任意の制約によってさらに不自由になりました。別の場所は、一般的なコレクションの周りで、カスタムコレクションのテーマに非常に苦心していました。別の場所では、カスケードコンストラクターを使用しなかったため、スクロールアウトしたクラスモデルのコードサンプルを使用していました（これらは、宣言のプロパティ初期化のサポートを認識していないようで、必要に応じて十分でした）。

• プラットフォームやプロトコルにとらわれないことに焦点を当てた技術の場合でも、小宇宙および/または構成設定の特定の実装の詳細に極端に焦点を当てています再利用/再目的/拡張性/必要に応じて統合）。

• オフショアチームとやり取りする作業を特定/監督/コードレビュー/その他の方法で行う意欲、およびそれに関連する非コーディングスキル。

• 製品/プラットフォーム/モジュール/などの特定のバージョンの使用。時には不合理な程度まで。「だから...バージョン1、2、4を使ったのですか？しかし、3ではありませんか？うーん... {履歴書に「no v3 !!!}で注釈を付けてください」」。あなたが何かを使用しているか、まったく使用していないこと、および彼らが求めている特定のことだけです...より広く使用され、完全に機能する競合製品であっても、代替品は数えないようでした。

• 「ソフトウェア開発者として実際に良いことはありますか」や「会社に価値を付加し、品質を提供するためのスキルと経験はありますか」よりも「チームにどれだけうまくフィットするか」に焦点を当てます製品」または「あなたが来て、店を破壊する危険なばかです」。いくつかのケースでは、私の履歴書はただ与えられたものであり、いわゆる「技術スクリーニング」や技術面接でさえ、スキル評価よりもはるかに個性の評価でした。あなたがそこにいて、2シーズンが変わる前に再び行く比較的短期の契約ポジションでも。

• 今回の企業は、特定の技術的問題の解決、新しいグリーンフィールドや大きな2.0開発プロジェクトの開始、または特定の製品を市場に投入して新たなトレンドや機会、または通常の大きなキックオフを活用することにあまり焦点を当てていないように見えました。少なくとも15か所で気付いた繰り返しのテーマは、3〜5人の開発者の小さなグループ（ほとんどが08年の市場崩壊の生存者）が、過去3年ほどで製品を粉砕することができたということです。いくつかの成功を発見したか、会社全体が活況を呈しており、増加する機能需要に対応したり、これらのシステムに組み込まれた設計上の欠陥に対処/克服したり、前述のプラットフォームを引き継いで解放するために、新しい人々を雇っています「他のプロジェクト」を行うためにそれを構築したコアチームを構築します。

しかし...このビジネスについて私が知っていることが1つあるとすれば、それは循環的であるということです。次に新しいギグを探しているとき、ゲームが再び変わっても驚かないでしょう。あなたは精神的な柔軟性を維持し、積極的なリスニングを行い、不要な場合は絶対的な発言を避けますが、イタチでもないようにし、一次元であるようになってはいけません狂信者、どちらも望ましくない）またはあまりにも良い（脅迫的でギグがかかる）。

アプローチを調整して、次回より測定された応答を提供するようにしてください...問題にアプローチする可能性のあるいくつかの異なる方法に言及してください...その場で推論します。それはより謙虚で、そのように威圧的または不快感が少ないようです。

もちろん、マーフィーの法則はそのままです。「私の現在のお気に入りのテクノロジーガイに情熱を注ぐ」ことをやめ、よりバランスのとれた/ひげをなでるスタンスを採用した後の次のインタビューは、あなたが狂ったなら得たはずのギグです熱狂的な男。;）

サンプルのセットが制限されすぎているため、間違った結論を出していると思います。私は何に強い嫌悪感を持つITショップの公正なシェアを見てきましたが、「そこに発明されていない」^1は、それらのどれもが、技術スタックで自分の好みに基づいて候補者を失格ないだろう。彼らは当然、彼らが使用する権利候補者を教えることができると確信しました自社開発のライブラリ。

会社がLINQの使用を全面的に禁止したことを真剣に疑っています。おそらく、彼らはあなたに彼らにあなたのスキルをより深いレベルで示すことを望んでいました。

たとえば、ハッシュテーブルを知っているかどうかを判断する1つの方法は、ホワイトボードにプリミティブなテーブルを実装するように依頼することです。この簡単な演習により、あなたの知識に関する驚くべき量のデータがレビュアーに明らかになります。彼は、ハッシュコード/イコールについて知っているかどうか、およびハッシュ衝突について知っていることを即座に学習します。同時に、Microsoftが非常に良い仕事をしてくれたので、彼らの正しい考えの誰かがハッシュテーブルを再実装することを想像することは困難です。並べ替えや検索など、多くのアルゴリズムについても同様です。インタビュアーは、.NETライブラリの実用的な知識があるかどうかを確認するのではなく、背景が低レベルの相互作用を理解するのに十分かどうかを知りたいことがよくあります。

あなたが彼らの会社で働くために雇われたら、彼らはあなた自身ではなくライブラリ実装を使うことをあなたに主張することはほぼ確実です。しかし、インタビュー中に彼らはあなたの本当の能力をより良く理解するために低レベルのコードにあなたを押しやるでしょう。

「スコットランドで黒牛を見たので、スコットランドの牛はすべて黒です」というタイプの狂気の一般化を行っていると思います。

私があなたにインタビューした場合、あなたが私のlinqの質問に答えられなかったら失望するでしょう。

しかし、Linqは扱いにくいものです。多くの人は、それが実際には非常にシンプルであり、より賢いので不公平なブードゥー教だと考えています。

悪魔の擁護者を演じる理由は、多くの開発者は新しいことを気にせず、すべてが自家製の（通常は劣った）ツールで解決しなければならないと考えるからです。抽象化を使用しても問題はありません。地獄、通常、これらの抽象化を使用しない正当な理由はありません。

物事を最新に保つことができず、すべてにハンマーとネイルのアプローチをとる貧しい開発者にインタビューしたばかりのように聞こえます。これらは、NUnit、NHibernate、またはさまざまなIoCコンテナーなどの有用なオープンソースツールについて何も知らない開発者です。データベース内の大規模なストアドプロシージャですべての問題を解決しようとする人。MVCが数年前にリリースされたにもかかわらず、MVCについてまったく何も知らないもの。