Comment bien choisir sa bibliothèque Java

Comment choisir une bibliothèque de logiciels

Voici les sept critères principaux à prendre en compte lorsque vous choisissez une bibliothèque de logiciels pour votre projet :

1. Fonction et forme
2. Documentation
3. Licence
4. Quantité d'effort économisé
5. Champ d'application
6. Support
7. Taille du déploiement

L'optimisation du moteur de recherche pourrait constituer un huitième critère. Mais s'il est vital pour les auteurs de bibliothèques, il reste négligeable pour les utilisateurs.

Examinons ces points un par un.

Fonction et forme

La première question à se poser concernant la fonction de la bibliothèque est la suivante : « Cette bibliothèque fonctionne-t-elle comme prévu ? » Demandez-vous ensuite si elle est adaptée à vos besoins. Autrement dit, assurez-vous que la bibliothèque remplit sa fonction d'une manière qui réponde à vos besoins.

Si votre objectif est d'analyser des dates de forme libre (par exemple, l'entrée « demain » doit renvoyer la classe LocalDate correspondant à la date du lendemain), il existe une règle simple de type pass/fail. Trouvez une bibliothèque qui, à partir d'une chaîne en entrée (par exemple, « demain »), renvoie une donnée pouvant être utilisée comme date locale (LocalDate). Si la bibliothèque ne répond pas à vos exigences élémentaires, vous en trouverez certainement une plus adaptée.

Il importe également de prendre en compte le niveau d'effort. Imaginez que la bibliothèque mentionnée plus haut convertisse « demain » en chaîne de dates plutôt qu'en date, mais que cette chaîne puisse être analysée de façon systématique par la classe LocalDate. Cette solution peut être acceptable, mais elle demande davantage de travail que si la bibliothèque renvoyait directement une date.

