Outils | Entreprise | Compte-rendus | Humeurs |   

Mot-clé - refactoring

Fil des billets - Fil des commentaires

28 août 2010

Ecrire des bons tests

tournevis.jpgDans une de ses présentations, Misko Hevery disait que la seule raison "valable" pour ne pas écrire de tests était de ne pas savoir comment faire. Plusieurs fois, j'ai cru savoir et aujourd'hui, je ne suis toujours pas sure de le faire "bien".

Lire la suite...

15 juillet 2010

CTRL+SHIFT+G

eclipse.jpgQuand du code me parait obsolète, je vérifie qu'il n'est pas utilisé en lançant un CTRL+SHIFT+G sur mon workspace Eclipse, avant de le supprimer.

Cette manoeuvre m'a trahie plusieurs fois :

  1. la classe était instanciée dans Spring
  2. la classe était utilisée... mais sur un projet qui n'était pas ouvert dans mon workspace. Ouvrir tous les projets juste pour cela a quand même un coût non négligeable. De plus, la manoeuvre n'est pas possible quand on a plusieurs branches (les différents projets portant le même nom).
  3. la méthode était utilisée dans de l'introspection. C'est là que je me dis, décidément, la réflection pose un véritable problème pour le refactoring.

Des tests d'intégration en JUnit ou Fitnesse peuvent révéler le premier souci. On se rend compte des deux autres à un moment ou un autre mais trop tard pour facilement identifier le problème.

Lire la suite...

26 mai 2010

Différentes expériences du TDD

givenWhenThen.jpg

Le projet sur lequel je suis actuellement va bientôt partir en production. Pas d'agilité dans mon équipe (malheureusement) mais quelques bonnes pratiques comme une réunion d'avancement quotidienne, l'utilisation d'une usine logicielle et le développement sous forme de TDD. Il s'agit d'une équipe qui a commencé à environ 8 personnes (projet critique donc on charge la mule au début) pour finir à 2 personnes.

Des TDD, oui ! Mes lesquels ?

Qui dit équipe de 8 personnes, dit expériences différentes de développement. Qui dit projet critique dit pression et donc pas le temps de faire du binômage ni de la revue de code. Argh.

Lire la suite...

28 avril 2010

Design for Testability, de Misko Hevery

Misko Hevery reprend dans Design for testability les différents points abordés lors de ses clean code talks.

En conséquence, si vous avez regardé les vidéos clean code talks, vous allez sentir quelques répétitions.

Lire la suite...

3 février 2010

Vitre cassée et refactoring

Je me rappelle avoir vu au lycée la théorie de la vitre cassée de Kelling et Wilson, tirée d'une expérience de Zimbardo. Dans un immeuble, les fenêtres étaient réparées dès qu'elles étaient brisées. Dans un autre, nous ne procédions pas aux réparations. Curieusement, le premier immeuble n'avait plus de dégradation alors que le deuxième se délabrait : toutes les fenêtres ont très vite été cassées. L'origine de l'étude était de prouver que l'environnement influençait nos comportements.

Le fait de ne pas réparer très vite une vitre cassée semblait donc encourager les gens à en casser d'autres. J'étais assez perplexe devant cette théorie parce que je ne voyais pas le rapport. En quoi voir une vitre brisée me donnerait envie d'en briser d'autres, et vice versa? Je pensais que peut-être, le fait de réparer très tôt les vitres rendaient vain toute tentative de dégradations, ce n'était plus "rentable".

C'est dix ans après que cette théorie m'est tout à coup revenu à l'esprit, en constatant le désordre sur la table. Au début, il y avait juste une gomme. Puis un crayon. Puis la corbeille de fruits... c'était le début de la fin. Ne pas ranger tout de suite ce qu'on utilise fait que rajouter encore un peu plus de désordre ne se voit plus... Nous en rajoutons insidieusement chaque jour un peu plus, on casse de plus en plus de fenêtres.

Non seulement, il y a de plus en plus de fenêtres à réparer, mais en plus elles couteront plus chères à réparer car il y a un cout/fatigue psychologique à se trainer cette dette. Il faut rassembler du courage, se retroussez les manches et se dire "Allez, on y va, on répare tout ça". Alors qu'en transformant la réparation d'une fenêtre dès qu'elle se casse en automatisme ne coute rien , il n'y a plus à réfléchir.

Cela rejoint les méthodes agiles dans le sens où il ne faut pas masquer les problèmes, au contraire, il faut les souligner, les rendre encore plus visibles pour qu'enfin, on y apporte une solution.

D'ailleurs, j'ai découvert récemment que cette théorie de la vitre brisée avait une application logicielle ! Concrètement, un environnement de code "sale" a tendance à rabaisser nos propres exigences de code propre. On a moins de scrupules à introduire du code sale. A contrario, du code très propre nous rendra beaucoup plus sévères avec nous-mêmes et nous tacherons de faire du code au moins à sa hauteur. Réparer une fenêtre se traduit en langage logiciel par du refactoring. C'est assez ironique dans la mesure où le refactoring est souvent vu par le client comme la dernière roue du carosse, alors que non, il est réellement essentiel à la survie d'une application.

Il me semble que Robert Martin proposait comme "solution" d'au moins nettoyer une chose à chaque commit / à chaque developpement. Par rapport à un refactoring plus massif et intimidant, l'objectif est suffisamment petit, atteignable pour être accompli. A la longue, l'application devient nettoyée, ou du moins nettoyable.

- page 1 de 2