チームがすべてを社内で書くことはどのくらい一般的ですか？[閉まっている]

最近のインタビューで、私はインタビュアーに「新しいテクノロジーやライブラリ（SignalRなど）を評価し、それらを使用するためにどのように取り組みますか？」と尋ねました。彼らはそうではなく、代わりに自分ですべてを書くので、他の誰かに頼る必要がないと言った。

同社は政府や防衛請負業者、または安全重視のプロジェクトなどに従事していません。彼らはあなたの平均的な中規模のソフトウェア開発会社でした。

私の質問は、チームがすべてを自分で書くのはどれくらい一般的ですか？そうするチームに心配する必要がありますか？

編集-ほとんどすべての回答が、これは懸念事項であると述べています。二度目のインタビューは、家の中にすべてを書く際に自分の立場を明確にする/繰り返すように頼むのに適切な時間でしょうか？

サードパーティのライブラリを使用しないという態度はばかげています。コードベースのすべての行が会社の従業員によって書かれたという厳しいビジネス要件がない限り、すべてを自分で書くことはあなたの会社の時間の恐ろしい使用です-しかし、それは特に民間企業のような珍しいシナリオですあなたが説明しました。

より合理的で徹底的な答えは、次のようなサードパーティのライブラリのみを使用することでした。

• それ以外の場合は自分で書くコードのニーズを満たす
• 会社のビジネスモデルと互換性のあるライセンスの下で利用可能だった
• 含まれるテスト
• コードレビューを通過しました

これらの基準が満たされた場合（そして、私の経験では、特に良いテストが存在する場合、コードレビューは非常に柔軟です）、あなたはもはや「他の誰かに依存している」ことはありません-既存の、利用可能な、そしてできれば堅牢に頼っていますコード。

コードがオープンソースの場合、最悪の場合、サードパーティのライブラリはメンテナンスされなくなります。しかし、誰が気にしますか？テストは、ライブラリがニーズに適していることを証明します！

さらに、確立されたサードパーティライブラリへの嫌悪感は、プログラマの生産性を大幅に妨げます。同社がWebアプリケーションを書いていて、（たとえば）jQueryの使用を拒否したため、代わりにDOM操作を簡素化する独自の代替クロスブラウザライブラリを作成したとします。ほぼ確実に、それらの実装は次のように仮定できます。

• jQueryに既に馴染みのある開発者にとっては異質なAPI
• jQueryほど文書化されていません
• ライブラリの使用中に問題が発生した場合、関連するGoogleの結果はありません
• jQueryほどフィールドテストされません

これらの点はすべて、プログラマの生産性にとって大きな障壁です。そのような生産性をあきらめるためにビジネスはどのように余裕がありますか

質問を更新し、これが2回目のインタビューで取り上げるのに適切かどうかを尋ねました。絶対です。

最初のインタビューでインタビュアーの回答を誤って解釈したか、インタビュアーが会社の立場を誤って説明しただけで、新しいインタビュアーがそれを明確にできる可能性があります。

外部ライブラリに対する姿勢について懸念していると説明した場合、少なくとも2つの結果が考えられます。

• 彼らは変化する可能性があり、彼らのプロセスに関する懸念は、他の候補者よりもあなたを良く見せます。
• 彼らは変化に対して開かれておらず、あなたを「私たちが雇いたくないような開発者」と考えています。関係ない、それはあなたがとにかく働きたい場所の種類ではありません。

それは信じられないほど非競争的だ。私は、Hibernateのような標準のオープンソースライブラリをスキップし、いくつかの「重要な」機能が欠けているため、独自のライブラリを展開することを決めたショップで働いてきました。最終的に、ソフトウェアの構築と保守には非常に費用がかかりました。もちろん、社内図書館の費用は著しく過小評価されていました。社内ライブラリが作成されている間、標準ライブラリは急速に進歩し、社内ライブラリでは利用できなかった新しい機能を追加しました。最終的に、標準ライブラリを使用して1時間かかる作業は、2日かかりました。そして、世界が彼らを追い越したので、それは開発者のキャリアにとって悪いことでした。そのような店は避けたいです。私は配信するのが好きで、再利用できるときに書き換える忍耐を持っていません。

この店にはNot Invented Hereという病気があります。面接をその場で終了し、すぐに去ることは正当な理由です。これは、発生する可能性が非常に低いトップダウンのハウスクリーニングによってのみ解決できます。

あなたの質問に答えるために、それはあなたが思っているよりもはるかに一般的であり、それは間違いなく心配する理由です。

はい、間違いなく心配です！それは慢と（ごめんなさい）愚かさの悪臭を放ちます。脳の半分を持っているプログラマーは、自分で書くのではなく、signalRのようなライブラリーを使用します。すでに解決済みの問題を解決するために時間を無駄にすることは絶対に意味がありません。私はおそらくより多くの情報を最初に見つけようとします-彼らはあなたを誤解しているかもしれません（インタビューが終わったとしても難しいかもしれません！）

私は、両方とも（簡単に）ここでシンドロームを発明していないソフトウェアハウスで働いている友人を何人か持っています。だからメンタリティはそこにあります。

