依存関係を取ることへの恐怖に対処する方法

私が所属するチームは、当社のプラットフォームと統合するために会社のパートナーが使用できるコンポーネントを作成します。

そのため、（サードパーティの）依存関係を導入する際には細心の注意を払う必要があることに同意します。現在、サードパーティの依存関係はなく、フレームワークの最も低いAPIレベルを維持する必要があります。

いくつかの例：

• フレームワークの最も低いAPIレベル（.NET標準）を維持する必要があります。この背後にある理由は、その非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか登場する可能性があるということです。
• JSONを（デ）シリアライズするための独自のコンポーネントを実装しており、JWTでも同じことを実行中です。これは、フレームワークAPIの上位レベルで利用可能です。
• 標準ライブラリのHTTP実装に依存したくないため、標準ライブラリのHTTPフレームワークのラッパーを実装しました。
• 同じ理由で、XMLとの間でマッピングするためのコードはすべて「手作業で」記述されます。

私たちはそれをやりすぎだと感じています。これは私たちの速度に大きな影響を与えると思うので、これにどう対処するのか疑問に思っています。

...フレームワークの最も低いAPIレベル（.NET標準）に留まることを余儀なくされています…

これは、自分自身を制限しすぎる可能性があるだけでなく、アプローチでひどい転倒に向かっている可能性があるという事実を強調しています。

.NET Standardはそうではなく、「フレームワークの最も低いAPIレベル」になることはありません。.NETのAPIの最も制限されたセットは、Windows PhoneとSilverlightを対象とするポータブルクラスライブラリを作成することによって実現されます。

対象とする.NET Standardのバージョンに応じて、.NET Framework、.NET Core、Mono、およびXamarinと互換性のある非常に豊富なAPIのセットになります。また、.NET Standardと互換性のあるサードパーティライブラリが多数あり、これらのすべてのプラットフォームで動作します。

その後、2019年秋にリリースされる可能性が高い.NET Standard 2.1があります。.NETCore、Mono、およびXamarinでサポートされます。少なくとも当分の間、.NET Frameworkのどのバージョンでもサポートされることはなく、おそらく常にサポートされます。そのため、近い将来、「フレームワークの最も低いAPIレベル」ではなく、.NET Standardはフレームワークに取って代わり、後者によってサポートされていないAPIを持つことになります。

新しいプラットフォームは実際には古いフレームワークよりも高いレベルのAPIをサポートする可能性が高いので、「この背後にある理由は、いつかその非常に低いAPIレベルのみをサポートする新しいプラットフォームが到着する可能性があるということです」

次に、サードパーティのライブラリの問題があります。たとえば、JSON.NETは.NET Standardと互換性があります。.NET Standardと互換性のあるライブラリはすべて、APIバージョンごとに、そのバージョンの.NET Standardと互換性のあるすべての.NET実装で動作することが保証されています。したがって、使用せずにJSONライブラリを作成することで、追加の互換性を実現することはできません。単に自分のために仕事を増やし、会社に不必要なコストをかけるだけです。

そうです、あなたは間違いなくこれをあまりにも遠慮していると思います。

フレームワークの最も低いAPIレベル（.net標準）を維持する必要があります。この背後にある理由は、その非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか登場する可能性があるということです。

ここでの理由はかなり逆です。古い、低いAPIレベルは、新しいものよりも廃止され、サポートされなくなる可能性が高くなります。「最先端」の背後にある快適な方法を維持することは、あなたが言及したシナリオで妥当なレベルの互換性を確保するために賢明であることに同意しますが、前進することは極端ではありません。

JSONを（デ）シリアライズするための独自のコンポーネントを実装しており、JWTでも同じことを実行中です。これは、フレームワークAPIの上位レベルで利用可能です。標準ライブラリのHTTPフレームワークに依存したくないため、標準ライブラリのHTTPフレームワークのラッパーを実装しました。同じ理由で、XMLとの間でマッピングするためのコードはすべて「手作業で」記述されます。

これは狂気です。何らかの理由で標準ライブラリ関数を使用したくない場合でも、上記のすべてを行う商業的に互換性のあるライセンスを持つオープンソースライブラリが存在します。これらはすでに記述されており、機能、セキュリティ、およびAPI設計の観点から広範囲にテストされ、他の多くのプロジェクトで広範囲に使用されています。

最悪の事態が発生し、そのプロジェクトがなくなるか、メンテナンスが停止した場合は、とにかくライブラリをビルドするためのコードがあり、それをメンテナンスするために誰かを割り当てます。そして、あなたは可能性が高いですまだあなたが実際にあなたがより多くの後に見て、クリーナー、より保守コードをテストしているでしょうから、あなた自身の圧延したい場合よりもはるかに良い位置に。

プロジェクトが維持されている可能性が非常に高いシナリオで、それらのライブラリにバグやエクスプロイトが見つかった場合、それらについて知っているので、それについて何かを行うことができます-無料で新しいバージョンにアップグレードする、バージョンにパッチを適用するなどコピーを撮った場合は修正します。

全体として、これらのことは顧客にとって良いことです。人気のあるオープンソースライブラリでさえ、何らかの理由で使用できない場合があります。

たとえば、彼らはオープンソース製品を使用しないことを約束する顧客との契約に署名した可能性があります。

ただし、ご指摘のとおり、これらの機能にはコストがかかります。

• 市場投入までの時間
• パッケージのサイズ
• 性能

私はこれらの欠点を上げ、顧客と話し合い、提供している非常に高いレベルの互換性が本当に必要かどうかを調べます。

たとえば、すべての顧客がすでにJson.NETを使用している場合は、独自のデシリアライゼーションコードではなく製品でJson.NETを使用すると、サイズが縮小されて改善されます。

サードパーティのライブラリを使用する製品と互換性のある製品の2つ目のバージョンを導入する場合、両方での使用を判断できます。顧客はサードパーティを使用して最新の機能を少し早く入手するのですか、それとも「互換」バージョンを使用するのですか？

簡単な答えは、サードパーティの依存関係を導入し始めることです。次回のスタンドアップミーティングでは、来週の仕事が何年もの間で最も楽しいものになることを皆に伝えましょう。JSONとXMLコンポーネントをオープンソースの標準ライブラリソリューションに置き換えます。JSONコンポーネントを置き換えるには3日間あることを全員に伝えます。終わったら祝いましょう。パーティーを開く。これは祝う価値があります。

基本的に、それはすべて努力対リスクに帰着します。

追加の依存関係を追加するか、フレームワークを更新するか、より高いレベルのAPIを使用することにより、労力は減りますが、リスクを負います。したがって、SWOT分析を行うことをお勧めします。

• 長所：自分でコーディングする必要がないため、労力が少なくなります。
• 弱点：特別なニーズのために手作りされたソリューションほどカスタム設計されていません。
• 機会：市場投入までの時間が短縮されます。外部の開発から利益を得るかもしれません。
• 脅威：依存関係が増えて顧客を混乱させる可能性があります。

ご覧のとおり、手作りのソリューションを開発するための追加の努力は、脅威を減らすための投資です。これで、戦略的な決定を下すことができます。

コンポーネントライブラリを、依存関係のない「コア」セット（基本的に現在実行していること）と、「コア」およびサードパーティライブラリに依存する「共通」セットに分割します。

そうすれば、誰かが「コア」機能のみを必要とする場合、それを使用できます。

「共通」機能が必要な場合は、それを使用できます。

また、「コア」と「共通」を管理できます。「Common」により迅速に機能を追加し、独自の実装を提供することが理にかなっている場合は、独自の「Core」実装に移動できます。