Le « refactoring » est une opération consistant à retravailler un code source existant afin d’en améliorer le fonctionnement sans en modifier la fonctionnalité. Au fil du temps et des développements d’une application, le code source peut accumuler des lignes de codes non optimisées, dites « sales ». Deux solutions s’offrent à vous : Soit écrire un nouveau code « from scratch », qui peut s’avérer coûteux et chronophage soit améliorer l’existant étape par étape. Le réusinage du code se concentre sur la deuxième solution.

La refactorisation entraine une dette, la dette technique. Elle désigne des erreurs, des failles et des défauts intentionnels ou involontaires dans le code. Ces défaillances sont générées par diverses raisons et ne cessent de croître en l’absence de réusinage du code. Il est important de contrôler cette dernière afin d’éviter une accumulation de tâches sans valeur ajouté et qui peut entrainer un coût financier important.

La dette technique qui entraine la refactorisation, est un sujet souvent dépriorisé dans les entreprises. Perçue comme un frein à l’innovation car la capacité à innover est restreinte, cette dette résultat d’un choix technique passé. Judicieux à court terme, avec des conséquences à long terme.

Analysons le graphique ci-dessus : En abscisse la période, en ordonnée le coût total de la dette technique. En pointillé vert, la dette initiale. En rouge, le plafond à ne pas dépasser. On peut s’apercevoir qu’avec le temps, la dette augmente et lorsqu’elle atteint le plafond fixé par les équipes, ces derniers la prennent en charge. Ce cas de figure se répète dans le temps. Les équipes attendent-elles le dernier moment pour agir ? Est-il possible de prévenir au lieu de guérir ? C’est ce que nous allons voir.

 

Lorsqu’on réusine, on se pose la question suivante : Quoi et comment ? Le quoi pour répondre au « Qu’est-ce que je dois optimiser ? » et le comment, plutôt « Comment dois-je le faire ? ». Voici une liste non exhaustive des causes du réusinage :

  • Montée de version
  • Mise à jour technologique
  • Pression économique
  • Documentation partielle ou absente
  • Développement complexe (complexité de la technologie et / ou du langage)
  • Manque de compétences ou de qualifications
  • Délocalisation du code
  • Pression temporelle

Après avoir vu les causes, jetons un œil aux solutions existantes à des fins préventives et pour réduire au maximum la refactorisation :

  • Anticiper les montées de version
  • Maintien des connaissances et des qualifications via la formation
  • Automatisation des détections d’erreurs de code
  • Arbitrer le ratio budget x temps
  • Créer des « users stories » de refactoring
  • Une DOD « definition of done » unanime au sein de l’équipe
  • Créer des indicateurs de qualité comme le temps de réponse d’une requête

 

On a pu voir qu’il est difficile, voire impossible d’éviter la refactorisation. En effet il y a des variables qu’on ne maitrise pas comme la montée de version qui peut survenir sur la technologie que vous utilisiez ou une mise à jour de version future qui impactera vos développements actuels. L’objectif étant de limiter la dette par des bonnes pratiques et de l’amélioration continue en itérant sprint après sprint et en adaptant ce qui fonctionne au sein de l’équipe.

 

Source : https://wikiagile.cesi.fr/index.php?title=G%C3%A9rez_votre_dette_technique pour le graphique

 

Obeïda Slimani, Consultant Data Product Owner chez Klanik