La propreté du code, une responsabilité collective

La dégradation du code

Lorsqu’on travaille seul (ou tout au plus en binôme) sur un projet, il est beaucoup plus facile d’appliquer les règles du clean code. D’autant plus si il s’agit d’un nouveau projet, dont le point de départ est, par définition, propre. Etant seul à faire évoluer le code, on est seul responsable de sa propreté, et on peut le maintenir à un niveau de propreté qui nous convient, qui nous permet de le faire évoluer de façon satisfaisante.

Le fait de créer un nouveau projet et d’être seul responsable de sa base de code reste néanmoins une situation privilégiée dans le développement logiciel. Dans la plupart des cas, il faut composer avec les contraintes suivantes :

  • la base de code est partagée entre plusieurs développeurs, de différents niveaux et expérience.
  • la base de code est souvent vieille de plusieurs années, et dans un état dont la propreté laisse à désirer.

L’application des principes du clean code se complique alors, pour les raisons suivantes :

  • certains développeurs ne sont pas réceptifs à la propreté du code, et ne voient pas ce que ça peut leur apporter, à part de perdre encore plus de temps et de fournir plus d’efforts.
  • le code peut être tellement encrassé que ça en devient décourageant, voire démotivant; dans ce cas, pourquoi faire des efforts qui ne vont pas se voir ?

Cette réalité, bien que courante, ne doit pas nous écraser comme une fatalité. Attaquons nous d’abord à l’idée reçue qui voudrait que la réalisation de code propre nécessite beaucoup plus d’efforts. Ce qui revient à dire que coder proprement est un effort en soi.

C’est peut-être vrai au départ, réfléchir à la propreté du code, réécrire quelques lignes, faire des petits refactorings prend un peu plus de temps. Mais ce temps investi est loin d’être perdu, et permet de garder l’esprit clair sur que l’on fait. De plus, on ressent progressivement la satisfaction du travail bien fait, et une confiance en soi liée à une meilleure maîtrise du code produit.

Avec le temps et l’expérience, on arrive à produire du code propre sans même y penser, parce qu’on a acquis certains réflexes. On repère même très facilement le code qui est de mauvaise qualité, et qui pique les yeux. Il faut alors lutter contre l’envie de tout réécrire, et se limiter à de petites améliorations.

L’autre problème majeur est posé par l’état de la base de code, et son encrassement. Il est vrai que nous n’aimons pas évoluer dans un environnement sale, de nombreuses situations de la vie courante l’illustrent assez facilement :

  • l’état des transports en communs : le manque de propreté fait qu’il est tentant de jeter ses ordures par terre, la saleté des banquettes incite à s’en servir comme repose-pieds.
  • la vie en copropriété : si le voisinage est bruyant, on n’est pas incité à limiter sa propre pollutions sonore.
  • on pourrait trouver de nombreux autres exemples : la pollution de l’environnement, les toilettes collectives, les incivilités, etc.

De tous ces exemples il ressort, de façon évidente, qu’on a du mal à se comporter proprement dans un environnement sale. Ce qui ressort de façon moins immédiate, c’est le fait que dans un environnement assez dégradé, une petite dégradation de plus n’est pas visible de façon évidente et ne change pas sensiblement la donne. Et pourtant, c’est une accumulation de petites dégradations de cette nature, étalée sur une échelle de temps relativement vaste, qui a conduit à l’état dégradé que l’on constate. Du coup, tous les auteurs de ces dégradations, aussi minimes et tardives soient-elles, sont collectivement responsables de l’état dégradé global. Seulement, quand on est l’auteur d’une petite dégradation, on ne se rend pas compte de son impact sur l’environnement pour ces raisons, soit par négligence, soit parce que l’environnement est trop dégradé pour que nous prenions conscience de la dégradation supplémentaire engendrée.

A l’inverse, dans un environnement propre, on pourrait avoir tendance à corriger la moindre dégradation (par exemple ramasser un papier tombé par terre et le mettre dans une poubelle), pour les raisons suivantes :

  • la dégradation est facilement perceptible.
  • l’effort de nettoyage est dérisoire.
  • le gain est important puisqu’il permet de maintenir l’environnement propre.

Bien entendu, ces points s’appliquent au développement logiciel. Dès lors, de quelles pistes disposons-nous pour faire évoluer les choses ?

