なぜ抽象化（LINQなど）の使用がタブーなのですか？
私は独立した請負業者なので、新しいギグについて年に3〜4回インタビューを行っています。私は今そのサイクルの真っ只中にいて、インタビューがうまくいったように感じたのに機会のために断られました。今年も同じことが何度か起こった。
今、私は完璧な人間ではありませんし、すべての組織に適しているとは思っていません。とはいえ、私の打率は通常よりも低いので、最後の面接担当者に建設的なフィードバックを丁寧にお願いしました。
インタビュアーによると、主なことは、私は、低レベルの有機的に成長したアルゴリズムではなく、抽象化（LINQなど）の使用に過度に傾いているように見えたということです。
表面的には、これは理にかなっています。実際、他の拒否も理にかなっています。なぜなら、私はそれらのインタビューでもLINQについて話しかけたので、インタビュアーが。みんな）。
だから今私はこの質問を残されています：「巨人の肩の上に立っている」と私たちが利用できる抽象化を使用することになっている場合（ LINQのように）では、なぜ一部の人々はそれをそれほどタブーだと考えるのですか？追加コストなしで同じ目標を達成するのであれば、コードを「既製」にプルするのは理にかなっていますか？
LINQは、が抽象化であっても、すべてのsameアルゴリズムの抽象化であるように思えますまったく同じ目的を達成するために書いてください。カスタムアプローチの方が優れているかどうかを確認できるのはパフォーマンステストだけですが、LINQのようなものが要件を満たしている場合、そもそもなぜ独自のクラスを作成する必要があるのでしょうか。
ここではLINQに焦点を当てるつもりはありません。 Java=世界に匹敵するものがあると確信しています。なぜ、一部の人々が、彼ら自身が書いていない抽象化を使用するという考えに不快に思うのか知りたいだけです。
更新
Euphoricが指摘したように、 Java world. のLINQに匹敵するものはありません。したがって、.NETスタックで開発している場合、なぜそれを常に利用しようとしないのですか？人々がそれが何をしているのか完全に理解していない可能性がありますか？
不快なのはそれ自体が抽象化の使用だとは思わない。他に2つの説明が考えられます。 1つは、抽象化がすべて一度に leaky であることです。正しいかどうかにかかわらず、根本的な基礎を理解していないという印象を与えると、インタビューに反映されなくなる可能性があります。
他の可能な説明はファンボーイ効果です。 LINQについてわくわくして話し、それを使用しておらず、現在使用する予定もない企業へのインタビューで繰り返し取り上げると、古いテクノロジーでの作業に不満を感じたり、不満を抱くようにさえ感じられます。また、1つの製品に対する熱意が、他の選択肢を知らない印象を与える可能性もあります。
本当にLINQ以外のショップで満足していると思う場合は、彼らがdoをどのように使用するかについて質問し、それに応じて回答を調整してください。 LINQを好みながら、手元にあるどのようなツールも使用できることを説明します。
一部の.NETプログラマー、特にクラシックVB/ASPまたはC++のバックグラウンドの出身のプログラマーは、LINQ、MVC、Entity Frameworkなどの新しいものを好まない。
私が観察したことに基づいて、このグループの元VBは、10年以上前に最初に記述されたデータアクセスレイヤーやその他のコードをまだ使用している可能性があります。彼らはまた、「n層」などの古い流行語を使用し、.NET Framework 2.0を超えることについてはまったく何も理解しておらず、何も学びたくありません。
C++の読者は、たとえそれが車輪を再発明することを意味するとしても、クールなアルゴリズムのコーディングを愛する学問指向のプログラマーである傾向があります。彼らは自分でコードを記述しなかったものに依存します。これらの人々の何人かは、特に伝統的な背景があまりない人々をインタビュー対象者に劣っているようにさせることを喜んでいます。
インタビューをしているときに、このような組織に出くわす可能性があります。しかし、より新しい方法を使用している人にも遭遇します。いくつかの悪い面接があなたを失望させてはいけません。
マイクロソフトには、新しいテクノロジーが登場してから5、10、または20年後にそのテクノロジーを忘れるという長い歴史があります。 [〜＃〜] linq [〜＃〜] は、一部の人にとっては別のように見えるかもしれません。彼らは、MicrosoftはSQLを非推奨にできないが、LINQは Silverlight に従う可能性があることに注意します。だから、辛い経験から生じるパラノイア、あるいは現代のテクノロジーに取り残されて憤慨している人々だけを見ているかもしれません。
追加コストなしで同じ目標を達成するのであれば、コードを「既製」にプルするのは理にかなっていますか？
常に追加料金がかかります。
既製のものの学習曲線は常にそこにあります。更新（および依存関係）を取得する苦労は常にあります。根性でねじ込むことができないことは常にそこにあります。
LINQの場合、最初のものだけが実際に適用されます。多くの人は、「奇妙な」コードを読みにくく、デバッグしにくいと考えています。 sqlに似た構文は、登場して以来、私が取り組んできたすべてのプロのギグであり、ペルソナではなくグラッタです。 LINQ to SQL（およびその他のデータソース）には、多くの問題と制限された最適化オプションがあります。
これらは、サードパーティツールおよびLINQに対する一般的な議論です。そうは言っても、LINQは非常に便利なツールであり、ほとんどの状況で推奨されるはずです。ここで発明されていないCryingと、抽象化は Cognative Dissonance を強く推奨すべきではありません。
彼らはLINQを知らない/学ぶことはできませんが、「明らかに」優れた開発者であるため、LINQに価値はありません。それはよくあるわなです。
あなたが考慮すべき他の何かは、クールな新技術へのあなたの熱意が単に人々を不快に感じさせ、あなたの周りに欲しくないということです。あなたは彼らに「力を与える」のではなく、なぜなら彼らではなく、あなたがこのテクノロジーを知っているからです。彼ら自身がそれを理解していなくても、彼らはすでに多くの時間を費やしてきたものを強化する候補者を探しているかもしれません。
「あなたは悪いことをしているかもしれないし、周りにいることで証明されるだろうそれ。"
これについての私の見解（そしてTBH私は誰もそれらのインタビュアーが何を考えていたのかを知ることができないので私は推測している）はしばしば彼らがあなたを雇うべき理由を説明するためにインタビューに行くということです彼らのチームに合うように、彼らの働き方。
あなたは完璧な開発者、ロックスタートコードの神になることができますが、それはあなたがやりたいこと（あなたがいくつかのクールなテクノロジーのガビンについて過度に熱狂的に話していることで強調されています）があなたについて単にあなたに話し、あなたがそうしないことを言っても絶対に何も意味しません彼らが望むものに収まる。古いスタイルのデータアクセスシステムを使用していて、何らかの理由でアップグレードできない場合は、メンテナンス方法を忘れた人は必要ありません。彼らが新しいものを開発していて、本当にクールな新しい技術をどこにでも置きたいと思っているのなら、彼らは将来のコードのメンテナンスやスタッフのトレーニングで大きな問題を抱えることは明らかです。
フリーランサーとして、これは彼らがパーマを雇っていた場合よりもはるかに問題です。パーマを使用すると、既存のコードとプラクティスの範囲内で、新しい作業方法のトレーニングと開発は悪いことではありません。物事を改善するために長い間そこにいるでしょう。フリーランサーを使用すると、彼らは本当にあなたが望むものを提供しません、あなたは彼らがやりたいように彼らの仕事をするためだけにあり、他のことをするのはあなたの仕事ではありません。 （同意しない-正社員になる）
それはおそらくLINQ自体とは何の関係もないので、私は出てきて、Haskellですべてを書く方がどれほど優れているかを説明した候補者を拒否しました。ハスケルはしません。同じことは、会社が使用していない技術にも当てはまります。通常、何か良いものと言っても問題はありません。問題はあなたが熱狂的すぎてそれに熱心であるときに来ます。
これは少し長くなりましたが、誰かに役立つかもしれないので、私はそれを許します。
私は実際に先月、20を少し超えるインタビュー（電話と対面の組み合わせ）を経験し、同様の何かに遭遇しました。思いがけないことが起こっていて、指を完全にはつけられなかった。
しかし、私が気づいたことの1つは、通常、過去5年間または6年間のインタビューサイクルの中心点であったものは明らかに議論されていないか、または短気を与えられなかったことです。 OOP分析/設計、パターン（設計とアーキテクチャの両方））の基礎、より高度な/抽象化指向の.net機能（ラムダまたはLINQ、具体的にはジェネリック、シリアライゼーション/データなど）のようなものバインドなど）、そして好まれる方法論のホットなトピック（誰もがアジャイルかウォーターフォールか、アジャイルのフレーバーを気にしているようには見えなかった）やツール、ORMの選択、またはコラボレーションまたはソース管理管理の優先手段です。まったく言及されていないケース、ほとんどすべてのケースで明らかに懸念されていないケース。
複数のインタビューと無関係な業界のさまざまな無関係な企業で焦点を当てたものは、次のとおりです。
時代遅れ/時代遅れの慣習と「石器時代に戻る」制限に関する奇妙な修正。不合理な制限のリストを使用してVS2003でプリミティブなWebアプリを開発するように、.netの時代の中で明示的な機能の範囲の使用をさらに禁止します...まるでそれが現代の開発者の能力の実際のゲージであるかのように...覚える能力9年前のパラダイムと限界は、非現実的/恣意的な制約によってさらに損なわれました。別の場所では、カスタムコレクション、つまり前ジェネリックコレクションが非常に熱心でした。別の場所で、カスケードコンストラクタを使用しなかったために書き出されたクラスモデルのコードサンプルを追加しました（必要に応じて十分な宣言でのプロパティ初期化のサポートを認識していなかったようです）。別の場所はデリゲートに大きく、頻繁に宣言するために使用した私の応答が気に入らなかったが、Action <>とFunc <>のおかげで、もう宣言する必要はほとんどありませんでした。
プラットフォームまたはプロトコルにとらわれないことに焦点を当てたテクノロジーの場合でも、microcosmおよび/または構成設定における特定の実装の詳細に極端に焦点を当てます（つまり、全体のポイントは特定の実装または特定の使用法に固執するのではなく、むしろ再利用/転用/拡張性/必要に応じて統合）。
オフショアチームとの間での作業のスペック/監督/コードレビュー/その他のスプールの意欲、およびそうすることに関連する非コーディングスキル。
製品/プラットフォーム/モジュール/などの特定のバージョンの使用法。 「それで...バージョン1、2、4を使用したことがありますか？3は使用していませんか？ええと... {履歴書に「no v3 !!!」と注釈を付けます。あなたが何かを使ったことがある、または使っていないことだけ、そして彼らが求めている特定のこと...置換さえ数えられないようですより広く使用され、フル機能の競合製品の。
「実際にソフトウェア開発者として優れているか」または「企業に付加価値を付け、品質を提供するのに役立つスキルと経験がありますか」よりも「チームにどれだけうまく対応できるか」に重点を置いています。製品」、または「あなたは危険な馬鹿で、店に入り込んで店を壊します」。いくつかのケースでは、私の履歴書は単に与えられたものと見なされ、いわゆる「技術スクリーニング」または技術面接でさえ、スキル評価よりもはるかに個性評価でした。あなたがそこにいて、2シーズンが変わる前に再び行った比較的短期の契約ポジションについてもです。
今回の企業は、特定の技術的な問題の解決、新しいグリーンフィールドまたは大きな2.0開発プロジェクトの開始、または特定の製品を市場に投入して、新しいトレンドや機会、または通常の大きなキックオフを活用することにあまり重点を置いていなかったようです。 。少なくとも15か所で気付いた繰り返しのテーマは、3〜5人の開発者の小さなグループ（ほとんどが08年の市場崩壊の生存者）が過去3年間で製品を粉砕できたということです。そして、いくつかの成功または会社全体が活況を呈していることを発見し、機能の需要の増加に対応するため、またはこれらのシステムに組み込まれた設計の欠陥に対処/克服するため、または前述のプラットフォームを引き継ぐために新しい人々を採用しています「他のプロジェクト」を行うためにそれを構築したコアチームを立ち上げます。詳細は異なり、例外もありましたが、それが今回の土地の一般的なレイアウトでした。
しかし...このビジネスについて私が知っていることが1つあるとすれば、それは循環的であるということです。次に新しいギグを探しているときに、ゲームが再び変わっても驚かないでしょう。あなたはただ精神的に柔軟性を保ち、積極的に傾聴し、不必要な場合でも絶対的な発言をしないようにし、イタチにもならず、1次元的ではない（ばかまたは熱狂的、どちらでもない）またはtoo良い（それは脅迫される可能性があり、ギグにかかる可能性があります）。
アプローチを調整し、次回はより詳細な応答を与えるようにしてください...問題にアプローチする可能性のあるいくつかの異なる方法を挙げてください...しかし、それがあなたのための熟練した知識であるとしても、実際にそれについて考えているかのように行動し、その場でそれを推論します。そのほうが、謙虚で、威圧的でも怒りっぽくないようです。
もちろん、マーフィーの法則はそれであり、あなたが「私の好きなテクノロジーの男に情熱を注ぐ」のをやめ、よりバランスのとれた/ひげを伸ばすスタンスを採用した後の次のインタビューは、あなたのギグですあなたは狂った熱狂的な男だったとしたら得たでしょう;）
Linqを使用していない人から聞いた有効な懸念が1つあります。それは、私が心に留めていることです。「実装が見えないからといって、それが高価ではないということではありません」。
次のスニペットを取ります：
var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);
ここで開始されたLINQはうんざりしています。どうして？このコードが見栄えがよくエレガントなからといって、それが恐ろしく非効率的ではないという意味ではありません。 Count（）は述語を使用して、親の列挙可能要素のすべての要素を評価し、述語がtrueを返した時間を合計します。したがって、このN ^ 2（inputListとotherInputListのカーディナリティがほぼ等しい場合）だけでなく、絶対最悪の場合のN ^ 2になります。 otherInputListのすべての要素は、入力のすべての要素に対してトラバースされます。代わりに、最初のステップはCountの代わりにAny（）を使用することです。これは実際に知りたいことであり、答えが「yes」であることが判明するとすぐに終了します。 otherInputListObject.OtherPropertyの個別の値を格納するHashSetを設定すると、役立つ場合もあります。アクセスはO(1)になるため、初期線形セットアップコストでは、操作全体を線形に削減最悪の場合二次式ではなく複雑さベストケース複雑さ。
したがって、これらの素敵なエレガントなメソッドの背後には深刻なコストがあり、それらのコストがわからない場合は、非常に簡単に[〜＃〜] o [〜＃〜]をコーディングできます。 （私のGD）複雑なアルゴリズムを雇用主の高性能中央ファイルサービサーまたはメインのランディングポータルページに組み込み、次にTweakが必要になる可能性があります。それを行った後にあなたを解雇しても、あなたがしたことは取り消されませんが、あなたがそうするだろうと彼らが考えたとしても、あなたを雇うことはそれを妨げるでしょう。したがって、これを回避するには、それらが間違っていることを証明する必要があります。これらのメソッドの機能（自分自身を知る必要があることを意味します）とその複雑さ、および効率的な（NlogN以上の）時間で答えに到達する方法について話し合います。
別の懸念は、古き良き「あなたの唯一の道具がハンマーであるとき」という議論です。このLinqファンボーイにインタビューするインタビュアーの代わりに自分を置きます。候補者はLinqが好きで、それを使いたいと思っています。与えられたすべてのプログラミング問題はLinqで解決されたため、候補者はそれなしではコーディングできなかったように見えるかもしれません。それが使用できない場合はどうなるでしょうか？まだ多くの.NET 2.0コードが存在します。アップグレードした場合、サーバー、ユーザーワークステーションなどへの痛みを伴うアップグレードが必要になるため、ファンシーな拡張メソッドを使用できます。インタビュアーとして、効率的な並べ替えをコーディングしたり、必要に応じて2.0の並べ替え方法を使用したりできることを説明します。Linqライブラリや類似の拡張メソッドがかなり優れていると私がどの程度同意してもかまいません。甘い。要点を理解していない面接担当者は、他のことについての適性を示すように仕向けようとすることさえしないかもしれません。彼らはあなたがそれを持っていないと仮定し、次に進みます。
サンプルのセットが非常に限られているため、あなたは誤った結論を引き出していると思います。 「そこに発明されていない」ものへの強い嫌悪感を持つITショップのかなりのシェアを見てきましたが1、テクノロジースタックの好みに基づいて候補者を失格にすることはありませんでした。彼らは、自社開発のライブラリを使用することを適切な候補者に教えることができると確信していました。
同社がLINQの使用を全面的に禁止したことを真剣に疑っています。おそらく、彼らはあなたに彼らにあなたのスキルをより深いレベルで見せてほしかった。
たとえば、ハッシュテーブルを知っているかどうかを判断する1つの方法は、ホワイトボードにプリミティブテーブルを実装するように依頼することです。この簡単な演習は、あなたの知識に関する驚くべき量のデータをレビュー担当者に明らかにします。彼は、ハッシュコード/等しいについて知っているかどうか、およびハッシュの衝突について知っていることを即座に学習します。同時に、Microsoftがハッシュテーブルを非常に上手にしたので、ハッシュテーブルを再実装する人がいることを想像するのは困難です。同じことが、並べ替えや検索などの多くのアルゴリズムにも当てはまります。インタビュアーは、.NETライブラリの実用的な知識を持っていることを確認するのではなく、バックグラウンドで低レベルのやり取りを理解するのに十分かどうかを知りたいことがよくあります。
あなたが彼らの会社で働くために雇われたら、彼らがあなたのライブラリ実装を使うのではなく、あなたにinsistをすることはほぼ確実です。しかし、インタビューの間、彼らはあなたを低レベルのコードに向けて押し、あなたの本当の能力をよりよく理解するでしょう。
1
「スコットランドで黒い牛を見たので、すべてのスコットランドの牛は黒い」タイプの狂った一般化をしていると思います。
私があなたにインタビューしたならば、あなたが私のlinq質問に答えることができなかったら失望するでしょう。
Linqはトリッキーなものですが、多くの人々はそれをブードゥーと見なします。これは実際には非常にシンプルで、より賢いので不公平です。
悪魔の擁護者を演じる理由は、多くの開発者が新しいことに関心を持たず、すべてを自社開発の（通常は劣った）ツールで解決する必要があると考えているためです。抽象化の使用には何の問題もありません。地獄、通常、これらの抽象化を使用する正当な理由notはありません。
物事について最新の情報が得られず、すべてにハンマーとネイルのアプローチをとる貧しい開発者にインタビューしたばかりのようです。これらは、NUnitやNHibernateなどの便利なオープンソースツール、またはさまざまなIoCコンテナーについて何も知らない開発者のタイプです。データベース内の大規模なストアドプロシージャですべての問題を解決しようとする人。数年前にリリースされたにもかかわらず、MVCについてまったく何も知らない人たち。