Relecture de Code
[TDD]
Des vérifications automatisées ne sont pas l’unique moyen de corriger le bruit qui est présent dans la conception de votre produit.
Voici un exemple de correction (tardive) d’un bruit dans la conception :
— Dis-donc hier j’ai jeté un œil sur le code du module facturation…
— Hmm ?
— Tu savais que la moitié des paramètres de calcul sont en fait des variables globales ?
— Ah oui, où ça exactement ?
— À peu près partout. Heureusement que j’étais assis.
— Ah oui, mais c’est le code de Théo. C’était l’un de nos 3 stagiaires, en Mars dernier, tu te rappelles ?
— Va falloir corriger tout ça !
Voici un exemple du même bruit décelé à temps, au cours d’une session de relecture de code où participent un développeur expérimenté et 2 débutants.
(Je parle de “relecture” et non de “revue” dans la mesure où l’usage courant de ce terme le limite à commenter en ligne des propositions de changement en vue de les valider.)
— EX: Ligne 42 : on n’a pas besoin d’une variable globale, si ?
— D1: Hmm… Peut être pas.
— EX: C’est une règle du standard : non aux variables globales sauf exception commentée.
— D1: Je ne connaissais pas cette règle.
— D2: Ha, moi non plus, du coup.
Au cours de cette session de relecture la conception vient d’être “vaccinée” contre les variables globales injustifiées :
1) le bruit est détecté et isolé
2) une (petite) partie de l’état de l’art est mise en évidence
3) deux personnes améliorent leurs connaissances sans avoir spontanément posé de questions
La majorité des professionnels considèrent la relecture de code comme une perte massive de temps. Parfois, cela fait suite à une ou plusieurs tentatives échouées faute d’un process adéquat. (Pro tip: ce n’est pas une “réunion” où on est invité à “débattre” sur l’État de l’Art en général).
On peut supposer que dans leur contexte, ceux qui renoncent à relire le code ensemble trouveront un moyen de le corriger individuellement sans avoir à consulter ni définir aucun standard, ou bien que des outils suffisent à détecter tout le bruit possible que leur conception peut comporter. Ou bien encore qu’il sera toujours temps dans 2 ou 3 ans de proposer une élimination totale du bruit sous la forme d’une refonte, un projet à part entière, et qui n’est pas leur préoccupation d’aujourd’hui d’autant qu’il sera porté par des ingénieurs commerciaux, et que pour eux cette base de code sera déjà de l’histoire ancienne.
Si l’on remet à plus tard la prévention des défauts (une forme en soi de décision absurde), c’est que sa mise en place requiert du temps, de la patience et de l’énergie. Mais sans prévention,
- vous subissez le bruit au lieu de le détecter et le corriger
- vous ne savez pas dire si votre conception comporte du bruit ou pas
- vous ne distinguez plus vraiment votre état de l’art lui-même
En bref, dans ce brouillard votre système de conception est sourd et aveugle : il détecte les obstacles uniquement après collision.
Stay Tuned!