Retranscription brute de pomme de la petite rétro diffusée en interne

Hier soir se tenait le book club de Lyon, organisé par le software craftmanship de Lyon. On était une petite dizaine, je vous fais un résumé rapide :

La séance portait sur les deux premiers chapitres de Refactoring de Martin Fowler, qu’on ne présente plus

La discussion a commencé sur la difficulté de faire du Refactoring en partie à cause d’une vision biaisée que le monde du business logiciel lui donne. Fowler explique à ce titre que le Refactoring n’est pas une tâche à part entière mais plutôt une étape de chaque développement. On aura paraphrasé Kent Beck :

To make a change, make the change easy and then make an easy change.

L’excuse “on a pas le temps on verra lors de la prochaine refacto” est un non sens financièrement parlant puisqu’une dette technique est quasi toujours mal maitrisée. Certes, certaines entreprises ont besoin d’une petite dette technique pour bien fonctionner, mais souvent la dette s’accumule et la période de refacto apparaît de plus en plus imaginaire

Quand refacto et quand ne pas refacto du coup ?

If it ain’t broke, don’t fix it

Ne pas aller refacto du code quand on sait que le code ne va pas évoluer. Le mieux est donc de refacto pour chaque feature donnée mais ça je vous en ai déjà parlé

On a évoqué l’importance du code review et des habitudes de chacun pour paraitre diplomatique dans les remarques. L’étape de la revue de code, ou celle du cross testing (qu’on fait peu ici), est également une bonne étape pour faire du refacto

En outre, la force des tests, c’est qu’ils permettent que le processus de refactoring soit sans régression.

Mais aussi : c’est difficile d’être un génie et de voir les patterns émerger sur du code legacy. Une bonne solution c’est de faire des tests pour faire émerger le “Quoi?” plutôt que le “Comment?”. Le quoi désigne le besoin utilisateur (dans tel contexte, je fais telle action, je m’attends à tel résultat). Le comment désigne l’implémentation. Pour chaque test qu’on veut créer on se rend compte qu’on ne peut pas tester en l’état actuel des choses (besoin de mocker 100 objets par exemple) et alors on fait un petit refacto. Quand s’arrêter ? C’est l’objet du chapitre 3 !

Prochaine session : http://www.meetup.com/Software-Craftsmanship-Lyon/events/227528781