En effet, dans un contexte agile, afin de pouvoir pivoter afin de résoudre un problème avec un maximum d’efficacité, il y a des prérequis humains et techniques indispensables qui doivent avoir été mis en place en amont.
Humainement parlant, la communication au sein de l’équipe et de l’entreprise qui l’accueille doit être efficace, l’équipe doit disposer rapidement des moyens nécessaires pour atteindre ses objectifs, les responsabilités doivent y être partagées, les rôles clairement déterminés, et elle doit exploiter correctement le feedback qui doit bien évidemment être collecté afin que l’amélioration continue devienne une réalité, et cette liste est loin d’être exhaustive.
Et techniquement parlant, les développeurs doivent être en mesure de faire évoluer leur code rapidement, de faire des expérimentations et de revenir en arrière à moindre coût, tout en garantissant qu’il répond toujours aux besoins du client.
En clair, l’équipe doit disposer des outils et des moyens nécessaires non pas pour anticiper un avenir par nature incertain, mais pour pouvoir s’y adapter.
Or, la production d’un code suffisamment générique est à ma connaissance le seul moyen dont dispose un développeur pour que son code puisse être adapté au changement par lui-même ou quelqu’un d’autre.
Écrire du code générique n’est donc pas à mon avis une mauvaise pratique, bien au contraire, d’autant que la programmation orientée objet a précisément été conçue pour cela : permettre la création à moindre coût à tout point de vue d’un code facile à maintenir, à faire évoluer et réutilisable.
Par conséquent, écrire du code générique ne devrait pas être un problème pour un développeur pratiquant la programmation orientée objet (je ne me prononce pas pour les autres paradigmes…), puisqu’il dispose du meilleur outil disponible à ce jour pour cela.
Alors pourquoi est-ce que c’est considéré comme une mauvaise pratique ? Ou, formulé autrement, comment est-il possible qu’écrire du code générique à l’aide d’un paradigme censé le permettre simplement et facilement semble être une tâche insurmontable, la chose à ne surtout pas faire ?
Le paradoxe semble insurmontable, mais j’ai une explication qui risque de faire mal à votre ego si vous pratiquez la programmation orientée objet : la plupart des développeurs ne savent pas utiliser ce paradigme correctement, ce qui les empêche d’en exploiter le plein potentiel !
En effet, nous faisons pour la plupart d’entre nous de la programmation procédurale déguisée en programmation orientée objet.
Au lieu de faire communiquer ensemble des objets, nous manipulons des structures de données qui se font passer pour des objets, à grand renfort de conditions qui nous permettent de prendre des décisions en fonction des données contenues dans ces structures.
Et le plus paradoxal n’est pas que nous ne parvenions pas à utiliser le paradigme de la programmation orientée objet pour concevoir du code générique alors qu’il a été conçu pour cela.
Le plus paradoxal est que nous savons que nous ne l’utilisons pas correctement, que nous cherchons des solutions pour le faire, mais que ces solutions ne sont que des pis-aller et des recettes de cuisine.
Ainsi, nous dressons des catalogues de patrons de conception censés nous permettre de répondre correctement à la grande majorité des problématiques que nous rencontrons et nous créons des acronymes tels que SOLID pour évangéliser des bonnes pratiques censées nous permettre de comprendre ce qu’est un « bon » code objet, nous lançons des mouvements tels que le « if less programming » ou le « east oriented programming », nous répétons à l’envi qu’il faut privilégier la composition et restreindre fortement l’utilisation de l’héritage, nous expliquons ce qu’est l’encapsulation ou le polymorphisme, nous crachons sur les « getter/setter », etc.
Nous disons beaucoup… et nous faisons finalement peu (un peu comme pour le climat, d’ailleurs…).
Mais rarement nous cherchons à comprendre pourquoi il est nécessaire de faire tout cela, rarement nous cherchons à comprendre ce qu’est la programmation orientée objet, rarement nous remettons fondamentalement en cause nos pratiques et nos connaissances.
À décharge, il faut bien dire qu’il n’est pas simple pour un développeur de remettre en cause l’ensemble de ses connaissances, surtout lorsque tout le monde fait de même, et je suis bien placé pour le savoir, puisque je l’ai fait il y a 5 ans.
Or, ce n’est pas parce que tout le monde fait la même chose de la même façon que c’est forcément ce qu’il faut faire pour obtenir le meilleur résultat.
De plus, les langages de programmation « orientés objet » n’aident pas, car ils sont pour la plupart basés sur des habitudes de syntaxe et des algorithmes issus du paradigme procédural.
Pourtant, pour celui qui a le courage d’entreprendre cette démarche et qui prend le temps de le faire, il devient possible d’écrire du code générique naturellement, ainsi que les tests associés.
Car vous pouvez très bien remplacer le concept de code générique par celui des tests dans le billet de Damien sans en changer le sens fondamental.
En effet, si je résume son article en une phrase, elle pourrait être :
Écrire du code générique, tout le monde voudrait le faire, mais ceux qui essayent ne savent pas le faire correctement, ce qui met la merde dans les projets, donc il ne faut pas écrire de code générique.
Maintenant, est-ce que vous voyez une grosse différence avec cela :
Écrire des tests, tout le monde voudrait le faire, mais ceux qui essayent ne savent pas le faire correctement, ce qui met la merde dans les projets, donc il ne faut pas écrire de tests.
J’avoue caricaturer quelque peu, mais je trouve que c’est tout de même assez proche de la réalité.
Et c’est la raison pour laquelle aujourd’hui, les tests sont l’exception et non la règle dans la plupart des projets informatiques et que des propositions commerciales sont faites avec à peine 1 % du budget alloué aux tests (quand il y a un budget alloué pour eux), avec tout ce que cela implique en termes d’insatisfaction, aussi bien chez les développeurs que chez les clients !
Et l’un dans l’autre, c’est aussi pour cela que nous avons des applications très gourmandes en mémoire par rapport aux services qu’elles rendent ce qui provoque la rédaction de ce type de billet d’humeur.
Alors la question est (un peu comme pour le climat, d’ailleurs…) : qu’allez-vous faire pour que cela change ?
Continuer à mal utiliser vos outils, ou bien faire en sorte de les utiliser correctement pour produire du code de qualité ?
