Derrière ce titre étrange se cachent quelques conseils sur l'utilisation de dépendance externes à vos projets. Que ce soit dans le cadre d'une maintenance, de la migration d'une application ou tout simplement dans l'évolution d'une application, des dépendances mal gérées peuvent faire capoter votre projet.

1. Lister ses dépendances

Il n'y a rien de pire qu'un projet dont on ne connait pas les dépendances. Savoir quelles dépendances on a, s'est déjà connaitre une partie de ce que l'on a besoin pour faire fonctionner son application. Dans certains cas, si vous connaissez les dépendances, vous pouvez même anticiper certains problèmes.

Si l'on ne connait pas ses dépendances, il est possible que l'on ne puisse pas déployer l'application.

Dans le cadre d'une migration, c'est une étape primordiale. Cette liste vous permettra de savoir quelles dépendances pourront être conservées, mises à jour, ou devront être supprimés. Si trop de dépendances n'existent pas sur la plateforme cible, il est possible que cela change complètement la philosophie de votre projet de migration en le transformant en projet de réécriture complète (pas de chance).

2. Ne garder que des dépendances utiles

Cette remarque vous fait sourire ? Si oui, avez-vous déjà listé les dépendances utilisées par le Template d'application web de Visual Studio ? Êtes-vous certain d'avoir besoin de toutes celles-ci pour votre projet ?

Il y a trop de projets qui incluent des dépendances pour effectuer des opérations déjà possibles avec les Frameworks. Exemple : sur un projet .net on peut déjà faire de la compression ou du cryptage sans utiliser de dépendances supplémentaires (et ça n'est pas très compliqué).

Parfois, il y a de dépendances que l'on garde par habitue. Il faut être vigilant avec celles-ci et régulièrement se tenir informé sur les évolutions de son Framework pour vérifier que celles-ci ne sont pas devenues inutiles. Exemple : avec le passage de Windows 8.0 à 8.1, j'ai supprimé plus de la moitié de mes dépendances, car j'ai presque trouvé tout ce dont j'avais besoin dans WinRT et les évolutions de Xaml.

3. Bien choisir ses dépendances

On a vite fait de lancer une recherche sur CodePlex, Nuget…etc… pour aller chercher des dépendances censées nous simplifier la vie. Certain préfèrerons acheter des composants aux près de fournisseurs bien connus comme DevExpress, Telerik… etc…

Quelle que soit la source des dépendances, il faut s'assurer de :

• La viabilité de la source : un projet maintenu par un seul développeur très actif peut être parfaitement viable. Mais qu'en est-il d'un projet dont il n'y a toujours eu qu'une version ?
• La fraicheur de la dépendance : un produit qui n'a pas été mis à jour depuis longtemps est un produit qui est peut-être mort. Il n'a donc pas d'avenir. Un bon indicateur pour identifier un projet mort, c'est de vérifier qu'il utilise un Framework récent. Exemple : une dépendance qui cible .net 2 en 2014… c'est risqué.
• La maintenance corrective et évolutive : Un produit acheté doit toujours l'être avec ses mises à jour. Cela vous permettra de profiter des correctifs de celui-ci. Ce surcout doit être considéré avant tout achat pour éviter des débordements sur votre budget. J'ai déjà vu des projets en galère, car les bugs induits par les dépendances ne peuvent être résolus.
• Regarder les breacking change : toujours vérifier si une dépendance est habituée à induire des breackin change suite à ses mises à jour. S'il y en a beaucoup, vous aurez beaucoup de travail à fournir lors des mises à jour.

4. Les dépendances ont des dépendances

On l'oublie souvent, mais une dépendance peut induire l'utilisation d'autres dépendances. Rien de pire que le message disant : «  la dépendance X où l'une de ses dépendances ne peut être résolue…. ».

À ce titre, vous devez appliquer les mêmes précautions sur celles-ci que sur vos dépendances directes. Il faut aussi être très prudent sur le fait qu'une dépendance n'aille pas à contrario des contraintes qui vous sont imposées. Exemple : Dépendance indirecte qui dépend de .net 4.5 alors que vous ciblez .net 4.0.

5. Garder un œil sur ses dépendances

Comme votre application, les dépendances évoluent. Ceci peut être pour votre plus grand bonheur. Mais ceci peut aussi être un véritable casse-tête à gérer.

Les problèmes pouvant être anticipés si on suit l'actualité de ses dépendances :

• Breaking changes
• Classes/Méthodes obsolètes
• Classes/Méthodes abandonnées
• Classes/Méthodes remplacées par d'autres
• Ajout/suppression de dépendances indirectes
• Abandon du projet par l'éditeur
• .. etc…

Outre le fait de suivre ses informations, il faut aussi mettre à jour régulièrement ses dépendances. Ceci permet de réduire le travail à fournir. Si on espace les mises à jour de plusieurs mois ou années, on s'expose à de grands risques. Exemple : perte de temps, delta trop important entre deux versions et donc situation difficilement gérable.

6. Garder ses dépendances au chaud

Il faut toujours stocker les dépendances et/ou les fichiers qui ont servi à leur déploiement. Que ce soit sur un TFS, un SharePoint ou un simple partage. Ces fichiers vous seront indispensables pour remonter un environnement. Que ce soit un environnement de développement ou de production.

Même si aujourd'hui des dispositifs types Nuget sont devenus fréquents, j'ai toujours pris l'habitude de conserver les fichiers téléchargés par ceux-ci. Qui sait, la source sera peut-être coupée un jour.

Stocker, c'est bien, mais il faut aussi penser à noter clairement la plateforme cible. Il n'y a rien de pire que d'avoir deux DLL avec le même nom, le même numéro de version et ne plus savoir laquelle est destinée au 32 bits ou au 64 bits.

Il est fort probable que j'oublie une ou deux petites choses, mais l'essentiel est là.

Et vous, auriez-vous d'autres conseils à donner sur la gestion des dépendances ?