両者が行った観察は、開発チームでアプローチが促進した文化に関するものでした。彼らは両方とも、ソフトウェア開発の見通しの点で非常に孤立した人々、および新しいことを学び、品質を追求することに本当に駆り立てられていない人々と協力することになりました。キャリアのどの段階にいても、仲間から新しいことを学ぶチャンスがある場所で働きたいと常に思っています。ただし、この種の環境は、すべてを自分でロールバックしたい場所では一般的に見られないようです。

私が住んでいる場所は一般的ではなく、同僚を通じて多くの企業を知っています。私はすぐに「感謝しない」と言っています。

すでに得られた良い点を逆説するつもりはありませんが、一つだけ追加します。

彼らは雇用をより困難にしました。

• すべての新規採用者は、ソフトウェア/ドメインの単なる主要部分よりもさらに急な学習曲線を持っています
• 最良の候補者は、スキルを未使用にしたくないため、先送りされます。
• 自分のお気に入りのツールを使用できないことがどれほど悪いかを理解すると、人々は長く滞在する可能性が低く、スタッフの離職は高価です

もちろん、チャレンジが好きな人もいるでしょうが、彼らは少数派になると思います。

同様に、「インターネットスケール」、Amazon、Facebookなどで業務を行っている企業もありますが、そこでは非常に多くのカスタムニーズがありますが、これらも少数です。

ソフトウェア会社は、サードパーティやオープンソースソフトウェアに依存せずに今日生き残ることはできないと思います。競争力を維持するためには、もちろん積極的に新しいテクノロジーを追跡する必要があります。ただし、多くの場合、少なくともかなり防御的な見方をする十分な理由があります。

たとえば、ソフトウェアを販売し、24時間年中無休のサポートを提供し、ソフトウェアが正しく動作するよう法的に責任があると主張する場合、問題が発生した場合に何が起こるのかについて非常に正確な考えを持つ必要がありますたとえば、1時間の生産停止に数百万ドルの費用がかかる工場でソフトウェアを使用すると、使用しているオープンソースライブラリに重大なバグが発生します。私を信じて、あなたは問題のソフトウェアの非常に徹底的な評価を実行します。

ただし、このシナリオを書いたことから、問題の核心にはないようです。

あなたが特定の規模のテクノロジーベースの会社である場合、あなたはあなた自身のテクノロジーをますます開発しているように思われます：例えば、Googleはほとんどではないにしてもほとんどすべてのソフトウェアを開発していますそれを業界標準にしようとしています。

中小企業にとって、独自のビジネスロジックを備えた特定の製品を出荷しようとするのは、まったく時間の無駄のように思えます。私の経験では、中小企業がそうすることは見ていません。

高度に専門化されたコードベースについて話している場合、より複雑になります。たとえば、暗号化アルゴリズム-一部の人々はその仕組みについて基本的な理解を持っていますが、実際にソリューションを実装する複雑な部分は足を踏み入れるようなものですそのようなことを専門とする暗号作成者を雇わない限り。

一部の企業は、より適切と思われる独自のオープンソースプロジェクトを自由に作成することを許可しています。

私は個人的にそのような文化のある場所には行きません。

あなたが持っているのは、2回目のインタビューに参加して、彼らにいくつかの難しい質問をする本当に良い機会です。私は会社が何をしているのか分からないので、なぜこれが奇妙な選択のように見えるのかを言うのは難しいです。Googleのサードパーティライブラリの使用に関して、@ Daniel Prydenのコメントを使用できます。

社内で使用するか、サードパーティ製であるかにかかわらず、使用するソフトウェアには長所と短所があります。たとえそれが仕事に最適なツールであっても、それが社内にないため、ツールを使用しないことは、特定の閉じた考え方を示し、それは革新と創造性を決して奨励しません。

ただし、おそらく、あなたはその変化を紹介する人です。すべての幸運を祈ります。

もちろん、立ち去るべきです。ここで言及したことはありませんが、仕事を引き継ぐ最大の理由は、譲渡可能なスキルをあまり得られないからです。

次のインタビューで、どのテクノロジーを使用したかを尋ねられたときに想像してみてください。C++のベアボーンのみに言及できます。

大企業はすべてを自分で書きます。

自分で作成することにはいくつかの利点があります。

1. あなたは自分でソフトウェアを所有することが保証されています
2. 作成に費やした作業量を正しく計算できます
3. 次回ライブラリが利用できない場合でも、手順を繰り返すことが可能になります
4. それはあなたの要件の肥大化を削減します
5. あなたは他の人がすでにやったことを繰り返していません
6. あなたはそれを維持するのに十分な人がいることが保証されています
7. ソフトウェアのすべての部分を変更できます
8. ソフトウェアのサイズは、所有するリソースの量によって制限されます

他の人のライブラリを使用した場合、各ポイントがどのように壊れるかを以下に示します。

1. 他の誰かがライブラリを所有している
2. ライブラリの作成にどれだけの労力が費やされたのかわかりません
3. 同じライブラリが利用できなくなったため、製品の次のバージョンを新しいプラットフォームで作成することはできません
4. 要件を実装する能力は、ライブラリが数年前に実装したかどうかに依存します
5. 他の人も同じライブラリを使用しており、同じ制限と機能を取得しています
6. ライブラリを作成しなかったため、製品内のすべてのソフトウェアを保守するのに十分な人員がいません
7. Libはバイナリであり、変更できません。ソースが利用可能であっても、その大量のコードを変更するのに十分な人員がいません。
8. 作成したコードとライブラリの保守は、当初の見積もりよりも大きな労力です