Quelques pistes d’amélioration

La discipline personnelle

On trouve, en premier lieu, la discipline personnelle : il est nécessaire de s’astreindre à faire du code propre, quoi qu’il arrive. La difficulté consiste à déterminer l’ampleur de l’effort. L’emploi de la règle du boy scout, consistant à laisser la base de code dans un état un peu meilleur que ce qu’on a trouvé, est un bon guide. On veille alors :

  • à n’écrire que des lignes de code de bonne qualité.
  • à effectuer quelques améliorations sur le code environnant, qui ne coûtent pas cher, ne posent aucun risque, et améliorent la lisibilité et la qualité du code; il peut s’agir simplement d’un renommage de variable, d’une extraction de méthode ou même de reformatage de code.

On pourrait arguer que, dans le cas de bases de code suffisamment dégradées, c’est loin d’être facile. C’est vrai, mais cela ne doit pas servir d’excuse. l’Amélioration du code, même si elle est perçue comme un combat contre la base de code, est avant tout un combat contre soi-même : contre la résignation, la paresse, la facilité immédiate, la procrastination. C’est une discipline de chaque instant mais qui procure une immense satisfaction.

L’outillage

En deuxième lieu, les outils ont toute leur importance. Ils proposent des fonctionnalités permettant de :

  • d’écrire facilement du code propre.
  • de détecter les violations potentielles de propreté du code.
  • de transformer du code sale en code propre.

Des IDE appropriés (IntelliJ, Eclipse) et configurés efficacement (règles de détection d’erreurs et de warnings, règles de formatage) permettent de remplir ces trois fonctions, du moins sur l’aspect solo du développement. Dans la mesure du possible, cet outillage devrait être partagé : il est courant de versionner les fichiers de configuration des IDE.

On trouve ensuite les outils d’analyse de la base de code (tels que Sonar), dont le rôle est de :

  • donner une idée de l’étendue des dégâts en fournissant des métriques.
  • détecter toute dégradation perpétrée sur la base de code.
  • alerter de façon quasi-immédiate ce qui permet de se reprendre immédiatement.

Avec ce type d’outil, notamment lorsqu’il est inséré dans la chaîne d’intégration continue, tout auteur d’une « incivilité » sur le code déclenche un signal d’alarme qui alerte toute l’équipe, l’invitant à corriger le problème sans délai.

L’adhésion de l’équipe

Il s’agit probablement du point le plus difficile, parce qu’il s’agit :

  • de convaincre des bienfaits du clean code,
  • d’en transmettre les techniques et les bonnes pratiques,
  • et surtout de démontrer que c’est applicable sur la base de code existante.

On arrivera d’autant mieux à convaincre ses coéquipiers si on a déjà soi-même appliqué le clean code, et qu’on dispose ainsi d’exemples dans la base de code permettant d’illustrer le propos. Il est important de montrer la voie.

Un des meilleurs moyens d’y parvenir reste toutefois de profiter des sessions de pair-programming (si elles sont rares, il faut chercher à les provoquer) pour en distiller les principes. On peut ainsi inciter son coéquipier à s’exprimer sur le code peu lisible, et lui montrer qu’avec un effort minime et en utilisant des techniques simples on a rendu le code plus lisible. Enfin, on peut insister sur la notion de petites victoires, du pas grand chose qui améliore le code pour tout le monde. C’est aussi un bon moyen de faire la promotion des bienfaits du pair-programming.
A l’issue de ce type de sessions, il m’est arrivé d’obtenir des retours de coéquipiers qui avaient eu la sensation de faire du bon travail, malgré l’état délabré de la base de code.

L’idée est qu’à terme ces bonnes pratiques entrent dans la culture de l’équipe. La discipline personnelle reste bien sûr primordiale, ainsi que les outils, qui permettent de se remettre rapidement dans le droit chemin.

Un des bénéfices principaux est que la perception de l’équipe vis-à-vis de la base de code se trouve modifiée : le travail s’y fait avec davantage de plaisir. Les avis sont beaucoup moins négatifs, le plus important n’étant pas l’état de la base de code, mais ce qu’on peut en faire, ce qui ouvre certaines perspectives.

 

Laisser un commentaire