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…

2 réflexions au sujet de « Le principe de précaution »

  1. Victor

    Bonjour,

    La Fondation Jean-Jaurès et la Fondation pour l’innovation politique organisent un colloque sur le principe de précaution le mardi 12 avril prochain.
 Nous sommes heureux de vous convier à cette manifestion qui se tiendra à l’Assemblée nationale.

    Par ailleurs, les deux fondations se sont également associées pour publier une note de Nicolas de Sadeleer sur « le principe de précaution dans le monde » que vous pouvez retrouver ici : http://www.jean-jaures.org/Publications/Les-notes/Le-principe-de-precaution-dans-le-monde
    Vous trouverez davantage d’informations concernant le colloque ici : http://www.jean-jaures.org/Manifestations/Les-colloques/La-precaution-par-principe/

    N’hésitez pas à diffuser l’information autour de vous.

    Je vous remercie.

    Victor

    Répondre
  2. Yannick

    La réponse à un excès n’est pas l’excès opposé.
    http://en.wikipedia.org/wiki/Interface_segregation_principle

    Le problème avec le refactoring « massif » (changements d’interfaces, collaboration de classes, etc …) et que cela induit *forcément* des bugs (test unitaire ou pas). Pour limiter les bugs il faut éviter à modifier du code qui marche.
    http://en.wikipedia.org/wiki/Open/closed_principle

    L’objectif n’est pas de créer de l’interface/classe abstraite a tour de bras, mais à identifier les bons. « Identifier les bons » requiert de l’expérience et permet de fixer le curseur entre coût et maintenabilité. Je dirais que plus il y a d’incertitude, plus il faut abstraire. Le YAGNI consiste alors a n’avoir qu’une implémentation (une seule feature). Qui peut dire avec certitude à un instant T que tel ou tel abstraction servira, ou non, au cours du cycle de vie complet du soft ? Idéalement il faudrait abstraite toutes les problématiques sous forme d’API/contrat (type Java JPA, JTA, JMS, …) pour pouvoir changer d’implémentation de manière isolé avec le minimum d’impact. Mais les coûts s’envolent. Cela requiert du temps et de l’expérience pour positionner le curseur au bon endroit.

    Le principe KISS quand a lui s’explique au travers de l’effort demandé pour fixer un bug/rajouter une feature. Si toutes les classes communiquent avec toutes les autres, vous avez une implem’ « straightforward » mais pas KISS puisque le développeur devra comprendre l’intégralité des classes, leur responsabilités et leur interaction pour pouvoir intervenir. C’est KISS  a l’écriture mais pas à la lecture/compréhension/modification. De ce point de vue là, Perl est KISS compliant 🙂

    Pour moi, KISS et YAGNI sont trop souvent mal interprété/compris. C’est à dire qu’ils sont souvent interprété de façon a permettre au « chef de projet » d’exiger l’implem de la  feature X ou Y le plus rapidement possible avec toute la légitimité acquise par ces symboles dans le milieu technique.

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *