依存関係を取ることへの恐怖に対処する方法
私が所属しているチームは、会社のパートナーがプラットフォームと統合するために使用できるコンポーネントを作成しています。
そのため、（サードパーティの）依存関係を導入する際には細心の注意を払う必要があることに同意します。現在、サードパーティの依存関係はなく、フレームワークの最も低いAPIレベルを維持する必要があります。
いくつかの例：
- フレームワークの最も低いAPIレベル（.NET Standard）を維持する必要があります。この背後にある理由は、その非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか登場する可能性があることです。
- JSONを（デ）シリアライズするための独自のコンポーネントを実装しており、JWTでも同じことを行っています。これは、フレームワークAPIの上位レベルで使用できます。
- 標準ライブラリのHTTP実装に依存したくないので、標準ライブラリのHTTPフレームワークのラッパーを実装しました。
- 同じ理由で、XMLへのマッピングまたはXMLからのマッピングのコードはすべて「手動」で記述されています。
行き過ぎだと思います。これは私たちの速度に大きな影響を与えると思うので、これに対処する方法を考えています。
...フレームワークの最も低いAPIレベル（.NET Standard）を維持することを余儀なくされています…
これは私にあなたが潜在的に自分自身を制限しすぎているだけでなく、あなたのアプローチで厄介な転倒に向かっているかもしれないという事実を強調しています。
.NETスタンダードは、「フレームワークの最も低いAPIレベル」ではなく、決してありません。 .NETのAPIの最も制限的なセットは、Windows PhoneとSilverlightを対象とするポータブルクラスライブラリを作成することで実現されます。
対象とする.NET Standardのバージョンに応じて、.NET Frameworkと互換性のある非常に豊富なAPIのセットが作成される可能性があります 。NET Core 、 Mono 、および Xamarin 。また、.NET Standardと互換性のある多くのサードパーティライブラリがあり、これらすべてのプラットフォームで動作します。
次に、.NET Standard 2.1があり、2019年の秋にリリースされる可能性があります。NETCore、Mono、およびXamarinでサポートされる予定です。 これは、.NET Frameworkのどのバージョンでもサポートされません 、少なくとも予見可能な将来のために、そしておそらく常にそうです。したがって、近い将来、「フレームワークの最も低いAPIレベル」とはほど遠い、.NET標準はフレームワークに取って代わり、後者によってサポートされます。
「この背後にある理由は、非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか到着する可能性があることです」と非常に注意してください。新しいプラットフォームは、実際には古いフレームワークよりも高レベルのAPIをサポートします。
次に、サードパーティのライブラリの問題があります。たとえば、JSON.NETは.NET標準と互換性があります。 .NET Standardと互換性のあるライブラリはすべて、APIの観点から、そのバージョンの.NET Standardと互換性のあるすべての.NET実装で動作することが保証されています。したがって、それを使用せずにJSONライブラリを作成しても、追加の互換性は得られません。自分のためにより多くの作業を作成し、会社に不必要なコストをかけるだけです。
だから、はい、あなたは間違いなくこれを私の見方から離れすぎています。
私たちはフレームワークの最も低いAPIレベル（.net標準）にとどまることを余儀なくされています。この背後にある理由は、その非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか登場する可能性があることです。
ここでの推論はかなり逆です。古いAPIレベルは、新しいAPIレベルよりも古くなり、サポートされなくなる可能性が高くなります。 「最先端」の背後で快適な方法を維持することは、あなたが言及したシナリオで妥当なレベルの互換性を確保するために賢明であることに同意しますが、決して前進することは極端ではありません。
JSONを（逆）シリアライズするための独自のコンポーネントを実装しており、JWTでも同じことを行っています。これは、フレームワークAPIの上位レベルで使用できます。標準ライブラリのHTTP実装に依存したくないので、標準ライブラリのHTTPフレームワークのラッパーを実装しました。同じ理由で、XMLへのマッピングまたはXMLからのマッピングのコードはすべて「手動」で記述されています。
狂気です。何らかの理由で標準ライブラリ関数を使用したくない場合でも、オープンソースライブラリは、上記のすべてを行う商用互換ライセンスで存在します。これらはすでに作成されており、機能、セキュリティ、API設計の観点から広範囲にテストされており、他の多くのプロジェクトで広く使用されています。
最悪の事態が発生し、そのプロジェクトがなくなった場合、または維持されなくなった場合は、とにかくライブラリを構築するためのコードを入手し、誰かにそれを維持するよう割り当てます。そして、あなたはおそらくそれでも自分でロールした場合よりもはるかに良い位置にいるでしょう。実際には、より多くのテストされた、よりクリーンでメンテナンス可能なコードがあるからです。
プロジェクトが維持され、それらのライブラリにバグまたはエクスプロイトが見つかるはるかに可能性の高いシナリオでは、それらについて知っているため、新しいバージョンに無料でアップグレードしたり、バージョンにパッチを適用したりするなど、プロジェクトについて何かを行うことができますコピーを取った場合の修正。
全体として、これらのことはあなたの顧客にとって良いことです。人気のあるオープンソースライブラリでさえ、何らかの理由で使用できない場合があります。
たとえば、オープンソース製品を使用しないことを約束する顧客との契約を結んだ可能性があります。
ただし、ご指摘のとおり、これらの機能にはコストがかかります。
- 市場投入までの時間
- パッケージのサイズ
- パフォーマンス
私はこれらの不利な点を挙げ、顧客と話し合って、提供している互換性のレベルが本当に必要かどうかを確認します。
たとえば、すべての顧客がすでにJson.NETを使用している場合は、独自の逆シリアル化コードではなく製品でJson.NETを使用すると、サイズが小さくなり、改善されます。
サードパーティのライブラリと互換性のあるライブラリを使用する製品の2番目のバージョンを導入する場合、両方の採用を判断できます。顧客はサードパーティを使用して最新の機能を少し早く入手するのですか、それとも「互換性のある」バージョンを使用するのですか？
簡単に言えば、サードパーティの依存関係の導入を開始する必要があるということです。次のスタンドアップミーティングで、来週の仕事が数年で最も楽しいものになることを全員に伝えます。彼らはJSONおよびXMLコンポーネントをオープンソースの標準ライブラリソリューションに置き換えます。 JSONコンポーネントを置き換えるには3日間あることを全員に伝えます。終わったらお祝いしましょう。パーティーを開く。これは祝福する価値があります。
基本的に、それはすべて労力とリスクに帰着します。
追加の依存関係を追加したり、フレームワークを更新したり、より高レベルのAPIを使用したりすることで、労力を軽減できますが、リスクを負うことになります。だから私は SWOT分析 を行うことをお勧めします。
- 長所：自分でコーディングする必要がないため、労力が少なくて済みます。
- 弱点：手作りのソリューションほど、特別なニーズに合わせてカスタム設計されたものではありません。
- 機会：市場投入までの時間が短くなります。外部開発から利益を得るかもしれません。
- 脅威：追加の依存関係で顧客を混乱させる可能性があります。
ご覧のとおり、手作りのソリューションを開発するための追加の努力は、脅威を軽減するための投資です。今、あなたは戦略的な決定をすることができます。