Comment gérer la peur de prendre des dépendances

54

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.

— Bertus
source

20

Existe-t-il une justification pour cela (par exemple, une exigence externe) ou est-ce fait par ignorance?

— Blrfl le

6

Faites une expérience avec une petite partie de codebase, créez une couche d’isolation qui n’essaye pas d’être une bibliothèque générique, mais définit une interface abstraite qui modélise vos besoins; mettez ensuite votre propre implémentation et une dépendance tierce derrière, et comparez le fonctionnement / les performances des deux versions. Pesez le pour et le contre, évaluez à quel point il serait facile (ou difficile) d’échanger les implémentations, puis prenez une décision. En bref, testez les choses de façon relativement peu risquée, voyez ce qui se passe, puis décidez.

— Filip Milovanović Le

73

"Actuellement, nous n'avons aucune dépendance vis-à-vis de tiers" Cela me fait toujours rire quand les gens le prétendent. Bien sûr, vous le faites. Vous n'avez pas écrit votre propre compilateur, IDE, ni aucune implémentation de librairies standard. Vous n'avez pas écrit de bibliothèque d'objets que vous utilisez indirectement (ou directement). Lorsque vous réalisez à quel point les logiciels et les bibliothèques tiers sur lesquels vous comptez, vous pouvez supprimer l’idée "les dépendances sont une mauvaise" et ne pas simplement réinventer la roue. Je voudrais simplement signaler les dépendances que vous avez, puis vous demander pourquoi elles sont acceptables, mais l'analyse syntaxique Json ne l'est pas.

— UKMonkey le

8

Cela dit, il existe des inconvénients alternatifs, comme ne jamais terminer des projets. Mais cela favorise les emplois dans les logiciels et l’emploi :)

— marshal craft

5

Vous avez raison de dire que vous gaspillez vos efforts en réinventant le logiciel de base. Vous vous trompez en ce sens que cela n’est pas du tout "d’éviter toutes les dépendances". L’équipe Excel de Microsoft a déjà écrit son propre compilateur C pour éviter de créer une dépendance vis-à-vis de l’équipe C de Microsoft . Vous prenez des dépendances énormes sur les systèmes d'exploitation, les frameworks de haut niveau, etc.

— Eric Lippert le

94

... Nous sommes obligés de rester sur le niveau d'API le plus bas du framework (.NET Standard)…

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.

— David Arno
source

16

"Vous créez simplement plus de travail pour vous-même et engagez des coûts inutiles pour votre entreprise." - et des passifs de sécurité. Votre encodeur JSON se bloque-t-il avec un débordement de pile si vous lui attribuez un objet récursif? Votre analyseur gère-t-il correctement les caractères échappés? Rejette-t-il les caractères non échappés comme il se doit? Qu'en est-il des personnages de substitution non appariés? Déborde-t-il lorsque le JSON code un nombre supérieur à 2 ^ 64? Ou est-ce juste une petite evalenveloppe avec des contrôles de cohérence qui sont facilement contournés?

— John Dvorak Le

4

"L'ensemble d'API les plus restrictifs pour .NET est obtenu en créant une bibliothèque de classes portable qui cible Windows Phone et Silverlight." Je vais vous dire qu'il y a au moins certaines API dans ce sous-ensemble qui ne sont pas supportées par toutes les implémentations possibles qui aient jamais existé (et personne ne se soucie plus de WinPhone ou de Silvernight, pas même de Microsoft). Utiliser .NetStandard 2.0 comme cible d’un cadre moderne semble très prudent et n’est pas particulièrement limitatif. Mettre à jour à la version 2.1 est une autre histoire, mais rien n'indique qu'ils le feraient.

— Voo le

Mis à part les futures plates-formes prenant probablement en charge davantage que moins, le développement de tout ce qui pourrait arriver est extrêmement coûteux (et vous risquez de rater quelque chose de toute façon). Développer sans réinventer la roue fera économiser plus de temps que de s’adapter à une nouvelle situation lorsque cela sera nécessaire, cela coûtera cher.

— Jasper

51

Nous sommes obligés de rester sur le 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 supporterait seulement ce très bas niveau d'API.

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.

Nous avons implémenté nos propres composants pour la (dé) sérialisation JSON et procédons de la même façon pour JWT. Ceci est disponible dans 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 l'impélemntation HTTP de la bibliothèque standard. Tout le code de mappage vers / depuis XML est écrit "à la main", toujours pour la même raison.

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.

— berry120
source

3

Et même si vous ne pouvez pas, changer de bibliothèque est toujours plus facile et meilleur que de rouler la vôtre.

— Courses de légèreté avec Monica Le

5

Excellent point que les objets de niveau inférieur meurent plus rapidement. C'est tout l'intérêt d'établir des abstractions.

— Courses de légèreté avec Monica Le

"Les niveaux d'API les plus anciens et les plus faibles risquent davantage de devenir obsolètes et non pris en charge que les plus récents". Hein? Les normes NetSTandards sont construites les unes sur les autres pour autant que je sache (ce qui signifie que 2.0 correspond à 1.3 + X). De plus, les normes ne sont que des normes, pas des implémentations. Cela n’a aucun sens de parler d’une norme qui ne soit plus prise en charge. La plupart des implémentations spécifiques de cette norme pourraient l’être dans le futur (mais voyez le point précédent pourquoi cela n’est pas non plus une préoccupation). Si votre bibliothèque n'a besoin de rien en dehors de NetStandard 1.3, il n'y a absolument aucune raison de la changer en 2.0

— Voo

11

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.

Temps de commercialisation
Taille de paquet
Performance

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"?

— Ewan
source

11

Oui, je suis évidemment d'accord et j'ajouterais "sécurité" à votre liste. Il est possible que vous introduisiez une vulnérabilité dans votre code, en particulier avec des composants tels que JSON / JWT, par rapport à des frameworks bien testés et à la bibliothèque standard.

— Bertus le

Oui, il est difficile de faire la liste, car des éléments tels que la sécurité et les performances pourraient aller dans les deux sens. Mais il existe un conflit d’intérêts évident entre la finition et l’assurance que les composants internes sont pleinement décrits / compris

— Ewan

12

"ils peuvent avoir signé un contrat avec leurs clients leur promettant de ne pas utiliser de produits open source" - ils utilisent .NET Standard, qui est open source. C'est une mauvaise idée de signer ce contrat lorsque vous basez l'intégralité de votre produit sur un framework open source.

— Stephen

Et toujours les gens le font

— Ewan

7

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é.

— Double Vision Stout Fat Heavy
source

2

C'est peut-être la langue dans la joue, mais ce n'est pas irréaliste. J'ai rejoint une société où un développeur "senior" (senior par education only) avait chargé un développeur junior d'écrire une bibliothèque de machine à états. Il y avait cinq mois-développeur et il y avait encore une erreur, alors je l'ai déchiré et remplacé par une solution clé en main en quelques jours.

— No U

0

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 .

Points forts: Moins d'effort, car vous n'avez pas à le coder vous-même.
Points faibles: il n’est pas conçu sur mesure pour vos besoins spéciaux comme une solution artisanale.
Opportunités: le temps de marché est plus petit. Vous pourriez tirer profit d'évolutions externes.
Menaces: vous risquez de contrarier les clients avec des dépendances supplémentaires.

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.

— Dominic Hofer
source

-2

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.

— Tortue1363
source