L'équipe dans laquelle je suis crée crée des composants qui peuvent être utilisés par les partenaires de l'entreprise pour s'intégrer à notre plateforme.
En tant que tel, je conviens que nous devrions faire extrêmement attention lorsque nous introduisons des dépendances (de tiers). Actuellement, nous n'avons pas de dépendances tierces et nous devons rester sur le niveau d'API le plus bas du framework.
Quelques exemples:
- Nous sommes obligés de rester sur le niveau d'API le plus bas du framework (.NET Standard). Le raisonnement derrière cela est qu'une nouvelle plate-forme pourrait un jour arriver qui supporterait seulement ce très bas niveau d'API.
- Nous avons implémenté nos propres composants pour la (dé) sérialisation JSON et procédons de la même manière pour JWT. Ceci est disponible à un niveau supérieur de l'API du framework.
- Nous avons implémenté un wrapper autour de la structure HTTP de la bibliothèque standard, car nous ne souhaitons pas dépendre de la mise en œuvre HTTP de la bibliothèque standard.
- Tout le code de mappage vers / depuis XML est écrit "à la main", toujours pour la même raison.
Je pense que nous allons trop loin. Je me demande comment régler ce problème, car cela influe grandement sur notre vitesse.
Réponses:
Pour moi, cela met en évidence le fait que, non seulement vous vous restreignez potentiellement trop, mais vous risquez également une mauvaise chute avec votre approche.
.NET Standard n'est pas et ne sera jamais " le niveau d'API le plus bas du framework ". L'ensemble le plus restrictif d'API pour .NET est obtenu en créant une bibliothèque de classes portable qui cible Windows Phone et Silverlight.
Selon la version de .NET Standard que vous ciblez, vous pouvez vous retrouver avec un ensemble très riche d'API compatibles avec .NET Framework, .NET Core , Mono et Xamarin . Et il existe de nombreuses bibliothèques tierces compatibles .NET Standard qui fonctionneront donc sur toutes ces plates-formes.
Il y a ensuite .NET Standard 2.1, qui devrait être publié à l'automne 2019. Il sera pris en charge par .NET Core, Mono et Xamarin. Il ne sera pris en charge par aucune version du .NET Framework , du moins dans un avenir prévisible, et très probablement toujours. Ainsi, dans un proche avenir, loin d'être " le niveau d'API le plus bas du framework ", .NET Standard remplacera le framework et comportera des API non prises en charge par ce dernier.
Soyez donc très prudent avec " Le raisonnement derrière tout cela est qu'une nouvelle plate-forme pourrait un jour prendre en charge uniquement ce niveau très bas d'API ", car il est fort probable que les nouvelles plates-formes prendront en charge une API de niveau supérieur à l'ancien.
Il y a ensuite la question des bibliothèques tierces. JSON.NET par exemple est compatible avec .NET Standard. Toute bibliothèque compatible avec .NET Standard est assurée, du point de vue des API, de fonctionner avec toutes les implémentations .NET compatibles avec cette version de .NET Standard. Vous n'obtenez donc aucune compatibilité supplémentaire en ne l'utilisant pas et en créant votre bibliothèque JSON. Vous créez simplement plus de travail pour vous-même et engagez des coûts inutiles pour votre entreprise.
Donc oui, vous allez certainement trop loin à mon avis.
la source
evalenveloppe avec des contrôles de cohérence qui sont facilement contournés?Le raisonnement est ici plutôt en arrière. Les niveaux d'API plus anciens et inférieurs risquent davantage de devenir obsolètes et non pris en charge que les plus récents. Bien que je convienne qu'il est judicieux de rester à l'aise avec la "pointe" afin de garantir un niveau de compatibilité raisonnable dans le scénario que vous avez mentionné, ne jamais aller de l'avant est au-delà de l'extrême.
C'est de la folie . Même si vous ne souhaitez pas utiliser les fonctions de bibliothèque standard pour quelque raison que ce soit, il existe des bibliothèques open source dotées de licences compatibles avec le commerce qui remplissent toutes les conditions susmentionnées. Ils ont déjà été écrits, testés de manière approfondie du point de vue des fonctionnalités, de la sécurité et de la conception des API, et largement utilisés dans de nombreux autres projets.
Si le pire se produit et que le projet disparaît ou cesse d'être maintenu, vous avez quand même le code pour construire la bibliothèque et vous affectez quelqu'un pour le maintenir. Et vous êtes probablement toujours dans une bien meilleure position que si vous aviez réussi, puisque vous aurez en réalité un code plus éprouvé, plus propre et plus facile à gérer.
Dans le scénario beaucoup plus probable selon lequel le projet est maintenu, et que des bogues ou des exploits se trouvent dans ces bibliothèques, vous en saurez plus qu'ils peuvent alors faire quelque chose - comme mettre à niveau gratuitement une version plus récente ou appliquer des correctifs à votre version. avec le correctif si vous avez pris une copie.
la source
Dans l'ensemble, ces choses sont bonnes pour vos clients. Même une bibliothèque open source populaire pourrait être impossible pour eux d'utiliser pour une raison quelconque.
Par exemple, ils peuvent avoir signé un contrat avec leurs clients leur promettant de ne pas utiliser de produits open source.
Toutefois, comme vous l'avez fait remarquer, ces fonctionnalités ne sont pas gratuites.
Je soulèverais ces inconvénients et discuterai avec les clients pour savoir s'ils ont réellement besoin des niveaux de compatibilité élevés que vous proposez.
Si tous les clients utilisent déjà Json.NET par exemple, son utilisation dans votre produit plutôt que dans votre propre code de désérialisation réduit sa taille et l’améliore.
Si vous introduisez une deuxième version de votre produit, qui utilise des bibliothèques tierces ainsi qu’une bibliothèque compatible, vous pourrez juger de l’absorption des deux. Les clients utiliseront-ils des tiers pour obtenir les dernières fonctionnalités un peu plus tôt ou resteront-ils avec la version "compatible"?
la source
La réponse courte est que vous devriez commencer à introduire des dépendances tierces. Lors de votre prochaine réunion informelle, dites à tout le monde que la semaine prochaine au travail sera le plus amusant depuis des années: ils remplaceront les composants JSON et XML par des solutions open source et des bibliothèques standard. Indiquez à tous qu'ils disposent de trois jours pour remplacer le composant JSON. Célébrez après c'est fait. Faire la fête. Cela mérite d'être célébré.
la source
Fondamentalement, tout se résume à l'effort par rapport au risque.
En ajoutant une dépendance supplémentaire, en mettant à jour votre infrastructure ou en utilisant une API de niveau supérieur, vous réduisez vos efforts mais prenez des risques. Je suggère donc de faire une analyse SWOT .
Comme vous pouvez le constater, les efforts supplémentaires déployés pour développer une solution artisanale constituent un investissement dans la réduction de vos menaces. Maintenant, vous pouvez prendre une décision stratégique.
la source
Divisez vos bibliothèques de composants en un ensemble "principal", sans dépendances (essentiellement ce que vous faites maintenant) et en un ensemble "commun", dépendant de vos bibliothèques "principale" et tierces.
De cette façon, si quelqu'un ne veut que la fonctionnalité "principale", il peut l'avoir.
Si quelqu'un veut une fonctionnalité "commune", elle peut l'avoir.
Et vous pouvez gérer ce qui est "noyau" ou "commun". Vous pouvez ajouter des fonctionnalités plus rapidement à "Common" et les déplacer vers votre propre implémentation "Core" s'il est judicieux de fournir votre propre implémentation.
la source