Boy Scout Rule : laisser le code plus propre qu'on l'a trouvé, sans devenir insupportable
Améliorer un peu le code à chaque passage paraît une idée simple. En pratique, c'est l'un des principes les plus mal compris, et l'un de ceux qui finissent le plus souvent en pull request bloquée pendant trois jours.
Le Briefing Dev - les ressources et actus de la semaine, droit dans ta boîte chaque vendredi gratuitement.
Le problème : la pourriture lente du code
Voici une situation que tout développeur a vécue. Vous ouvrez un fichier pour corriger un petit bug. Le fichier fait 1200 lignes. Une fonction au milieu en fait 300 à elle seule. Les noms de variables sont obscurs. Il y a un commentaire qui dit // FIXME : à refaire après la démo daté de 2021.
Vous corrigez votre bug en deux lignes. Vous fermez le fichier. Vous n'avez touché à rien d'autre, parce que ce n'était pas votre ticket, parce que vous n'aviez pas le temps, parce que toucher à ce fichier vous semblait ouvrir une boîte de Pandore.
Six mois plus tard, le même fichier fait 1400 lignes. La fonction de 300 lignes en fait 380. Personne n'a osé y toucher. C'est exactement comme ça que naît la dette technique : non pas en une grande catastrophe, mais par des dizaines de petites occasions ratées.
La Boy Scout Rule, formulée par Robert C. Martin dans Clean Code, propose une réponse à ce phénomène. Elle tient en une phrase : laissez le code plus propre que vous ne l'avez trouvé. Pas parfait. Pas refactoré. Juste un peu plus propre.
Le principe, vraiment compris
L'analogie vient du scoutisme : quand un groupe quitte un emplacement de bivouac, il le laisse plus propre que ce qu'il avait trouvé en arrivant. Personne ne fait un grand chantier de nettoyage. Chacun ramasse un peu, et l'effet cumulé est massif.
Appliqué au code, ça donne un principe d'amélioration continue à coût marginal. À chaque fois que vous touchez un fichier, vous y laissez une petite trace d'amélioration : un nom de variable plus clair, un commentaire mort supprimé, une fonction de 80 lignes coupée en deux, un if imbriqué simplifié.
Ce qui distingue la Boy Scout Rule du refactoring classique, c'est l'échelle. On ne réécrit pas un module. On ne propose pas un grand cleanup PR. On améliore la zone qu'on est déjà en train de modifier, parce qu'on l'a déjà chargée mentalement, parce que les tests existants vont déjà la couvrir, parce que le risque est faible.
À retenir : la Boy Scout Rule ne demande pas de devenir un perfectionniste. Elle demande de ne plus être passif face à la dégradation du code qu'on lit.
Exemples concrets de bonne application
Renommer une variable opaque
Vous corrigez un bug dans une fonction qui contient une variable nommée d. Vous comprenez en lisant le code que d contient le nombre de jours depuis l'inscription. Trente secondes pour renommer en daysSinceSignup. Le prochain qui passera ne reperdra pas ces deux minutes.
Extraire une condition complexe
Vous tombez sur ce genre de ligne :
if (user.subscription && user.subscription.status === 'active' && user.subscription.expiresAt > Date.now() && !user.flagged) {Vous extrayez en une fonction hasActiveAccess(user). Le test qui couvre la ligne d'origine couvre toujours le cas. Vous n'avez rien cassé. Vous avez juste rendu la prochaine lecture plus rapide.
Supprimer du code mort
Une fonction computeOldDiscount qui n'est plus appelée nulle part. Un import inutilisé. Un commentaire // ancien calcul, à garder au cas où qui traîne depuis trois ans. Si Git existe, ce code peut partir. Vous le retrouverez dans l'historique si besoin.
Ajouter un test manquant
Vous corrigez un bug qui n'avait aucun test. Plutôt que de juste pousser le fix, vous ajoutez le test qui aurait attrapé ce bug. Coût : cinq minutes. Bénéfice : la régression ne reviendra pas en silence dans six mois.
Aucune de ces actions ne fait sortir votre pull request de son périmètre. Aucune ne demande de réunion d'archi. Et pourtant, multipliées par les dizaines de PR de votre équipe chaque mois, elles changent radicalement la trajectoire de la base de code.
Lien avec les autres principes de conception
La Boy Scout Rule n'existe pas en isolation. Elle tire sa puissance de tous les autres principes que vous appliquez en parallèle. Quand vous nettoyez un peu un fichier, vous appliquez sans le dire :
- DRY quand vous remarquez que la même logique est dupliquée trois lignes plus haut.
- KISS quand vous simplifiez une condition tordue qui faisait peur à tout le monde.
- YAGNI quand vous supprimez le paramètre optionnel qui n'a jamais été utilisé.
- SRP (le S de SOLID) quand vous extrayez une responsabilité parasite d'une classe trop bavarde.
L'inverse est aussi vrai : si votre équipe ne pratique pas la Boy Scout Rule, ces principes restent théoriques. Personne n'a jamais le temps de "vraiment" appliquer SOLID sur l'existant. Mais tout le monde a quinze minutes pour rendre un fichier qu'il vient de modifier un peu moins hostile.
Les pièges qui transforment un bon principe en cauchemar d'équipe
Piège 1 : la PR qui dérape
Vous deviez corriger un bug dans une fonction. Trois heures plus tard, votre PR touche 27 fichiers, renomme la moitié du module et déplace deux classes. Le reviewer ouvre votre code, soupire, et met le sujet en pause "pour en discuter en réunion". Votre fix urgent est bloqué pendant une semaine.
La règle implicite : si le nettoyage devient plus gros que le changement initial, il sort du scope. Faites-en une PR séparée, ou un ticket dédié, ou laissez-le pour la fois suivante. La Boy Scout Rule est censée réduire la friction, pas la déplacer sur les reviewers.
Piège 2 : nettoyer ce qu'on ne comprend pas
Une fonction vous semble inutilement complexe. Vous la simplifiez. La PR passe la CI. Trois jours plus tard, un comportement obscur en production se met à dérailler. La complexité bizarre que vous aviez "nettoyée" gérait en fait un cas particulier non testé, documenté nulle part.
Avant de simplifier du code que vous trouvez moche, posez-vous la question : pourquoi est-il comme ça ? Si vous n'avez pas la réponse, votre nettoyage est un pari, pas une amélioration. Cherchez l'historique Git, demandez à un collègue, ou laissez le code tranquille.
Piège 3 : nettoyer sans tests
Le corollaire du précédent. Si la zone que vous voulez améliorer n'a pas de couverture de tests, vos modifications "innocentes" peuvent introduire des régressions silencieuses. Dans ce cas, deux options : ajouter d'abord les tests qui manquent (ce qui est en soi une excellente application de la règle), ou s'abstenir de toucher à autre chose que le strict minimum.
Piège 4 : le perfectionnisme déguisé
Certains développeurs utilisent la Boy Scout Rule comme alibi pour passer trois jours à reformuler tout le code qu'ils croisent, au lieu de livrer la fonctionnalité demandée. Le test est simple : si vous ne pouvez pas expliquer votre nettoyage en deux phrases dans la description de PR, vous êtes sorti du cadre.
Piège 5 : ignorer les conventions de l'équipe
Vous trouvez que la convention de nommage du projet est mauvaise, alors vous renommez "au passage". Sauf que le reste de l'équipe a une convention différente, validée collectivement. Votre nettoyage devient une incohérence supplémentaire. La Boy Scout Rule ne permet pas de réécrire les choix de l'équipe en solo. Elle permet de les appliquer mieux.
Comment l'installer dans une équipe
Une règle individuelle qu'aucun process n'encourage finit par mourir. Voici trois leviers concrets pour ancrer la pratique au-delà des bonnes intentions.
Définir un budget de nettoyage par PR. Une convention informelle peut suffire : on s'autorise jusqu'à 10 ou 15 % de fichiers modifiés "pour le ménage". Au-delà, c'est une PR séparée. Ce chiffre n'est pas magique, mais le simple fait d'en parler change la culture.
Mettre le nettoyage dans la description de PR. Une section dédiée, même courte : "Au passage : renommé X, supprimé Y, extrait Z." Ça aide les reviewers à comprendre le scope, et ça rend visible le travail invisible.
Outiller la dette technique. Linters, formatters, règles ESLint ou Pylint, hooks pre-commit, métriques de complexité cyclomatique. Plus la dégradation est détectée tôt, moins la Boy Scout Rule a de travail à faire en aval. Si ces outils ne font pas encore partie de votre quotidien, la formation CI/CD avec GitHub Actions couvre l'automatisation de ce type de garde-fous.
Le cas particulier du legacy
Sur une base de code récente, la Boy Scout Rule fonctionne presque toute seule. Sur un legacy de huit ans avec 400 000 lignes, c'est plus subtil. Vous pouvez nettoyer pendant des mois sans qu'aucune amélioration ne soit perceptible. Le découragement s'installe.
Dans ce contexte, deux ajustements aident. Premièrement, concentrer les efforts sur les zones les plus modifiées. Un fichier touché trois fois par an n'a pas la même urgence qu'un fichier touché trois fois par semaine. Git permet de mesurer ça en quelques commandes (git log --pretty=format: --name-only | sort | uniq -c | sort -rg).
Deuxièmement, accepter que sur du legacy, "plus propre" peut juste vouloir dire "un peu mieux documenté". Ajouter un commentaire qui explique pourquoi un comportement bizarre existe est parfois le meilleur nettoyage possible, parce qu'il évite à la prochaine personne de le "corriger" par erreur. Si vous travaillez sur des bases de code orientées objet de longue date, la formation PHP orienté objet et la formation Symfony 7 abordent les patterns qui rendent ce type de refactoring progressif gérable.
FAQ
Faut-il appliquer la Boy Scout Rule sur du code que je ne maîtrise pas encore ?
Avec beaucoup de prudence. Si vous débutez sur un projet, votre priorité est de comprendre, pas de nettoyer. Limitez-vous aux améliorations sans risque : renommer une variable locale, supprimer un import inutilisé, ajouter un commentaire descriptif. Tout le reste attendra que vous ayez le contexte.
Mes nettoyages allongent les revues de code et énervent l'équipe. Que faire ?
Deux choses. Premièrement, séparez clairement vos commits : un commit "fix bug X", un commit "cleanup" distinct. Le reviewer peut traiter chaque diff indépendamment. Deuxièmement, posez la question franchement à l'équipe : à quel volume de nettoyage par PR tout le monde est-il à l'aise ? Une norme partagée vaut mieux qu'une bataille à chaque PR.
La Boy Scout Rule remplace-t-elle un vrai effort de refactoring ?
Non. Elle ralentit la dégradation et règle la dette de surface. Mais une refonte d'architecture, le découpage d'un monolithe ou la migration d'un framework restent des chantiers à part entière qui demandent un budget temps explicite. Confondre les deux mène à deux échecs simultanés : le grand chantier ne se fait jamais, et les petites PR finissent par dépasser leur scope.
Comment convaincre un manager qui veut "uniquement les fonctionnalités" ?
En montrant le coût réel de la dette. Le temps passé à comprendre un fichier mal nommé, le nombre de bugs liés à du code dupliqué, les régressions sur des zones non testées : ce sont des chiffres concrets. La Boy Scout Rule, présentée comme "10 minutes par PR pour économiser des heures de debug plus tard", se vend bien mieux que "il faut nettoyer le code".
Est-ce que ça s'applique aussi aux tests, à la documentation, aux scripts ?
Oui, et c'est même là que ça paie le plus vite. Un test mal nommé qui devient explicite, un README désynchronisé qu'on remet à jour, un script bash qu'on ajoute à un Makefile : ces nettoyages-là sont souvent invisibles dans les métriques mais transforment l'expérience quotidienne de l'équipe.
Quels outils aident à appliquer la règle au quotidien ?
Un linter strict, un formatter automatique, des hooks pre-commit, et une CI qui bloque les régressions évidentes. À ça s'ajoutent les capacités de refactoring de votre IDE : extraction de fonction, renommage propagé, détection de code mort. Plus ces actions sont rapides, plus la Boy Scout Rule devient naturelle. Si vous voulez creuser ces fondations, la formation Git et GitHub donne les bases pour bien isoler vos commits de nettoyage.
Pour aller plus loin
La Boy Scout Rule prend tout son sens quand elle s'inscrit dans une culture de code mature. Les autres principes du blog forment ce socle :
- Les principes SOLID
- DRY : arrêter de subir son propre code
- KISS : la simplicité comme compétence
- YAGNI : le code que vous n'écrivez pas
Côté formations, le catalogue LaPolaris couvre les briques techniques qui rendent ces principes applicables au quotidien : POO, frameworks backend, tests, CI/CD et gestion de versions.
