What prompts my question is this post from Jeff Atwood, and this post from Dare Obasanjo. It seems to me that there might be at least a few areas where third-party functionality is a better idea than custom code.
For example, should logging always be third-party? How about encryption? Or search?
I'm looking forward to everyone's feedback on this.
Edit: This question assumes that logging, encryption, and/or search isn't your core business.
ほとんどの場合、暗号化はサードパーティでなければなりません...暗号化システムを販売するビジネスをしている場合を除きます。
私が理解しているように、これはアトウッド氏の主張のほとんどです。あなたのコアビジネスはサードパーティであってはならないので、常にサードパーティであるべきものはおそらくないでしょう...
「常にサードパーティであるべき機能は何ですか?」
なし。本質的にエンジニアリング上の決定について議論するとき、「常に」という悪質な使用を無効にする例外または特別なケースが常に存在します。
さらに、サードパーティに移行するという決定は、特定の「機能」に基づいて行われることはほとんどありません。そのタイプの機能のために他の場所に行く必要がないような完璧なライブラリなどはありません。
サードパーティへの移行は、以下に基づいて下すべき決定です。
でも。家にいる方が良いと信じるのが本当に難しいことがいくつかあります. たとえば、OpenGL と DirectX の競合を作成できます。特定のアプリケーション (科学計算など) では、そのようなパスを検討する十分な理由があります。しかし、一般的には夢にも思いません。「無料」とはいえ、サードパーティの依存関係であり、これらのグラフィック言語の使用方法にのみ影響するバグのために、スキッドに陥る可能性があります.
言い換えれば、信じられないほど複雑で証明/テストが困難なものがいくつか存在し、ほとんどの場合サードパーティに行く必要があります. セキュリティは別のものです。独自のハッシュ アルゴリズムを作成しないでください。ただし、1) 確実にクレイジーであり、2) 少なくとも 3 つの優れたビジネス上の理由がある場合を除きます。
しかし、「常にサードパーティであるべき機能は何ですか?」なし。常に例外があります。
-アダム
私の経験則は、あなたのビジネスの中心的な目的以外のものにはサードパーティを使用する (または少なくとも検討する) ことです。
暗号化は常にこの典型的な例です。しかし、それは他の分野にも及んでいます。
開発中にトラブルシューティング用のログ コードを記述することは、運用システムの監視に使用されるログ コードを記述することとはまったく異なります。
重要なのは、開発のどの領域が実際にプロジェクトに価値をもたらすかを選択することです。サードパーティのものを使用すると、そのコンポーネントが不完全/バグがあるなどのリスクがなくなります。ただし、必要なほど柔軟ではない可能性があるというリスクが伴います。
もう 1 つの例は、ソリューションをはるかに安く購入できる場合に、Web サイトの Web フォーラム全体を開発することです。
暗号化は可能な限り専門家のみが行うべきであることに完全に同意します。また、オープン ソースである必要があり、多くのピア レビューを受けています。
場合によります。あなたのニーズに合った利用可能なサードパーティのライブラリはありますか?最も重要なのは、使用する言語や API です。それからそれのために行きます。
独自のバージョンを作成する理由がある場合は、それが「ここで発明されたものではない」だけではないことを確認してください。また、市場のトップ 5 の主要製品を詳しく調べていない場合は、十分に仕事をしているとは言えません。探しているものが見つかる可能性は高く、たとえそれを使用できなくても、ライブラリの説明からでも何かを学ぶことができます。最低限、どの機能が必要で、どの機能が不要かを学習します。いずれかのライブラリのソース コードも取得する場合は、ソース コードはなくても機能が多い可能性がある競合ライブラリよりも、これを選択することをお勧めします。
構築するよりも安く購入でき、購入した機能がビジネス要件を満たしている場合は、購入してください。
私が一貫してサードパーティのコントロールを使用してきた領域はチャート作成でした。一部のデータのバッチをグラフ化する必要があるのはかなり一般的な問題であり、サードパーティのコントロールは成熟しており、信頼できます。
答えは使い方次第だと思います。利益のために開発している場合、コンポーネントを使用するコストと開発するコストがより多くの利益をもたらす場合、コンポーネントを購入する可能性があります。これは、社内に製造するための専門知識がない大型コンポーネントの場合に特に当てはまります。
私が使用したいくつかの良い例は、Infragistics コントロールと Dundas チャートです。これらを社内で作成することもできましたが、数ライセンスを購入する場合に比べて、時間と機会損失のコストが膨大になります。
もちろん、コンポーネントの購入とは考えずに、この種のことを行うこともあります。少し想像力を広げて、.NET フレームワーク、SQL Server、Windows API などを含めることができます。
この質問は、「どのソフトウェアを作成する必要がありますか?」という質問の逆です。
これは明らかにばかげています。
どちらの場合も、答えは 1 つではなく、ビジネスのニーズによって異なります。インターネット全体のためのより優れた検索エンジンを構築する必要がありますか? ほぼ確実にそうではありません。しかし、あなたが 90 年代後半の Google なら、そうします。サードパーティ対ファーストパーティは、どのオフィスで働いているかの問題であり、すべてのサードパーティは自分自身のファーストパーティです。
品質の低いものを作成するか、それほど重要でないものにお金と労力を浪費するか、またはその両方です。
より良いものを構築でき、そのより良いものからビジネスを構築できるなら、そうしてください!
この質問に対する決定的な答えはありません。ソフトウェア開発の他のことと同様に、状況に依存するからです。次の3つの項目が当てはまる場合は、自分でやろうと考えるべきではないと思います...
必要な回答はすべて揃っているようですが、他の皆様の意見と合わせて、ここに私の意見を述べたいと思います。クライアントは、彼らのために特別に機能するアプリケーションを作成するためにあなたにお金を払います。彼らが必要とするものは、市場に出回っている他のどの製品にもありません。したがって、彼らが必要とする特定の部分を開発することに焦点を当てる必要があります。
間違いなく、アプリケーションは他のことも行う必要があります。データベースに接続するか、特定の行を暗号化する必要があるかもしれません。ここでサードパーティのライブラリが活躍します。データベース用の新しいドライバーや、テストする時間がない穴がある可能性のある新しい暗号化スキームを作成するのに時間を無駄にしたくありません。すでに存在し、広範囲にテストおよび最適化されたものを使用したい場合。
覚えておいてください、あなたが早く終わるほど、彼らが支払わなければならない金額は少なくなります. これは彼らを幸せにし、あなたに戻ってきたいと思っています. これは、彼らが支払う金額が少なくても、より多くのプロジェクトに取り組むことができるため、より多くの収入を得ることを意味します。つまり、より多くのお金を意味します。
結論として、その他のモジュールではサードパーティのライブラリに依存する必要があります。
コア ビジネス以外のものはすべて、サードパーティ ソリューションの有力な候補です。開発に時間を費やして、独自の (らしい) コア機能を作成し、費用対効果の高いマナーで購入して使用することはできません。
たとえば、Web グリッドビュー コントロールを見てみましょう。グリッドビューを自分で開発および拡張できますか? 確かにできますが、グリッド ビューを開発、コーディング、およびテストするには、X 倍の時間とリソースが必要であり、これはドルに換算できます。これで、サポート、メンテナンス、およびバグ修正のために繰り返し発生するコストを考慮に入れることができます。
ここで、平均的な米国の開発者が福利厚生を含めて 1 時間あたり 40 ドルを稼いでいることについて雑誌で読んだことを覚えている任意の金額を使用してみましょう。開発者ライセンスあたり約 800 ドルで利用可能な Web コントロール スイート全体があります。開発者がこの 1 つのコントロールに合計 25 時間以上費やしている場合、スイート全体を購入し、統合とテストに 5 時間を費やしていた可能性があります。
ここであまり混乱していないことを願っていますが、一般的な要点は、自分でそれを購入できれば、おそらく時間とお金を節約でき、代わりに、通常は自分のお金である自分から離れられないものに焦点を当てることです。メーカー。
すべてを手で書くには時間がかかることを忘れないでください。それができないわけではありませんが、システムを構築するための最速の方法を常に見つけたいと考えている顧客や会社から問題が生じます。しかし、非営利のプロジェクトがある場合は、自分で何かを構築してみることができます。たとえば、Web アプリケーションを作成していて、いくつかの ajax 機能を設定したい場合は、JQuery または Dojo を ajax ツールキットとして使用できます。これらのものを手動で構築するには時間がかかります :)
ただし、サードパーティのライブラリを使用する場合も注意が必要です。悪意のあるコードが含まれている可能性があるため、それらを信頼する必要があります。そうしないと、記述が非常に不十分で頭痛の種になる可能性があります。
独自の暗号化機能? 考えてもいけませんが、おそらく既存の関数のある種のラッパーを意味していると思います。
サードパーティ製コンポーネントの利点: 豊富な機能
完全にテスト済み (うまくいけば!
)
短所
次の顧客の要件に対応できる柔軟性があるか
配布に費用がかかる可能性がある
サードパーティの会社に縛られて、バグを修正するために新しいリリースを作成するときに苦労する可能性がある
自分でタスクを実行することを学ばない
サードパーティのコンポーネントを使用するかどうかは、アプリケーションと要件によって異なります。グラフのようなものは正しくなるまでに時間がかかるため、サードパーティ製のコンポーネントを使用するとよいでしょう。
ボイラー プレート コード、またはほぼ毎回コピー アンド ペーストされる冗長なコードを記述する場合は、ライブラリを介して行う必要があります。私にとって、バリデーション コードは退屈なので、ほとんどの場合、ばかげた間違いを犯します。Spring.NET はこれに関して驚くべきことです。上司が私にそれを試してみるように勧めてくれてとてもうれしいです。