7 Jan 2015

Dojo #13

Pour ce 13ème Dojo, les participants ont croisé le chemin d’une bête noire du programmeur : le refactoring d’un code existant et “un peu” hostile.


Sujet : https://github.com/AxaWebCenter/Dojo-13

Dans ce kata, nous avons 2 objectifs :

  • Comprendre ce que le code fait.
  • Rendre le code plus lisible sans en changer son comportement.

Technologies :

  • 7 binômes en C#/MS Test

WP_20141217_13_46_07_Pro

Nous avions 2h pour ce kata, découpé comme suit: 10-15 minutes d’explication du sujet, 1h30 de code, 20-25 minutes de debrief. On se donne comme objectif lors du premier 1/4 d’heure de comprendre le sujet.

Au bout d’1/4 on a fait émerger avec le groupe qu’avec un code aussi hostile et incompréhensible, on pouvait l’aborder de la manière suivante:

  • Vu qu’on ne comprends pas ce que cela fait, on tente de le faire tourner et de déverser à l’intérieur des données en entrées au petit bonheur la chance pour voir comme le programme réagit.
  • On se rends compte assez vite que cela n’est pas vraiment suffisant il est difficile de deviner les arguments en entrées comme cela. On se sert malgré tout de la structure d’un test unitaire pour faire nos premiers pas et avoir un bout de code qui tourne, dans un test.
  • En analysant le code on se rend compte que le programme lit une certaine quantité d’entier. On essaye donc de les lui refiler et on arrive assez vite à quelques cas de tests qui couvrent les scenarii suivants: cas passant, cas impossible, plusieurs cas (passant et/ou impossible).
  • On peut commencer a refactorer doucement le code en s’attaquant dans l’ordre:
    • A ce que l’IDE nous indique comme code mort
    • Travail en inlinant et en supprimant les variables inutiles
    • Travail sur la double boucle imbriqué et son test ‘if’ juste en dessous
    • Renommage des variables en des concepts plus parlant
    • Extraire les concepts en classes/structures pour répartir les comportements communs au même endroit et ajout de tests unitaires sur ces classes

Vous trouverez dans le répertoire code des essais dans ce sens.

A retenir sur ce kata :

  • Dans le cadre d’un code hostile sans tests, des tests de bout en bout (end to end, boite noire, etc…) nous permettent de découvrir le domaine et de comprendre le sujet. (Type technique Golden Master)
  • Une fois le sujet compris et le harnais de tests en place, on peut refactorer paisiblement.
  • On fait émerger un domaine métier qui se suffit à lui même en terme de documentation.
  • Les tests bout en bout peuvent être remplacer/compléter par des tests unitaires sur le comportement des nouveaux objets crées.
Share