Choisir ses dépendances applicatives
Il est rare lorsque l’on développe une application d’écrire soi-même (ou une équipe) 100% du code qui fera fonctionner le projet. Nous utilisons et réutilisation de nombreux outils et composants que nous intégrons à notre code pour gagner du temps et éviter de réinventer la roue. Le choix de ces composants ne doit pas être pris à la légère car ils vont faire partie intégrante de notre code. Nous allons réfléchir dans ce billet aux différents aspects à prendre en compte.
Le premier élément à prendre en compte est le risque lié à la mise en place de la dépendance. Cette dernière a-t-elle une place critique dans le projet ? On ne s’attardera pas, par exemple, sur une librairie de génération d’un UUID, alors que sans aucun doute, une analyse poussée sera réalisée pour choisir le système de gestion de base de données. Effectivement ce dernier, qui servira au stockage des informations traitées par notre application est une pièce maîtresse. Utiliseriez-vous un moteur de base de données totalement inconnu pour un point aussi critique ?
Déterminer le risque d’utiliser tel ou tel module, vous poussera certainement à faire une analyse plus ou moins approfondie de la qualité du composant que vous allez mettre en place. Dans un domaine où nous utilisons de plus en plus d’outils et modules open source, n’importe quel développeur peut explorer le code pour en vérifier sa robustesse. Ce dernier respecte-t-il les “bonnes pratiques” de développement ? Est-il maintenable ? Possède-t-il des tests unitaires et/ou fonctionnels ? Autant de questions qui permettent de dresser un bilan de la qualité du projet. Une dépendance de qualité permettra de garantir son bon fonctionnement sur le long terme et facilitera d’éventuelles interventions au sein de cette dernière.
Un autre point à prendre en compte est l’activité autour du composant auquel on s’intéresse. Peut-être s’agit-il d’un projet de qualité, mais dont le développement n’est plus maintenu. Dans ce cas-là que se passe-t-il si vous rencontrez un problème lors de son utilisation ? Est-ce que l’équipe de développement pourra corriger ce dernier ? Si la réponse à cette question est “non”, il sera peut-être nécessaire de travailler sur votre propre version du module ou éventuellement d’en choisir un autre.
Le dernier point qu’il est intéressant d’analyser est la communauté qui gravite autour de la dépendance étudiée. Plus la communauté sera grande et plus vous pourrez profiter de retours d’expériences, d’aide et de conseils autour des questions et des différentes problématiques que vous pourrez rencontrer. Il faudra sur ce point, faire attention à la notion d’effet de mode. Il peut être préférable dans certains cas d’utiliser des outils éprouvés et pertinents pour l’utilisation que vous souhaitez en avoir. Focalisez-vous sur votre cas d’utilisation et ne choisissez pas spécialement des solutions “passe-partout”.
Le choix d’un module dépend de nombreux critères qui ne seront pas évalués de la même manière en fonction de l’impact dans le projet. Dans tous les cas, ce n’est pas une décision à prendre à la légère car cette dernière vous suivra durant toute la durée de vie du code de l’application. Pour limiter l’impact d’une dépendance et faciliter son remplacement, il est intéressant d’abstraire le côté technique de son utilisation au sein de classes orientées métier.