Archives par étiquette : Architecture

Le principe de précaution

“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…