En somme, si votre bibliothèque renvoie un élément que vous pouvez convertir dans le type de données qui vous intéresse (par exemple, une chaîne analysable par LocalDate plutôt qu'une classe LocalDate), vous pouvez la conserver.

En revanche, si l'écart entre ce que vous attendez et ce que vous obtenez est plus important, cherchez une autre bibliothèque, ou corrigez celle-ci et envoyez une pull request à son auteur.

Documentation

La documentation disponible pour une bibliothèque donnée représente un autre aspect à prendre en compte, étroitement lié à la fonction et à la forme.

Il est difficile de qualifier le « niveau de qualité approprié » d'une documentation, car cela dépend de la complexité des tâches de la bibliothèque. En effet, si celle-ci convertit « demain » en date, la documentation correspondante indiquera ni plus ni moins « Voici comment installer la bibliothèque ».

En revanche, si vous travaillez avec le projet Spring Data, vous aurez besoin d'un manuel exhaustif, voire d'un livre. Le sujet est crucial, et les utilisateurs doivent comprendre de nombreux cas particuliers.

Vérifiez également comment la documentation a été rédigée et à qui elle s'adresse. Elle peut en effet s'adresser aux développeurs de la bibliothèque et porter principalement sur les aspects internes et les notations Big O concernant la complexité de la structure de données. Ces considérations ne sont pas dénuées d'intérêt, mais les utilisateurs souhaitent avant tout savoir comment utiliser la bibliothèque, et non comment la développer.

Pour conclure, si la documentation ne vous permet pas d'utiliser facilement une bibliothèque, cherchez-en une autre qui, en plus de répondre à vos besoins, vous permette de l'utiliser de façon appropriée.

Licence

La licence de la bibliothèque constitue un autre point très important. Une fois de plus, la définition d'une « bonne » licence est très relative. Certaines licences open source sont communément jugées « correctes », ce qui ne signifie pas qu'elles respectent vos obligations légales. Je ne suis pas juriste - je m'appuie simplement sur le sens commun - mais dans le monde réel, ce n'est tout simplement pas suffisant.

Si la licence des bibliothèques est un facteur important pour vous et votre entreprise, consultez un avocat. L'argument de défense « mais j'ai lu dans un article... » ne sera pas recevable devant un juge.

La licence des bibliothèques que vous choisissez doit être suffisamment permissive pour les circonstances en question. C'est généralement le cas des licences Apache v2.0, BSD et MIT, qui répondent à la plupart des besoins. D'autres licences peuvent être appropriées, mais présenteront davantage de risques. Citons la licence LGPL, qui est généralement acceptable, mais je sais par expérience que les avocats ont tendance à tiquer à son évocation. Il faut dire que c'est en principe une licence virale (néfaste), même si le modèle de déploiement de Java atténue quelque peu sa nature pernicieuse.

Je le répète, si vous avez des questions sur les modèles de licence, n'hésitez pas à vous adresser à un avocat.

Quantité d'effort économisé

Si j'ai cité l'exemple de l'analyse des dates relatives, c'est en partie parce que les efforts déployés pour répondre à une demande ne sont pas quantifiables. Comment analyser « demain » en tant que date du lendemain ? Quelle serait la quantité de travail nécessaire pour en faire une exigence ?

Comparez le niveau d'effort minimal requis pour satisfaire une exigence à l'effort nécessaire pour trouver une bibliothèque où quelqu'un d'autre a déjà fait ce travail. La recherche d'une bibliothèque est rapide si vous connaissez les termes de recherche communs généralement utilisés par leurs auteurs. Toutefois, vous devez également vérifier l'API afin de déterminer si elle remplit ses engagements, et vous assurer que la licence de la bibliothèque convient à votre usage.

La plupart des gens se contentent de rechercher une bibliothèque et de l'utiliser, puis d'évaluer les autres paramètres après coup pour savoir s'ils sont adaptés. Demandez-vous s'il serait plus difficile de mettre en œuvre vous-même ce dont vous avez besoin. Si vous voulez simplement traduire « demain » en date relative à aujourd'hui, pourquoi ne pas avoir recours à une simple instruction « if » et vérifier le terme ?

Il ne s'agit pas de minimiser l'utilité des bibliothèques dont l'application est plus générale que ce simple cas d'usage. Si vous voulez tout simplement inscrire un objet dans une base de données, demandez-vous si Hibernate ou Spring Data vous coûtent plus qu'ils ne vous apportent.

Champ d'application

Le champ d'application décrit dans quelle mesure la finalité d'une bibliothèque correspond à vos besoins. Par exemple, si vous avez besoin d'un cache, la bibliothèque Guava de Google en propose un de qualité. Cependant, le champ d'application de Guava est loin de se limiter au cache : vous trouverez une multitude de fonctionnalités dans une même bibliothèque, telles que des collections, des graphes, des utilitaires de simultanéité ou de chaînes, et bien plus. Et elles ont certainement été éprouvées sur le terrain. Je considère Guava comme l'une des rares bibliothèques réellement utiles que j'inclus par défaut dans mes projets personnels.

Cela dit, elle n'est pas forcément adaptée à tous les projets malgré sa multitude de fonctionnalités. Je la connais suffisamment pour être capable de créer une structure sans me poser de questions si j'ai besoin d'un cache, ce qui me fait gagner un temps considérable sur le long terme.

Mais cela ne justifie pas les approches « cargoïstes » de la programmation. Réfléchissez à l'efficacité des fonctions d'une bibliothèque par rapport à vos besoins. Même si Guava me permet de créer ce dont j'ai besoin sans me poser trop de questions, il peut exister d'autres solutions plus adaptées à un projet particulier.

Support

Demandez-vous également quels moyens propose une bibliothèque lorsque vous avez besoin d'aide. Examinez plusieurs options de support pour une bibliothèque donnée :

• La bibliothèque a pu être créée par une entreprise, comme c'est le cas de Spring ou Hibernate.
• Vous pouvez également vous reporter à la source du projet et, par exemple, demander de l'aide sur une page Issues de GitHub. Ou encore envisager un système de suivi de bugs.
• Certaines entreprises proposent un service de support, mais ce faisant entre en compétition avec les concepteurs du projet. En effet, leurs employés possèdent un savoir-faire, mais ne font pas partie des équipes de maintenance de ces projets.
• Une communauté d'utilisateurs partageant des intérêts communs permet d'obtenir de l'aide en temps réel par le biais de plateformes de communication telles que Discord, Slack ou IRC.
• Sur les réseaux sociaux Stack Overflow, Reddit ou Quora, pour ne citer qu'eux, vous pouvez laisser un message et espérer que quelqu'un finira par vous répondre.

Sans ce type de solution, il vous faudra travailler sans aucun soutien et ce sera à vous de trouver ce dont vous avez besoin. Un rapport de bugs générera peut-être une réponse, mais dans les faits, vous êtes responsable de votre utilisation du code si les autres réseaux d'assistance ne sont pas disponibles ou sont inefficaces.

En tout état de cause, une bibliothèque disposant d'une communauté active et dynamique disposée à offrir son aide présente un avantage non négligeable par rapport aux autres.

Taille du déploiement

La taille de déploiement fait référence à la quantité réelle d'espace disque occupée par le déploiement d'une bibliothèque et de ses dépendances transitives. Si la bibliothèque fait 100 Ko, mais qu'elle nécessite plusieurs dépendances transitives telles que Spring, elle occupera en réalité l'équivalent de Spring en plus des 100 Ko.

En Java, cette question est relativement anodine, car la taille de la JVM déployée a de fortes chances d'être supérieure à celle des dépendances. Cependant, si vous effectuez le déploiement dans des environnements aux ressources limitées, par exemple dans des clusters de serveurs disposant d'un espace disque restreint ou dans des appareils embarqués (comme c'est mon cas), la taille du déploiement est un facteur à prendre en compte.

Bien entendu, cette liste de critères n'est ni exhaustive ni prescriptive. A chaque projet et chaque propriétaire de projet correspondent des objectifs et des mesures spécifiques qui déterminent l'importance de chacun de ces aspects. Utilisez cette liste comme point de départ pour déterminer dans quelle mesure chaque facteur doit être pris en compte.

L’auteur, Joseph B. Ottinger, a occupé des postes à responsabilité dans le domaine de l'ingénierie logicielle et de la gestion de projets, dans divers langages, architectures et mises en œuvre. Il est actuellement développeur sénior chez Delos, un fabricant de wearables médicaux.