Code de mue cutanée

Voici un peu de jargon que j'ai appris en travaillant dernièrement sur un projet pour un client : déchiqueter. Ou : partir en déchiquetage.

Cela signifie réécrire du code. Démonter quelque chose, le mettre dans un broyeur, puis le remonter, mais d'une manière différente et meilleure. C'est du refactoring, mais en remplaçant le scalpel par un marteau-pilon.

Lorsque vous dites que vous refactorisez quelque chose, cela peut signifier que vous modifiez une seule classe, méthode par méthode, en vous assurant qu'elle fonctionne après chaque modification.

Le déchiquetage, en revanche, signifie embrasser la destruction. Se lancer dans un déchiquetage consiste à supprimer cinq fonctions porteuses d'un coup et à les recréer. Supprimer un type et ses définitions, le reconstruire à partir des erreurs du compilateur. Créer un fichier vide et construire à partir de zéro une meilleure version de ce qui existe déjà dans un autre fichier. Le déchiquetage consiste à arracher une page et à la refaire.

Le concept — démonter quelque chose pour le recréer — n’était pas nouveau pour moi. Ce qui m’a surpris, c’est la fréquence à laquelle cela se produire chez ce client.

Quand je suis en binôme avec Éric, par exemple, il me dit souvent « supprimons ça ». Je lui réponds généralement en rigolant, mais il efface ensuite tout le texte le temps que mes pupilles se dilatent et qu'une seule syllabe sorte de ma bouche : « euh ? »

Ou quand Stéphanie et Éric s'associent, ils peuvent tomber sur quelque chose qui ne fait pas tout à fait ce qu'il devrait faire avec leurs nouvelles exigences et au lieu de — clink clink clink — le marteler pour lui donner forme, ils vont tout jeter et le reconstruire pour l'adapter à l'ancien et au nouveau cas d'utilisation.

Toute l'équipe a travaillé sur plusieurs semaines de travail exceptionnel , juste avant que je ne rejoigne l'équipe. Ils ont réécrit le framework d'interface utilisateur (maison) sous-jacent, et ont déplacé l'ensemble sur de nouvelles échasses, ce qui a donné lieu à une demande d'extraction finale +42,150 -330,105.

« Ce que j’aime vraiment, c’est qu’aucun code ici n’est considéré comme sacré », m’a dit un collègue, « aucun code n’est intouchable. »

C'est une pratique courante, elle fait partie de la culture, mais ce n'est pas facile. Un autre collègue et moi travaillions ensemble sur quelque chose et il a dit : « Mon Dieu, réécrire un tel composant, la confiance… » Oui, ai-je dit. Je savais ce qu'il voulait dire : il faut du courage pour regarder quelque chose qui fonctionne et décider de le casser, en étant sûr de pouvoir le reconstruire de manière meilleure, au lieu de changer la plus petite partie possible pour apporter votre changement. Il faut de l'expérience et de la conscience de soi pour savoir quand un petit changement est une bonne idée et quand il ne l'est pas, quand il vaut mieux faire un petit changement à la place.

Huit mois après avoir rejoint l’équipe, je ne sais toujours pas pourquoi les shreds fonctionnent si bien. Pourquoi cette base de code ne s'effondre-t-elle pas si des parties de celle-ci sont constamment démontées et réassemblées ?

Est-ce parce que les fondateurs ont écrit le projet en entier à partir de zéro et connaissent pratiquement tous les fichiers de sa base de code ? Est-ce parce qu'ils travaillent sur des éditeurs de texte depuis plus d'une décennie et connaissent bien le domaine, et que la façon dont les choses devraient fonctionner et la façon dont elles fonctionnent actuellement ne sont qu'un détail ? Est-ce parce que toute l'équipe est composée d'excellents programmeurs ? Est-ce à cause de... Go ?

Ou est-ce parce que les déchiquetages ne sont pas des frénésies de destruction, mais des démolitions à la loupe ? Pas un scalpel, pas une boule de démolition non plus, mais des marteaux de forgeron soigneusement dirigés ? Est-ce parce que celui qui se lance dans un déchiquetage ici fait attention à ne pas tomber dans le piège « … et quand c'est reconstruit, il devrait aussi faire ceci et cela » ?

Ce que je sais, c'est ceci : je pense que ces lambeaux réguliers sont sains pour la base de code.

Ils enlèvent les petits éléments qui s'accumulent au fil du temps et que personne ne remettrait en place s'il fallait recommencer. Des feux de forêt contrôlés qui brûlent les broussailles – la partie la plus inflammable d'une forêt – ne laissant que les arbres.

Ils vous permettent de vous débarrasser des maximums locaux, en vous donnant la possibilité de vous demander : si je devais refaire cette partie, à quoi ressemblerait-elle idéalement ? Ignorer les coûts irrécupérables est ce qui fait qu'un déchiquetage est un déchiquetage.

Avec des réécritures régulières et limitées (des déchiquetages) qui ne recréent qu'une poignée de fichiers, la base de code est dans un état de renouvellement constant. Comme un serpent qui mue, il perd ce dont il n'a plus besoin.

Merci de m’avoir lu!