Nettoyer son code legacy avec grep

En tant que développeur web, j’ai récemment dû faire face à un défi classique mais peu engageant : nettoyer un projet contenant des implémentations obsolètes accumulées depuis 2007, soit plus de 15 ans de code legacy.

La commande qui a changé ma fin de semaine

Ces jour-ci, mon attention s’est portée sur une commande Linux particulièrement puissante :

grep -Rl --exclude-dir={dir-a-exclure-1,dir-a-exclure-2} "texte à chercher"

Cette ligne de commande m’a permis de localiser efficacement toutes les références à d’anciennes intégrations Google (analytics, adsense, etc.) dispersées dans mon code, certaines datant des débuts du site en 2007. Comme tout développeur web débutant à l’époque, je surveillais avec attention mes statistiques de visiteurs et avais intégré ces outils partout.

Décryptage de la commande

Prenons le temps de comprendre ce que fait exactement cette commande :

grep : l’outil de recherche par excellence sous Linux
-R : recherche récursive dans tous les sous-répertoires
-l : affiche uniquement les noms de fichiers contenant les correspondances (plutôt que les lignes correspondantes)
--exclude-dir={dir1,dir2} : ignore les répertoires spécifiés
"texte à chercher" : le motif à rechercher dans les fichiers

Mon cas d’usage concret

Dans mon cas, j’ai pu rapidement identifier tous les fichiers contenant d’anciennes traces de Google Analytics et AdSense avec :

grep -Rl --exclude-dir={node_modules,build,dist,.git} "UA-[0-9]" .

Puis pour les publicités :

grep -Rl --exclude-dir={node_modules,build,dist,.git} "adsbygoogle" .

Cette approche m’a fait gagner énormément de temps par rapport à une recherche manuelle ou à l’utilisation des fonctionnalités de recherche des éditeurs de code, qui peuvent être moins performantes sur de grandes bases de code.

Les défis post-nettoyage

Bien que la commande grep ait brillamment résolu la partie « identification », le nettoyage proprement dit s’est avéré plus complexe. Comme je m’y attendais, la suppression de ces éléments a entraîné des problèmes lors de la rebuild de certaines applications.

La raison ? Les dépendances React, Webpack, Bootstrap et Sass ont considérablement évolué au fil des années, rendant certaines parties du code incompatibles avec les versions actuelles.

Ce sont surtout les projets créés avec d’anciennes versions de Bootstrap ou de React qui m’ont donné le plus de fil à retordre. Pour identifier précisément les versions utilisées dans chaque projet, j’ai utilisé une version plus élaborée de la commande grep :

grep -R --exclude-dir=node_modules --include="package.json" -n -E '"(bootstrap|react)"' .

Cette commande recherche spécifiquement dans tous les fichiers package.json (en excluant le dossier node_modules) les occurrences de « bootstrap » ou « react », affichant le numéro de ligne avec l’option -n. Cela m’a permis de cartographier rapidement tous mes projets et leurs versions de dépendances.

Il a alors fallu trouver le bon « assemblage » de versions compatibles entre elles. L’enjeu étant de déterminer quelle combinaison précise de paquets me permettrait d’obtenir un build fonctionnel tout en évitant d’avoir à modifier la syntaxe de mon code existant. Chaque mise à jour majeure de dépendance risquait d’entraîner une cascade de modifications dans le code source.

J’ai même redécouvert un projet particulièrement « vintage » qui utilisait simultanément Grunt (avec un Gruntfile.js) pour orchestrer les tâches de build et Bower pour gérer les bibliothèques front-end — deux outils largement remplacés aujourd’hui par Webpack ou Vite (build) et npm/yarn (gestion de paquets).

J’ai donc dû jongler avec :

Des versions de React correspondant aux bonnes versions de ReactDOM
Des versions de Bootstrap compatibles avec les versions de jQuery et Popper.js utilisées
Des dépendances secondaires ayant leurs propres contraintes de compatibilité
Des outils de build exigeant des versions spécifiques de leurs plugins

Alternatives sous Windows

Pour les développeurs travaillant sous Windows, plusieurs options permettent de réaliser des opérations similaires :

1. PowerShell

PowerShell offre une alternative native puissante :

Get-ChildItem -Path . -Recurse -Exclude "dir-a-exclure-1","dir-a-exclure-2" | Select-String -Pattern "texte à chercher" -List | Select Path

Décortiquons cette commande :

Get-ChildItem -Path . -Recurse : équivalent à ls -R ou find . sous Linux, liste récursivement tous les fichiers
-Exclude "dir-a-exclure-1","dir-a-exclure-2" : exclut les répertoires spécifiés (comparable à --exclude-dir)
| Select-String -Pattern "texte à chercher" : filtre les fichiers contenant le motif (l’équivalent de grep lui-même)
-List : affiche seulement les noms de fichiers, similaire à l’option -l de grep
| Select Path : formate la sortie pour n’afficher que les chemins

Bien que fonctionnelle, cette commande illustre pourquoi de nombreux développeurs Windows finissent par installer des outils comme Git Bash ou WSL pour bénéficier de la concision des commandes Unix.

2. Windows Subsystem for Linux (WSL)

Une autre option est d’utiliser WSL, qui donne accès aux commandes Linux natives tout en permettant d’accéder aux fichiers Windows via le chemin /mnt/c (pour le lecteur C:) :

# Même commande que sous Linux
grep -Rl --exclude-dir={dir-a-exclure-1,dir-a-exclure-2} "texte à chercher" .

3. Git Bash

Si vous avez Git installé sur Windows, Git Bash inclut une version de grep :

grep -r --include="*.js" "texte à chercher" .

Notez que la syntaxe peut légèrement différer.

4. findstr (natif Windows)

Windows dispose de sa propre commande native, moins puissante mais fonctionnelle :

findstr /s /m /c:"texte à chercher" *.*

Cette commande permet de rechercher un texte précis (« texte à chercher ») dans tous les fichiers du répertoire courant et de ses sous-répertoires. Voici le détail de ses options :

/s : Cette option permet de rechercher de manière récursive dans tous les sous-dossiers du répertoire courant.
/m : Avec cette option, l’affichage se limite aux noms des fichiers qui contiennent la chaîne recherchée, sans afficher les lignes correspondantes.
/c:"texte à chercher" : L’option /c: indique à findstr que la chaîne de caractères qui suit (ici, « texte à chercher ») doit être recherchée telle quelle, en tenant compte notamment des espaces.
*.* : Ce paramètre précise que la recherche doit s’effectuer dans tous les fichiers, quels que soient leur nom et leur extension.
Leçons apprises

Ce processus de nettoyage m’a rappelé quelques principes essentiels :

Modularisation : Isoler les intégrations dans des composants dédiés limite l’impact de leur remplacement.
Tests automatisés : Des tests solides permettent de vérifier rapidement que le nettoyage n’a pas cassé de fonctionnalités.
Mise à jour progressive : Maintenir ses dépendances à jour régulièrement évite les grands écarts de versions.

Conclusion

Bien que la commande grep ait été un allié précieux pour identifier le code obsolète, ce projet de nettoyage m’a rappelé l’importance d’une architecture logicielle bien pensée et d’une maintenance régulière. Les efforts investis aujourd’hui dans un code propre et modulaire sont toujours rentabilisés lors des mises à jour futures.

Et vous ? Avez-vous déjà utilisé grep ou des outils similaires pour des tâches de nettoyage de code ? Partagez vos expériences en commentaires !

Frédéric Misery