Comment gérer la peur de prendre des dépendances
L'équipe dans laquelle je travaille 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 être extrêmement prudents lors de l'introduction de dépendances (tierces). Actuellement, nous n'avons pas de dépendances tierces et nous devons rester au niveau d'API le plus bas du framework.
Quelques exemples:
- Nous sommes obligés de rester au 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 ne prend en charge que ce très bas niveau d'API.
- Nous avons implémenté nos propres composants pour (dé) sérialiser JSON et sommes en train de faire de même pour JWT. Ceci est disponible à un niveau supérieur de l'API du framework.
- Nous avons implémenté un wrapper autour du cadre HTTP de la bibliothèque standard, car nous ne voulons pas prendre de dépendance sur l'implémentation HTTP de la bibliothèque standard.
- Tout le code pour le mappage vers/depuis XML est écrit "à la main", toujours pour la même raison.
Je sens que nous allons trop loin. Je me demande comment y faire face, car je pense que cela a un impact important sur notre vitesse.
... Nous sommes obligés de rester au niveau d'API le plus bas du framework (.NET Standard)…
Pour moi, cela souligne le fait que, non seulement vous vous limitez potentiellement trop, vous vous dirigez peut-être aussi vers une chute brutale avec votre approche.
.NET Standard n'est pas et ne sera jamais " le niveau d'API le plus bas du framework ". L'ensemble d'API le plus restrictif 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 avec .NET Standard qui fonctionneront donc sur toutes ces plateformes.
Ensuite, il y a .NET Standard 2.1, qui devrait sortir à 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 , au moins dans un avenir prévisible, et très probablement toujours. Donc, dans un avenir proche, loin d'être " le niveau d'API le plus bas du framework ", .NET Standard remplacera le framework et aura des API qui ne sont pas " t soutenu par ce dernier.
Soyez donc très prudent avec " Le raisonnement derrière cela est qu'une nouvelle plate-forme pourrait un jour arriver qui ne prend en charge que ce très bas niveau d'API " car il est fort probable que les nouvelles plates-formes prendront en charge une API de niveau supérieur à celle de l'ancien framework.
Ensuite, il y a le problème des bibliothèques tierces. JSON.NET par exemple est compatible avec .NET Standard. Toute bibliothèque compatible avec .NET Standard est garantie - au niveau de l'API - pour fonctionner avec toutes les implémentations .NET qui sont 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 vous engagez des coûts inutiles pour votre entreprise.
Alors oui, vous allez certainement trop loin à mon avis.
Nous sommes obligés de rester au niveau d'API le plus bas du framework (standard .net). Le raisonnement derrière cela est qu'une nouvelle plate-forme pourrait un jour arriver qui ne prend en charge que ce très bas niveau d'API.
Le raisonnement ici est plutôt à l'envers. Les niveaux d'API plus anciens et inférieurs sont plus susceptibles 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'écart du "tranchant" pour garantir un niveau raisonnable de compatibilité dans le scénario que vous mentionnez, ne jamais aller de l'avant est au-delà de l'extrême.
Nous avons implémenté nos propres composants pour (dé) sérialiser JSON, et nous sommes en train de faire de même pour JWT. Ceci est disponible dans un niveau supérieur de l'API du framework. Nous avons implémenté un wrapper autour du cadre HTTP de la bibliothèque standard car nous ne voulons pas prendre de dépendance sur l'impelemntation HTTP de la bibliothèque standard. Tout le code pour le mappage vers/depuis XML est écrit "à la main", toujours pour la même raison.
C'est folie. Même si vous ne voulez pas utiliser les fonctions de bibliothèque standard pour une raison quelconque, les bibliothèques open source existent avec des licences compatibles avec le commerce qui font tout ce qui précède. Ils ont déjà été écrits, largement testés du point de vue de la fonctionnalité, de la sécurité et de la conception d'API, et largement utilisés dans de nombreux autres projets.
Si le pire se produit et que ce 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 encore dans une bien meilleure position que si vous aviez roulé le vôtre, car en réalité vous aurez un code plus testé, plus propre et plus maintenable à entretenir.
Dans le scénario beaucoup plus probable où le projet est maintenu et où des bogues ou des exploits sont trouvés dans ces bibliothèques, vous en serez informés, alors vous pouvez faire quelque chose à ce sujet - comme la mise à niveau gratuite vers une version plus récente ou le patch de votre version avec le correctif si vous en avez pris une copie.
Dans l'ensemble, ces choses sont bonnes pour vos clients. Même une bibliothèque open source populaire pourrait leur être impossible à utiliser pour une raison quelconque.
Par exemple, ils peuvent avoir signé un contrat avec leurs clients promettant de ne pas utiliser de produits open source.
Cependant, comme vous le faites remarquer, ces fonctionnalités ne sont pas sans coût.
- Délai de mise sur le marché
- Taille de l'emballage
- Performance
Je voudrais soulever ces inconvénients et parler avec les clients pour savoir s'ils ont vraiment besoin des niveaux de compatibilité uber que vous proposez.
Si tous les clients utilisent déjà Json.NET par exemple, alors l'utiliser 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, une qui utilise des bibliothèques tierces ainsi qu'une compatible, vous pouvez juger de l'adoption 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 réponse courte est que vous devriez commencer à introduire des dépendances tierces. Au cours de votre prochaine réunion debout, dites à tout le monde que la semaine prochaine au travail sera la plus amusante qu'ils auront eu depuis des années - ils remplaceront les composants JSON et XML par des solutions de bibliothèques standard open source. Dites à tout le monde qu'ils ont trois jours pour remplacer le composant JSON. Célébrez une fois terminé. Faire la fête. Cela vaut la peine d'être célébré.
Fondamentalement, tout se résume à l'effort vs le risque.
En ajoutant une dépendance supplémentaire ou en mettant à jour votre framework ou en utilisant une API de niveau supérieur, vous réduisez vos efforts mais vous prenez des risques. Je suggère donc de faire un analyse SWOT .
- Forces: moins d'efforts, car vous n'avez pas à le coder vous-même.
- Faiblesses: Ce n'est pas aussi conçu sur mesure pour vos besoins spéciaux qu'une solution artisanale.
- Opportunités: le temps de mise sur le marché est plus court. Vous pourriez bénéficier de développements externes.
- Menaces: vous pourriez déranger les clients avec des dépendances supplémentaires.
Comme vous pouvez le voir, l'effort supplémentaire pour développer une solution artisanale est un investissement pour réduire vos menaces. Vous pouvez maintenant prendre une décision stratégique.