Comment effectuer des refactorisations de code volumineuses dans le curseur
a toujours été une tâche fastidieuse mais importante. La refactorisation consiste à prendre un morceau de code et à le nettoyer, soit par une meilleure séparation des préoccupations, soit par le principe de ne pas vous répéter (DRY), soit par d’autres principes d’hygiène du code.
Les refactorisations de code ont toujours été importantes, mais avec la sortie des agents de codage, nous constatons des résultats de codage plus élevés, ce qui conduit inévitablement à un besoin accru de refactorisation de code. Je me retrouve de plus en plus souvent dans des situations où certains codes doivent être refactorisés, même si je ne pense pas que ce soit un signe d’avertissement, étant donné que la quantité de code que je produis est également nettement plus élevée maintenant avec l’aide des LLM.
Heureusement, les efforts de refactorisation du code ont considérablement diminué depuis la sortie des LLM.
Dans cet article, je vais passer en revue mon approche de haut niveau pour effectuer une refactorisation de code à l’aide d’agents de codage comme Cursor ou Claude Code. Je couvrirai mon approche générique et mon processus de réflexion, donc le modèle que vous utilisez n’a pas d’importance.
Pourquoi effectuer une refactorisation du code
Vous devez effectuer une refactorisation du code chaque fois que vous remarquez de nombreux anti-modèles dans votre code, ou lorsque vous remarquez que vous (ou votre agent de codage) consacrez plus de temps que nécessaire à une implémentation. Votre seuil avant d’effectuer une refactorisation devrait également être inférieur à ce qu’il était avant la sortie des LLM, étant donné que les refactors sont désormais beaucoup plus faciles et plus rapides à mettre en œuvre à l’aide d’agents de codage.
En effet, une partie de la formation des agents de codage consiste à refactoriser le code, et ils sont particulièrement doués pour cela. Dans de nombreux cas, je dirais même qu’ils sont meilleurs que les humains, étant donné que le refactoring nécessite beaucoup de mémoire de travail :
- Se souvenir de toutes les variables
- S’assurer que les entrées/sorties après le refactor sont les mêmes qu’avant le refactor
- Quels fichiers déplacer, supprimer et ajouter
Ainsi, vous devez effectuer une refactorisation du code lorsque :
- Vous ou votre agent de codage découvrez de nombreux anti-modèles dans votre code
- Les implémentations commencent à prendre plus de temps qu’elles ne le devraient (signe d’un mauvais code)
Et vous devez effectuer des refactorisations de code car :
- Ils augmentent la vitesse d’itération
- Ils sont relativement peu coûteux à réaliser avec les LLM
Mon approche de la refactorisation du code
Dans cette section, je couvrirai mon approche de haut niveau de la refactorisation du code. Je vais passer par quatre étapes :
- Découvrir quand refactoriser
- Ce qu’il faut considérer avant le refactor
- Ce qu’il faut considérer lors du refactor
- Ce qu’il faut considérer après le refactor
Cela mettra en évidence la manière dont vous pouvez aborder la refactorisation vous-même, en termes si génériques que vous pouvez répliquer le traitement vous-même sur votre propre base de code.
1. Découvrir quand refactoriser
La première étape consiste toujours à découvrir quand vous devez décider de refactoriser votre code. Il n’y a souvent pas de ligne claire quant au moment où le refactoring doit être effectué ou non, et il faut donc un certain instinct pour savoir quel est le bon moment.
Cependant, vous devez appliquer quelques principes génériques simples. Si vous voyez beaucoup d’anti-modèles dans le code, par exemple avec :
- Beaucoup de code en double
- Docstrings et types de fonctions manquants
- Mauvaise séparation des préoccupations
Vous devriez envisager de refactoriser.
De plus, si vous remarquez que votre agent de codage passe plus de temps que d’habitude à lire votre base de code pour essayer de la comprendre. Ou bien, il a plus souvent du mal à mettre en œuvre quelque chose, et des erreurs apparaissent ailleurs. Vous devriez également envisager de refactoriser.
Cependant, reprendre cet instinct prend du temps, et au début, vous pouvez essayer de refactoriser plus tôt que tard (étant donné qu’effectuer une refactorisation est bon marché avec les LLM), puis vous ajuster lorsque vous en apprendrez davantage en cours de route.
2. Ce qu’il faut considérer avant le refactor
Lorsque vous êtes arrivé à cette étape, vous avez décidé qu’une certaine partie d’un référentiel de code devait être refactorisée. Vous devez maintenant planifier la portée que la refactorisation doit couvrir, car vous devez naturellement réduire la portée de la refactorisation autant que possible.
Réduire autant que possible la portée du refactoring
Je commence ensuite à planifier, ce que je fais principalement de deux manières :
- (facultatif) Si je souhaite discuter de prises de décision architecturales génériques ou d’idées de haut niveau, je commence à discuter avec Gemini dans la console. J’explique ma situation, les compromis, les différentes solutions que j’envisage et toutes autres informations pertinentes. J’ai ensuite une conversation avec Gemini au sujet de la décision. Remarquez le mot conversation. Je ne pose pas simplement à Gemini une question sur la façon de résoudre mon problème ; Je discute avec le modèle de la meilleure approche et j’essaie de comprendre le problème le mieux possible.
- Je commence toujours par utiliser mode planification dans Cursor ou Claude Code, où vous indiquez au modèle ce que vous voulez faire, il examine votre base de code et propose un plan sur la façon d’implémenter une solution dans votre base de code. Parfois, je copie ma conversation depuis Gemini (si je l’ai fait), et parfois je démarre simplement ma refactorisation directement dans Cursor.
Planifier votre approche est extrêmement précieux, car vous prenez conscience de certains problèmes dont vous n’aviez pas conscience auparavant et pouvez prendre des décisions avec autant d’informations que possible. De plus, vous pouvez lire le plan élaboré par Cursor et le modifier si nécessaire. Plus important encore, je vous recommande d’avoir une conversation avec votre agent de codage sur la façon d’aborder le refactoring, plutôt que de simplement lui poser une question simple et d’obtenir une seule réponse.
Vous devriez vous efforcer d’avoir conversation avec vos agents, et pas seulement une simple question et réponse
Je recommande de consacrer au moins 10 à 15 minutes à cette conversation lors d’une refactorisation importante.
Une fois le plan élaboré, je passe à l’étape 3.
"""
Example plan.md file after using plan mode
In this scenario, the context is refactoring a messy, monolithic `server.js` (Express node app) into a cleaner MVC (Model-View-Controller) architecture with TypeScript.
"""
***
# Plan: Refactor Monolithic Server to MVC Architecture
## Context
Currently, `src/server.js` contains all database connections, route definitions, and business logic in a single file. We need to refactor this into a modular structure using TypeScript, splitting concerns into Controllers, Services, and Routes.
## User Requirements
1. Convert the project to **TypeScript**.
2. Extract database logic into a Singleton/Service.
3. Separate routes into `src/routes`.
4. Move business logic to `src/controllers`.
## Proposed File Structure
* `src/app.ts` (Entry point)
* `src/config/database.ts` (DB connection)
* `src/routes/userRoutes.ts` (Route definitions)
* `src/controllers/userController.ts` (Request handling)
* `src/services/userService.ts` (Business logic)
---
## Step-by-Step Plan
### Phase 1: Setup & Configuration
- [ ] Initialize TypeScript configuration (`tsconfig.json`).
- [ ] Install necessary `@types` dev dependencies (`node`, `express`).
- [ ] Rename `server.js` to `server.ts` temporarily to resolve immediate linting errors.
### Phase 2: Database Layer
- [ ] Create `src/config/database.ts`.
- [ ] Move the MongoDB connection string and connection logic from `server.ts` to `src/config/database.ts`.
- [ ] Ensure the database connection exports a robust singleton or connection function.
### Phase 3: Service & Controller Extraction
- [ ] Create `src/services/userService.ts`.
- [ ] Move raw database queries (find, create, update) here.
- [ ] Define interfaces for User data.
- [ ] Create `src/controllers/userController.ts`.
- [ ] Implement `getUsers`, `createUser`, and `updateUser` methods.
- [ ] Import `userService` to handle the logic.
- [ ] Ensure proper type typing for `Request` and `Response`.
### Phase 4: Routing
- [ ] Create `src/routes/userRoutes.ts`.
- [ ] Setup `express.Router()`.
- [ ] Map endpoints (`/users`, `/users/:id`) to the specific Controller methods.
### Phase 5: Entry Point Cleanup
- [ ] Create `src/app.ts`.
- [ ] Initialize the Express app.
- [ ] Import and apply middleware (CORS, JSON body parser).
- [ ] Mount `userRoutes`.
- [ ] Connect to the database using `src/config/database.ts`.
- [ ] Delete the original `src/server.js`.
### Phase 6: Verification
- [ ] specific verification step: Start the server using `ts-node src/app.ts` to ensure no runtime errors.
- [ ] specific verification step: Test the `/users` endpoint to ensure data flow is intact.
---
### Would you like me to create this file structure for you now, or start specifically with Phase 1?3. Ce qu’il faut considérer lors du refactoring
Si vous êtes arrivé à cette étape, vous avez déjà préparé un bon plan avec votre agent de codage et vous avez commencé à effectuer le refactor. Pour rendre le refactor efficace et garantir qu’il fonctionne le mieux possible, je garde ces éléments à l’esprit :
- Soyez aussi indulgent que possible avec les autorisations. Bien sûr, soyez prudent avec les commandes destructrices, mais le fait que l’agent soit capable d’exécuter la plupart des commandes accélère considérablement le processus.
- Utiliser Claude. Mon expérience est que Claude Sonnet/Opus 4.5 sont de loin le modèle de codage le meilleur et le plus rapide du marché.
- Dites à l’agent de créer des scripts de test si nécessaire. Parfois, les agents essaient simplement de déboguer à partir du code seul, mais il est souvent préférable de l’informer pour créer un script de test dans lequel il peut voir les entrées et les sorties.
Je laisse ensuite l’agent de codage fonctionner jusqu’à ce qu’il soit terminé, ce qui peut prendre entre une minute et 20 minutes. Si c’est l’une des premières fois que vous exécutez du code dans le dépôt, vous devrez peut-être autoriser la liste de certaines commandes, mais comme mentionné, j’essaie d’être indulgent ici, surtout lorsque nous parlons de commandes de lecture, qui ne peuvent causer aucun dommage.
J’autorise également mon agent à créer des scripts de test et à les exécuter à volonté, non seulement pour déboguer le code en regardant le code, mais également en voyant les entrées et les sorties.
Avec cette configuration, je réussis principalement avec le refactor avec un maximum de quelques invites aller-retour, et dans de nombreux cas, une seule invite.
4. Ce qu’il faut considérer après le refactor
Une fois la refactorisation terminée, vous devez prendre en compte les modifications. Parfois, vous devriez examiner attentivement tout le code, même si parfois ce n’est pas nécessaire. Cependant, j’ai quelques recommandations particulières après un refactoring :
- Demandez au modèle de comparer les entrées et les sorties avant le refactor (pointez le modèle vers votre branche principale ou de développement, quelle que soit la branche dont vous partez lors du démarrage d’une nouvelle branche). Le modèle vous fournira un aperçu et vous devez généralement vous assurer que l’entrée et la sortie sont les mêmes avant et après. Cette astuce m’a évité beaucoup de bugs
- Exécutez une révision de codage avec un agent distinct (démarrez-le avec un nouveau contexte), ce qui permet de signaler plus facilement les erreurs que votre agent n’a pas vues lors de la refactorisation
- Demandez à Cursor de fournir un message d’engagement réfléchi et créez le PR pour vous. Cela accélère à la fois le processus de mise en production du code et rend vos relations publiques plus descriptives.
En particulier, mon premier point sur la comparaison avec la branche main/dev est important. Le fait que le modèle compare l’entrée et la sortie avec le code précédent et le code actuel a découvert tellement de bogues que le modèle n’a pas vu lors de la refactorisation.
Je pense qu’avec des modèles de codage encore meilleurs, nous verrons de moins en moins de ces erreurs, même si pour l’instant, je pense vraiment qu’il est utile de disposer du modèle pour un deuxième examen des modifications, à la fois en comparant les entrées et les sorties, et également en effectuant une révision du code.
Conclusion
Dans cet article, j’ai fourni un aperçu général de la façon dont j’effectue des refactorisations de code. J’ai d’abord expliqué comment savoir quand un refactoring est nécessaire, avant de plonger dans les spécificités de l’approche de refactoring. J’ai ensuite expliqué comment j’utilise le mode plan avant la refactorisation, autorise les commandes de liste pendant la refactorisation et demande au modèle de faire une deuxième révision du code refactorisé, avec une fenêtre contextuelle actualisée.
Je pense que la refactorisation LLM deviendra de plus en plus importante à mesure que nous verrons une sortie de codage de plus en plus élevée, grâce aux agents de codage LLM. Je pense également que le refactoring avec les LLM est très efficace et que tout le monde devrait garder à l’esprit, en particulier lorsque l’on code beaucoup à l’aide d’agents de codage.
👉 Mon eBook et mon webinaire gratuits :
🚀 10x votre ingénierie avec les LLM (cours gratuit par e-mail de 3 jours)
📚 Obtenez mon ebook gratuit sur les modèles de langage de vision
💻 Mon webinaire sur les modèles de langage de vision
👉 Retrouvez-moi sur les réseaux sociaux :
