Le refactoring c’est tout le temps, et c’est normal. (épisode 3 - appel à un ami)
Trop de doutes, Charlotte a besoin de conseils. Marc est indépendant, il est très fort techniquement et très gentil, ça va bien se passer c’est sûr. Elle a toute confiance.
« Marc mon ami, tu pourrais me faire une revue de code ?
« J’ai beaucoup avancé et j’ai besoin de tes feedbacks pour continuer.
« Je me pose quelques questions sur des endroits bien précis, mais le mieux je pense c’est que je te laisse regarder.
— D’accord, pas de soucis, je regarde ça.
— Merci ! »
Charlotte n’a pas osé être franche : elle l’attend comme le sauveur.
« Il a toujours de bonnes idées, avec ses commentaires je vais repartir de plus belle. »
La tour de kaplas défiera les lois de la gravité.
Marc met un peu de temps à s’y mettre. Charlotte trouve le temps long. Elle a pour sa part arrêté toute activité de développement. En fait, elle est bloquée. Si elle continue comme ça sans rien changer elle voit bien que ce n’est pas une tour mais plutôt une décharge de kapla qu’elle construira. Elle attend les commentaires tous les jours et rien. Elle vérifie, il ne s’est pas encore connecté. Elle n’est pas sûre que Marc soit intéressé finalement. Elle bascule sur d’autres activités qu’elle avait laissées de côté dans sa passion créatrice.
Elle écrit des tests.
Le test doit proposer des devinettes de la leçon plus de ses précédentes leçons.
La leçon précédente n’existe pas vraiment. C’est une astuce aujourd’hui qui rend ça possible.
« Je dois ajouter un ordre de leçons. Dans quel objet ? »
Pas facile non plus, certaines questions sont les mêmes.
Elle observe son code longtemps, et la conclusion est toujours la même : il faut casser du code. Ou alors un petit bout. Elle essaie d’identifier une petite partie cassable. Pas facile, tout est lié.
« Charlotte il faut qu’on se parle. »
C’était direct. Pas forcément brutal se convainc elle.
« C’est du niveau de toutes les sociétés d’informatique : sale et efficace. »
Charlotte ne sait pas quoi répondre, elle tente une explication :
« J’ai développé tout ça en 4 semaines, j’ai eu plein d’idées et j’ai dû faire plein d’allers-retours. Les utilisateurs sont ravis, ils utilisent vraiment l’application. »
Marc n’écoute pas les excuses.
« Raconte-moi ton code. Ça commence où ?
— Là : le fichier index. Puis les appels de tous les objets, l’objet qui lance l’application est Devinette, il contient la fonction LancerUnEntrainement qui va créer la Leçon. La devinette sera un kana de la leçon. Le jeu consiste à trouver quel est le bon romaji qui correspond au kana affiché. L'entraînement est lancé quand la fonction a associé le kana et les propositions à deviner.
— C’est un jeu, une devinette ou un entraînement ?
— …
— Comment tu peux t’y retrouver dans ton code si tu ne sais pas de quoi tu parles ?
— Oui, c’est un peu difficile à expliquer. C’est un entraînement.
— Une devinette c’est plusieurs entraînements ou un entraînement c’est plusieurs devinettes ? Et un jeu c’est quoi ?
— … je ne sais pas, mais les utilisateurs sont ravis.
— Ouais ben pas le développeur, lui, il pleure. »
Charlotte soupire. Elle marmonne :
« Tous les feedbacks sont méchants en fait. Ils ne se rendent pas compte que les gens travaillent dur pour ça, pas obligé de se fâcher. »
Elle tente une réponse argumentée :
« Au début je me suis inspirée de Google traduction, donc oui c’était une devinette, et puis avec l’alphabet japonais il faut s’entraîner, et puis quand les utilisateurs ont joué il est devenu pertinent de …
— Bon arrête, il faut renommer. »
Charlotte est déçue, les remarques de Marc ne lui apprennent pas grand chose.
« Il n’y a pas un autre moyen ? Il y a beaucoup de lignes de code quand même.
— Ecoute, là, je suis plutôt inquiet sur ta production au travail, si tu veux je t’aide. Je te propose qu’on refactore tout, petit à petit.
— C’est à dire ?
— On refactore, on débranche, on rebranche. D’habitude tu ne fais jamais de refactoring ?
— J’ai lu des articles, je n'en n’ai jamais fait. »
C’est un aveu, elle comprend qu’elle n’a plus le choix, si elle veut son aide, si elle veut progresser, il faut avouer.
« J’ai déjà vu du code refactoré. C’est pas mal, j’essaie de m’en inspirer.
— Pas mal … Tu ne peux pas t’en inspirer, en fait ! Tu n’y arriveras JAMAIS en une fois. Si tu ne refactores pas ton code, il est pourri, il mourra bientôt. »
Charlotte est déçue : cette discussion est trop compliquée, on ne parle même pas technique. En plus remettre en cause sa compétence à développer, c’est vexant. Marc est en train de dire qu’elle travaille mal.
« Pourquoi je n’y arriverai jamais en une fois ?
— Ecoute. Quand tu écris un mail important tu fais comment ?
— Et bien je fais attention.
— Moi j’ai déjà envoyé des mails que je n’aurai pas dû. Mal écrits, mal reçus.
— Oui, moi aussi ! Depuis je fais attention justement, je m’impose un processus qui marche bien :
- D’abord je ne remplis pas la zone « destinataire », je le fais à la fin quand je suis contente du mail.
- J’écris toutes mes idées, brutes.
- Je relis en vérifiant que tout y est. Ma vérification est facile, je contrôle que tous les points que je veux aborder sont présents.
- J’écris la conclusion.
- Je réécris deux ou trois fois la conclusion en testant qu’elle est bien cohérente avec les données brutes présentées.
- Je déplace la conclusion tout en haut du mail. Comme ça mon expéditeur saura tout de suite ce que je lui demande.
- Je reprends mes données brutes, je les positionne tout en bas du mail avec la mention « Plus précisément : ».
- Je relis mes données brutes, je les réécris pour qu’elles soient compréhensibles.
- A la fin je fais une dernière relecture, voire une deuxième.
- J’ajoute le ou les destinataires et j’envoie.
— Tu es trop forte.
— Comment ça ? »
« Tu sais refactorer un mail mais tu ne sais pas refactorer du code. »
Là c’est dûr. Elle ne sait plus où elle en est.
« Tu écris ton mail, ça marche. Puis tu retravailles ton mail, ça marche encore. Tu l’améliores, ça marche toujours. Tu es tellement satisfaite que tu décides de l’envoyer.
« Le code c’est pareil.
« Tu sais développer, ça marche. Et finalement, est-ce que tu es contente de ton code ?
— C’est vrai que je ne suis pas perfectionniste moi, je suis plutôt rapide.
— Attention aux mots. Un perfectionniste, il n’y arrive pas : il est toujours à vouloir refaire les choses car il ne les trouve jamais pas assez parfaites. Un mail important tu le traites rapidement ?
— Non, j’utilise mon process.
— Traite ton code comme quelque chose d’important. »
À ce moment-là Charlotte reçoit trop d’informations en même temps, qui génèrent trop de réflexions en même temps.
« D’accord, je vais tout nettoyer. » répond-elle, résignée.
« Surtout pas. »
Décidément la discussion est difficile.
Marc reprend calmement :
« Si tu nettoies tout, ça va prendre du temps. Tes utilisateurs peuvent attendre ?
— Je ne sais pas, avoue-t-elle.
— De plus, qu’est ce qui nous garantit que tu ne vas pas recommencer ? Que tu ne vas pas me rappeler dans deux mois car ton code est de nouveau illisible ?
— Je ne sais pas, avoue-t-elle à nouveau.
— Qu’est ce qui est le plus cool à faire selon toi ?
— Développer une nouvelle fonction.
— Et bien je vais te montrer comment développer une nouvelle fonction en faisant du refactoring.
— Mais attends, je n’ai pas le droit d’en faire, moi, d’habitude. Au travail je dois respecter le budget qui m’est attribué et puis le tech lead doit faire une présentation sur le refactoring, mais là on n’a pas le temps.
— Tu as sûrement raison, et ce sont d’autres problèmes. Concentrons nous sur maintenant si tu veux bien, ici personne ne t’en empêchera. »
Marc propose de ranger souvent. Marc l’autorise à ranger souvent.
Elle procrastinait, le chantier était trop gros.
Elle a hâte maintenant.
épisodes :
3 - appel à un ami