Le refactoring c’est tout le temps, et c’est normal. (épisode 7 - le développement est sinueux, pas linéaire)
Cela fait maintenant deux semaines que Charlotte suit les conseils de Marc. Les nouvelles fonctions sont faciles à reconnaître, ce sont celles qui ont des tests. Une cinquantaine de tests pour une dizaine de nouvelles fonctions. Facile à lancer, facile à débugger.
Avant elle ne touchait plus à son code quand il marchait. Aujourd'hui, si elle ne peut pas y toucher, elle suspecte que le code ne marche pas.
Avant, coder vite la grisait. Aujourd’hui, coder lentement la rassure. Le lièvre et la tortue, ça l'énerve.
C’est un exercice nouveau d’améliorer le code en permanence, un luxe qu’elle ne s’autorisait pas avant. Avant, elle l’améliorait un peu bien sûr.
Un peu.
Elle a encore plein de questions. Le refactoring est possible grâce aux tests écrits avant de coder. Ceux qui veulent aller vite ne font pas de refactoring et ne font pas autant de tests. Ses fondamentaux conception-développement-tests sont modifiés, c’est toute sa connaissance du génie logiciel qui est remise en cause.
« Marc, la conception bouge beaucoup pendant le refactoring.
— Oui, et alors ?
— Alors, cela veut dire qu’au début la conception est fausse ?
— Non, ça veut dire que tu améliores au fur et à mesure que tu construis. Je te l’ai déjà dit, personne ne peut construire du code parfait du premier coup. Le refactoring te permet de ne pas être coincée avec ta conception initiale. Quand tu es face à un problème, tu te sens capable de trouver la bonne solution en une fois ?
— Pas toujours, non.
— Le refactoring te permet de trouver la bonne réponse, car en plusieurs fois, tu as plus de chances d’y arriver.
— Je vois, donc je dois retravailler plusieurs fois mon code ?
— Je répète, tu te sens capable de trouver la bonne solution en une fois ?
— Non …
— Ne pas refactorer, c’est croire que développer est une formule linéaire. C’est tout le contraire. Ce n’est pas parce que le code se lit de haut en bas qu’il a été écrit de haut en bas. L’écriture du code suit un chemin itératif, non linéaire.
— C’est dommage de devoir refaire.
— Pas refaire, améliorer. Si tu ne refactores pas, ton code pourrira. L'entropie est un phénomène naturel, le refactoring est un process pour lutter contre. »
Marc sourit tout le temps, il est moins brutal.
« Refactorer, c’est la meilleure méthode connue pour écrire du code améliorable. Le process fonctionne, tu peux lui faire confiance : tester-coder-refactorer, c’est LE process de construction d’un code maintenable. »
Charlotte réfléchit, elle ne voit pas comment expliquer ça à son chef lundi.
« Tu es d’accord que ce process coûte plus cher que juste coder ?
— Oui, la qualité du code coûte cher si c’est ce que tu veux dire. Tout le monde serait d’accord pour faire du code maintenable si ce n’était pas cher. Je te pose la question, ce code est-il maintenable ?
— Oui oui. »
Charlotte connaît maintenant le prix du code maintenable. Elle y repense, peut-être que ce code maintenable coûte moins cher que de devoir tout refaire de temps en temps, se convainc-t-elle.
« Il faudrait essayer ça au travail. Malik est curieux, avec lui ça devrait aller. »
Charlotte reconsidère sa notion de collage des kaplas.
« Ce n’est pas de la colle entre les kaplas que Marc a posé : ce sont des bouts de scotch.
« À chaque nouveau test, il enlève des bouts de scotch et il replace des bouts de scotch. Il modifie le nombre de kaplas ainsi que leur positionnement sans faire tanguer la tour. Il modifie des tests et il modifie du code sans rien casser.
« Il a trouvé un moyen de construire en solidifiant la construction.
« Et si ça se trouve, ce n’est pas plus cher. Le code avant refactoring et le code après refactoring ne sont pas comparables. J’espère bien que le code remanié aura moins de défauts. »
Charlotte a fait deux grandes découvertes :
- La pratique du refactoring s’appuie sur les tests.
- Les tests permettent de refactorer sans casser le code.
Elle ne développait pas mal avant, elle développait dangereusement. Charlotte vivait dans l’angoisse de ne pas être efficace, elle avait du mal à refaire car refaire c’était casser, refaire c’était ralentir. Comme une artiste, elle était émotionnellement attachée à son travail, refaire était un aveu d’échec.
Elle a appris que coder ce n’est pas faire du code refactoré, mais plutôt faire du code refactorable.
Le problème du garage était qu’il n’était plus rangeable, c’est pour ça qu’il a fallu tout ranger. D’ailleurs au dernier rangement elle a mis en place des espaces plus pratiques. Le garage aura besoin d’autres rangements, elle s’en doute bien. Elle espère seulement que les rangements suivants seront moins douloureux. Elle a trouvé des moyens de maintenir le garage rangé. Par exemple, le panier vide à l’entrée du garage qui permet de poser rapidement les petites affaires de vélo (lunettes, gants) sans devoir les ranger, et de les retrouver facilement à chaque sortie, c’est une amélioration qui marche bien, elle en est très fière.
Charlotte comprend qu’elle doit réaliser un code aménageable, facile à maintenir.
Le refactoring permet de maintenir le code rangé.
Dans son code il y aura des allers-retours, le refactoring est le process non linéaire d’écriture du code.
épisodes :
7 - le développement est sinueux, pas linéaire