“Quelqu’un peut il m’expliquer pourquoi il arrive fréquemment, dans une équipe projet, d’avoir une ou deux personnes qui ne peuvent écrire une classe sans écrire, systématiquement, une ou plusieurs interfaces ou classes abstraites qui, en fin de projet, ne sont finalement implémentées que par une classe voir pas du tout ?”
Voilà en substance un mail qui a lancé un débat intéressant entre collègues. Et je dois dire que je suis d’accord avec ce constat et qu’il est vrai que j’ai parfois l’impression que certains développeurs pensent que savoir développer proprement et professionnellement signifie devoir implémenter 9879798 interfaces et classes abstraites et ajouter 98770754 niveaux d’abstractions. Après tout, rajouter de l’abstraction est le premier réflexe que l’on peut avoir lorsque l’on essaie d’atteindre l’objectif premier de tout développeur qui se respecte :
Ecrire du code maintenable
Cet objectif est en effet primordial afin de réduire le coût de développement (et de maintenance) d’un projet. Mais il mène parfois vers le travers évoqué ci-dessus.
Cette mauvaise habitude appelée “le syndrome du “ocazou”” par David, se rapproche beaucoup du principe de précaution dont on parle beaucoup en ce moment. Adapté au développement logiciel celui-ci pourrait se traduire par :
“ l'absence de certitudes, compte tenu des connaissances techniques du moment, ne doit pas retarder l'adoption de mesures effectives et proportionnées visant à prévenir un risque de dommages graves et irréversibles au projet de développement à un coût économiquement acceptable ”
Seul problème avec ce genre de principe de précaution, il est très souvent difficile d’arriver à proportionner correctement son action afin d’éviter les problèmes par la suite. L’actualité récente l’a montré, le principe de précaution incite souvent à exagérer la menace, et a dans quasi tous les cas une certaine faculté à faire exploser les coûts pour un résultat… souvent peu mesurable.
En réalité, la maintenabilité doit certes être basé sur du code propre et bien structuré, mais il repose également sur deux principes fondamentaux :
- Le principe KISS (Keep It Simple and Stupid) : Plus un code est simple et plus il sera facilement compréhensible et maintenable. Ajouter de la complexité en ajoutant des niveaux d’abstractions inutiles ne fait… qu’ajouter de la complexité.
- Le principe YAGNI (You aren’t going to need it) : Ce principe indique qu’il ne faut pas ajouter des fonctionnalités ou du code tant que l’on n’en a pas réellement besoin.
Ces deux principes sont d’autant plus valables que nous avons à présent des outils efficaces (comme ReSharper) permettant de refactoriser intelligemment son code afin de faire évoluer son architecture quand on a en besoin. Inutile donc de rajouter de la complexité en prévision du futur, il ne sera pas trop tard pour le faire par la suite…