Maintenance de code

Le composant DoSomethingAwesome date de 8 mois, ça aurait été pas mal de le supprimer une fois qu'il n'était plus utilisé

Pour le coup c'est du très très (très) classique. Que ce soit du commentaire, du code mort, voire du code qui tourne mais qui n'apporte rien, on en retrouve toujours dans une codebase legacy (comprendre avec du code de plus d'une semaine).

C'est tout l'enjeu de la maintenance, prendre le temps du refacto, de simplifier les choses (algo, structure de données, organisation des modules, etc.).

Prendre le temps ne veut pas dire ouvrir une branche de refacto qu'on laisse ouverte 3 mois et qui finit par ne plus être fusionnable. Prendre le temps, c'est surtout permettre d'avoir en tête une partie structurelle de la codebase, de la couvrir par des tests unitaires de haut niveau (on ne teste pas les détails d'implémentation), de la modifier par babystep (sans casser les tests), et de merger. C'est un temps sans valeur ajoutée fonctionnellement, mais ça aide le futur.

Dans un article sur les sprints Agile, Gojko Adzik parle de la gestion de la maintenance du code. Il propose de convenir d'un budget en fonction du besoin de pérennité du projet et de s'organiser comme suit :

You don’t have to keep sustainability tasks in the backlog or track them in the task management tool, just do them as much as the budget allows every iteration. The team will mostly know what are the next few critical improvements, they don’t need to keep them in a list visible to anyone else. In theory, it may be good to understand the impact of sustainability tasks in order to prioritise them, but in most cases this is obvious. Urgent bugs come first, otherwise they aren’t that urgent, and the remaining sustainability tasks all tend to be gradual improvements, so it’s not that critical to select any particular order.

Vous n'avez pas besoin de garder les tâches de maintenance dans le backlog ou de les suivre dans l'outil de gestion des tâches, il vous suffit de les faire autant que le budget le permet à chaque itération. L'équipe saura le plus souvent quelles sont les prochaines améliorations critiques, elle n'a pas besoin de les garder dans une liste visible par les autres. En théorie, il peut être bon de comprendre l'impact des tâches de maintenance afin de les hiérarchiser, mais dans la plupart des cas, cela semble évident. Les bogues urgents passent en premier, autrement ils ne sont pas si urgents, et les tâches de maintenance restantes ont toutes tendance à être des améliorations progressives, il n'est donc pas si important de choisir un ordre particulier.

Si vous lisez l'anglais, je ne saurai que vous recommandez de lire cet article : Sprints, marathons and root canals

How to prioritise technical debt against business features? How do we convince them that refactoring is important? How can anyone estimate the value of technical stories?

Merci Gojko Adzik.