Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Quel que soit le type d’application à réaliser, ou la technologie employée, le choix des dépendances est critique. Certaines peuvent vous simplifier la vie aujourd’hui et la transformer en véritable cauchemar à long terme.

Je vous propose aujourd’hui de présenter quelques points à ne pas négliger au moment d’effectuer ce choix.

Licences

Trouver des produits gratuits, c’est bien. Trouver un produit que vous avez le droit d’utiliser, c’est mieux. Je ne vais pas vous faire un cours sur les différents types de licences. Ce serait trop barbant, et je ne suis pas certain de maitriser ni d’arriver à couvrir la totalité des licences disponibles aujourd’hui.

GNU, GPL, BSD, Apache, MIT… Il y en a pour tous les gouts, toutes les couleurs, et certaines existent en plusieurs versions.

Que vos dépendances soient gratuites ou payantes, il faut être très vigilant sur les sujets suivants :

• Avez-vous le droit de distribuer ces dépendances à vos utilisateurs (binaires, scripts, etc.) ? Il n’est pas rare que l’on ait le droit d’utiliser une dépendance dans un cadre éducatif, pour découverte d’un produit, la R&D ou pour un projet Open Source, mais que la commercialisation soit interdite. Il arrive aussi que la redistribution gratuite soit soumise à conditions.
• Votre propre licence est-elle compatible ? Cela peut sembler un peu tordu, mais il arrive qu’une licence interdise la redistribution d’une application sous une autre licence.
• La licence de la dépendance vous oblige-t-elle à distribuer votre code source ?
• Devez-vous citer la dépendance comme faisant partie de votre application.
• Comment exploiter une dépendance payante ? La licence doit être acquise en fonction du nombre de développeurs, de serveurs, d’agents de builds, d’applications, de clients ?

Attention : n’aller pas penser que pour éviter d’avoir à respecter la licence, il suffit de copier le code qui vous intéresse. Il s’agit là de la pire idée qui puisse vous passer par la tête. Une licence ouverte peut protéger davantage le code que la distribution de ses livrables.

Utilité

Avez-vous vraiment besoin de telle ou telle librairie ? Ne pourriez-vous pas obtenir le même résultat par vos propres moyens.

J’ai vu beaucoup d’entreprises acquérir des librairies tierces à des fins purement esthétiques. Le genre de choses qu’un bon développeur peut très bien réaliser s’il a un peu de temps. Il faut donc être très vigilant : le temps gagné aujourd’hui vous engage à renouveler vos licences tant que vous supportez votre application (pour profiter des corrections des bugs et failles de sécurité).

Il y a aussi multitude de librairies que l’on installe par habitude sans se poser la question de leur utilité aujourd’hui (Exemple : jquery). Il faut toujours se demander si une librairie ajoute de la valeur à votre projet.

Popularité / Support / Viabilité

Avant d’installer une dépendance, il faut toujours s’intéresser à sa pérennité. Celle-ci est-elle distribuée par une entreprise viable ? Est-elle soutenue par une communauté vivante et des développeurs impliqués ? Est-ce un simple projet de fin d’études ? De quand date la dernière mise à jour ?

Nombre de projets Open Sources étant maintenus via GitHub, ces informations sont simples à trouver.

Il existe cependant un élément difficile à estimer : comment cette dépendance évolue au fils des frameworks / runtimes / SDK ?

Sur ce point, les développeurs .net ont un gros avantage : Nuget. Via Nuget, un développeur peut savoir très simplement quelles versions de .net sont supportées et quelles versions ont été supportées par le passé. Il est donc possible de se faire une idée très rapidement. De plus, il est possible de voir l’évolution des dépendances indirectes (information qui n’a pas de prix).

Maitrise / appropriation / documentation

Utiliser une dépendance implique d’avoir une bonne compréhension de celle-ci. Il est donc très important de prendre le temps de se l’approprier, d’explorer la documentation et les exemples de code fournis avec celle-ci. Bien évidemment ce temps à un coût. Il faut donc être vigilant pour ce que celui-ci ne devienne pas trop important. Toute dépendance doit vous faire gagner du temps, elle ne doit pas vous en faire perdre.

L’effectif de votre équipe de développement évoluant avec le temps, la qualité de la documentation est très importante. Celle-ci sera profitable aux nouveaux développeurs et évitera de trop mobiliser vos développeurs expérimentés.

Inutile de rappeler que Stack Overflow n’est pas une documentation …

Déploiement du poste de développement / Builds / Intégration continue

Je n’aime pas perdre mon temps à installer des PC de développement. J’installe mon Visual Studio. Je profite de Visual Studio Installer pour choisir mes composants. J’ajoute à cela VS code, PowerShell, Node.js, et le tour est joué. Sauf si je dois jouer avec des conteneurs.

Je déteste avoir à installer des outils supplémentaires.

Si une dépendance implique l’installation d’outils sur les PC de développement, il faut en avoir conscience avant même de commencer. À l’avenir, ceci peut être un frein pour les builds. À terme, cela peut bloquer la mise à jour de vos PC de développement. J’ai vu par le passé des sociétés qui conservaient durant des années d’anciens PC sous Windows XP pour être en mesure d’utiliser d’anciens outils et réaliser leurs patchs.

Pour un développeur .net, une bonne dépendance est une dépendance qui s’installe via Nuget. Il n’y a rien de plus simple.

Attention avec Node.js : il n’est pas rare qu’un module dépende d’un runtime supplémentaire (python, C++, etc.). Celui-ci devra être présent sur l’ensemble des PC de développements, serveurs ou agents de build. Il faut prendre cela en compte lors du choix de vos dépendances.

Déploiement de l’application

Le déploiement ne doit pas être négligé. Nombre de dépendances peuvent être déployées sans la moindre manipulation. Cependant, il n’est pas rare d’avoir à utiliser un msi, un exe, ou un script pour déployer des composants ou services associés à la dépendance (exemple : Crystal report).

Aujourd’hui, dans un contexte d’application .net moderne, ce type de dépendance est rare. Mais il en existe toujours. Exemple : WebView2 nécessite qu’un runtime soit déployé.

Si cela ne pose pas de véritable problème en soi, il faut garder à l’esprit qu’à terme cela limitera les plateformes sur lesquels le déploiement sera possible. Inutile d’envisager l’usage d’un cloud de type PAAS. Même s’il est vrai que sur certaines plateformes comme Azure, il est possible de déployer un msi au démarrage de son application.

Dans un contexte cloud, les VM sont souvent plus chères que le PAAS. Il ne faut donc pas qu’une dépendance réduise vos coûts à court terme tout en augmentant vos coûts récurants.

Mises à jour, montées de versions

La mise à jour des dépendances pose les mêmes problèmes que le déploiement. Exception faite qu’il est probable qu’une mise à jour conduise à l’obligation de redémarrer du PC ou serveur sur lesquels se trouve l’application (pas cool). Voici une raison de plus d’éviter les dépendances qui doivent être déployées via un msi, un exe ou un script.

Les développeurs .net doivent s’appuyer sur Nuget pour la gestion des dépendances. Cela règle les problèmes d’upgrade des dépendances directes et indirectes.

Conclusion

Une bonne dépendance :

• A une licence exploitable.
• Est utile.
• Est maintenue et documentée.
• Réduit les coûts à court terme.
• Ne doit pas introduire de coûts exorbitants à long terme.
• Est facile à déployer et mettre à jour.