Nettoyer votre code pour le rendre 5 S

Publié par David Beaumier, Jean-Francois Gilbert le lundi 20 avril 2015 à 08:13

Nous voilà rendus au 3ième concept de la méthode 5S : nettoyer (ou seiso en japonais). Comment ce principe, pensé à la base pour éviter la détérioration de la machinerie et des équipements, peut-il s’appliquer en développement logiciel?

Revenons pour une seconde aux fondements de la méthode 5S : une fois l’espace de travail ordonné (le premier S) et rangé (le second S), il devient beaucoup plus simple de le nettoyer puisque ce qui a besoin de nettoyage devient dès lors visible.  En développement, on pourrait penser à ces bouts de codes qui ont mal vieilli et qui handicapent d’une façon ou d’une autre le système. La fameuse dette technique, quoi!

Évidemment, pas besoin d’avoir fait les étapes 1 et 2 dans l’ensemble du code pour pouvoir passer au nettoyage. En procédant ainsi vous risqueriez même de salir de nouveau certains coins si l’application est d’une certaine envergure. Pourquoi ne pas directement cibler les morceaux qui sont connus pour dégager une odeur (virtuelle, on s’entend) nauséabonde? Probablement qu’il faudrait très peu de temps à l’équipe pour les identifier!

Nous vous proposons dans ce billet quelques suggestions pour procéder au nettoyage de votre base de code.

La règle des scouts

La bonne vieille règle des scouts, soit celle de laisser le campement plus propre au départ qu’à l’arrivée, peut être une bonne façon de procéder à un nettoyer graduel de votre code. En effectuant ici et là une extraction de méthode, un renommage ou en révisant une condition en introduisant un guard clause (quelqu’un a une bonne traduction à proposer?) votre équipe en viendra à rehausser la maintenabilité de la base de code. Et cela, sans impacter de façon significative son rythme de livraison habituel.

L’important dans toute opération de nettoyage de cette envergure est de se donner des objectifs atteignables, de mesurer la progression régulièrement (tous les sprints, par exemple) et d’ajuster le tir en fonction de ce que vous découvrirez. C’est surprenant de voir ce qu’on peut accomplir lorsqu’on rend visible la crasse qui se cache dans certains recoins du code!

Réingénierie (refactoring)

La réingénierie logicielle est la technique qui revient le plus souvent lorsqu’on parle de nettoyer du code existant.

La réingénierie logicielle est un processus ayant pour objectif de transformer et améliorer un logiciel à partir du modèle existant sans toutefois modifier son comportement externe.

Livre RefactoringtopatternMême si elle est simple à comprendre, c’est une technique qui demande beaucoup de pratique pour développer les bons réflexes et savoir bien doser son utilisation. Si vous débutez avec cette pratique, la lecture du livre Refactoring: Improving the Design of Existing Code de Martin Fowler s’avère toujours un bon point de départ (même après plus de 15 ans). Un catalogue des différents types de réingénierie est aussi disponible en ligne.

Le livre de Kerievsky s’adressera quant à lui aux personnes qui ont déjà un peu d’expériences avec la réingénierie et qui souhaitent voir comment cette technique peut être combinée avec les patrons de conception.

Scott Ambler et Pramod Sadalage ont même appliqué les principes de la réingénierie logicielle aux bases de données relationnelles dans leur livre Refactoring Databases: Evolutionary Database Design.  Vous n’aurez dorénavant plus aucune excuse pour ne pas nettoyer votre schéma de base de données!

Outils disponibles

Il existe aujourd’hui des fonctionnalités de réingénierie dans pratiquement tous les IDEs. Sinon, des extensions plus avancées peuvent vous aider, tel que Resharper sous Visual Studio. Ces outils vous sauveront du temps, tout en évitant les erreurs typiques associées aux opérations manuelles de rechercher/remplacer.

Des outils spécialisés pour les SGBDR, tels que Liquibase ou SQL Server Data Tools vous aideront à produire les scripts de mise à jour requis pour offrir une cure de jeunesse à vos bases de données. La vidéo ci-dessous vous permettra d'avoir un aperçu de l'utilisation de Liquibase.

Identifier les candidats potentiels au nettoyage

Encore une fois, les techniques du management visuel peuvent venir à notre rescousse pour vous aider à identifier les bouts de code qui sont de bons candidats à la réingénierie. Par exemple, l'extension Microsoft CodeLens Code Health Indicator (pour Visual Studio Ultimate) permet d’obtenir plusieurs mesures sur la maintenabilité du code et l’indicateur visuel vous indiquera si vous êtes face à un bout de code qui rencontre les exigences (en tout cas, celles de Microsoft). On peut même voir si la modification courante améliore ou non le code et ajuster le tir au besoin. Ça réduit de beaucoup la boucle de rétroaction.

Codehealth

SourceMonitor est un autre outil qui peut aider à identifier les classes qui ont besoin d’un peu d’amour. Bien qu’il ne soit pas directement intégré à un IDE, SourceMonitor a l’avantage de supporter plusieurs langages de programmation, tels que C++, C, C#, VB.NET, Java et Delphi. Il permet de cibler un sous-ensemble plus ou moins grand de votre base de code et produit les métriques de différentes façons, tel que démontré ci-dessous. Il est aussi possible d'en automatiser l'utilisation de façon à prendre des mesures sur une base régulière.

Sourcemonitor

Et vous, quels sont les techniques et outils qui vous permettent de nettoyer votre code? Quels approches ont été les plus bénéfiques pour votre équipe?

Mise à jour

Voici les liens pour consulter les autres articles.

D'autres billets qui pourraient vous intéresser

blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.