Vendredi dernier, grande relance du chef sur le nombre de lignes de code du projet.
Off course avec mon acolyte Marcello[1], nous avons recommencé à expliquer le pourquoi du le nombre de lignes de code, c'est mal et ça mesure pas combien on gland... Travaille dur.
Et là, quasi-éclair de quasi-génie !!!
Vous ai-je déjà dit que j'étais aussi le grand Manitou du serveur Subversion ?
Oui, je l'ai fait ? Bon, bah, je le redis :
Je suis le grand Manitou Subversion dans mon boulot... Enfin, dans mon département... Bon, okay, dans ma salle de dev
Il m'est venu une idée: Plutôt que de mesurer le nombre de lignes de code à un moment donné[2], ne serait-il pas opportun de regarder l'évolution de ce nombre au fur et à mesure du projet ?
En effet, ce nombre ne fait pas qu'augmenter. Par exemple, lors d'un refactoring, il n'est pas rare de supprimer plus de lignes que d'en rajouter.
Du coup, en comptant l'ensemble des variations de lignes de code depuis le début du projet et en appliquant une règle pondérant le nombre de lignes supprimées par rapport au nombre de lignes ajoutées[3], on peut rapprocher cette variation du temps de développement. Car au final, c'est bien le nombre demandé par le chef : "Combien de lignes de code vous écrivez à l'heure ? Combien ça me coûte ?".
Bon, on a déjà eu le même coup avec le nombre de bugs et on en a pris plein la figure à l'époque donc finalement, je crois que je vais laisser traîner 
Enfin, votre avis m'intéresse sur la question, chers lecteurs et lectrices.
