Coder est un plaisir pour beaucoup de développeurs, et en tant que développeur, on ne s'ennuie jamais : chaque année, de nombreux nouveaux langages, technologies, frameworks et bibliothèques apparaissent.
Les développeurs occupent une place centrale dans tout projet ; leur contribution est cruciale, et disposer de bons développeurs augmente considérablement les chances de réussite d'un projet.
Mais qui mérite le titre de bon développeur ? Quelqu'un qui écrit beaucoup de code en peu de temps ?
Tout développeur sait que plus de code implique :
- plus de bogues.
- plus de code smells.
- plus de support.
- plus de documentation.
Chaque ligne de code peut introduire un problème dans la base de code et augmenter sa dette technique. Pour réduire le nombre de bogues, il est généralement préférable d'avoir moins de code.
Prenons l'exemple de l'algorithme du tri à bulles : certains développeurs auront besoin de 50 lignes de code parce qu'ils l'implémentent à partir de zéro, tandis que d'autres n'auront besoin que de deux lignes parce qu'ils utilisent une bibliothèque bien connue pour faire le travail.
Quelle est la grande différence entre coder à partir de zéro et utiliser une bibliothèque mature et reconnue ?
Une bibliothèque mature présente les avantages suivants :
- Utilisée par des milliers de développeurs.
- Très bien testée.
- Une évolution continue et la compatibilité avec de nombreux systèmes d'exploitation sont assurées.
- Bien optimisée.
- Bien documentée.
- Maintenue.
Un bon développeur devrait être à l'aise pour rechercher des solutions existantes. Avant d'implémenter quelque chose de complexe, vérifiez si une bibliothèque reconnue fait déjà le travail. En C++, comme dans d'autres langages, il existe de nombreuses bibliothèques intéressantes comme STL, Boost, POCO…
D'après mon expérience de développeur, un bon développeur est quelqu'un qui écrit moins de code et travaille efficacement. Ce n'est pas nécessairement un gourou technique aux compétences exceptionnelles, mais plutôt quelqu'un qui sait rechercher et choisir la bonne bibliothèque pour le travail. Parfois, les gourous techniques ont tendance à coder à partir de zéro, ce qui peut nuire à la qualité de la base de code.
Mais comment choisir la bonne bibliothèque ?
Choisir une bibliothèque logicielle n'est pas toujours une tâche facile, surtout si de nombreuses bibliothèques concurrentes existent pour un besoin spécifique. De nombreux facteurs peuvent influencer le choix d'une bibliothèque par une équipe de développement ; en voici quelques-uns :
1. La licence
La licence de la bibliothèque est la première chose à vérifier. Il est très important de s'assurer que la licence est compatible avec la façon dont vous comptez utiliser la bibliothèque dans votre projet, avant d'aller plus loin et d'explorer ses capacités.
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
2. La bibliothèque répond-elle à vos besoins ?
Cela peut sembler évident, mais combien de développeurs réalisent un petit proof of concept pour vérifier que la bibliothèque répond à tous leurs besoins ? Il arrive que l'on découvre très tôt que la bibliothèque ne convient pas, pour une raison ou une autre.
3. La communauté est active
De nombreux problèmes peuvent survenir lors de l'utilisation d'une bibliothèque ; si sa communauté est active, il sera très facile de trouver rapidement une solution.
4. Quelle est la tendance d'adoption de la bibliothèque ?
Il est intéressant de savoir si la bibliothèque gagne en popularité ou non. Pour cela, vous pouvez utiliser Google Trends et découvrir l'évolution de la bibliothèque au fil des années.
Voici, par exemple, la tendance pour l'API d3.js :
5. La bibliothèque a-t-elle connu des ruptures de compatibilité dans le passé ?
Avant d'adopter une bibliothèque, prenez quelques minutes pour rechercher sur le web « LibraryName breaking changes » afin de vérifier si une version spécifique a introduit une rupture de compatibilité.
Cela peut vous aider pour les raisons suivantes :
- Éviter d'utiliser des exemples de la bibliothèque issus d'anciennes versions.
- Une rupture de compatibilité majeure peut être un signal d'alarme. Elle peut indiquer que la compatibilité avec les utilisateurs existants n'est pas une priorité, et que des changements similaires pourraient se reproduire dans les versions futures.
6. Les contraintes et limitations de la bibliothèque
Parfois, une bibliothèque est excellente pour un besoin spécifique, mais présente une limitation critique qui vous empêche de l'utiliser.
Prenons l'exemple de l'API Google Chart : c'est une bibliothèque de graphiques très utile. Cependant, elle a une limitation agaçante — l'utilisateur doit disposer d'une connexion Internet.
Avant de choisir une bibliothèque, assurez-vous qu'aucune de ses limitations ne pourrait affecter votre cas d'usage. Une simple recherche web « LibraryName limitations » peut aider.
7. La documentation
Une bibliothèque bien documentée vous aidera considérablement lors de son utilisation, surtout si elle contient de nombreux exemples d'utilisation.
8. Les performances sont-elles importantes dans votre utilisation de la bibliothèque ?
Si vous prévoyez d'utiliser une bibliothèque dans un contexte où les performances sont très importantes, ne vous fiez pas uniquement aux benchmarks trouvés sur le web. Il est préférable de construire un proof of concept avec vos contraintes spécifiques pour avoir une idée plus précise des performances de la bibliothèque dans votre contexte.
9. Votre application est-elle multiplateforme ?
Si votre application doit fonctionner sur plusieurs plateformes, ne testez pas principalement sur une seule plateforme en attendant la fin du développement pour tester les autres.
Testez toujours dès le début sur toutes les plateformes ciblées ; certaines bibliothèques sont très bien implémentées pour un OS et très mal implémentées pour les autres.
10. Existe-t-il une autre alternative sérieuse à la bibliothèque choisie, et vous avez des doutes ?
Dans certains cas, vous pouvez trouver deux excellentes bibliothèques qui répondent aux mêmes besoins et avoir du mal à choisir entre elles. Dans ce cas, ne laissez jamais votre code être fortement couplé à la bibliothèque. Préférez utiliser des wrappers et le pattern façade pour isoler son utilisation.
Bien sûr, de nombreux autres facteurs peuvent influencer votre choix. Pour minimiser le risque d'adopter une bibliothèque qui devra peut-être être remplacée plus tard, il est de bonne pratique d'isoler son utilisation à quelques endroits du code en utilisant des wrappers et des façades.
Essayez d'évaluer le couplage de votre application avec toutes les bibliothèques utilisées, identifiez celles qui sont fortement couplées à votre code, et essayez progressivement, dans la mesure du possible, de découpler leur utilisation.
De nombreux outils peuvent être utilisés pour détecter facilement le couplage des bibliothèques externes. On peut citer JDepend et JArchitect pour Java, CppDepend pour C/C++ et NDepend pour .NET.