Comment augmenter la vitesse d’itération du codage

En développant du code, vous devez souvent le tester avant de le passer à l’environnement de développement ou de production. Cependant, attendre un déploiement avec des actions GitHub ou un déploiement de pile CDK avec CDK prend du temps.

De telles tâches chronophages tuent vitesse d’itération, ce qui est un facteur critique si vous souhaitez développer du code efficacement. En effet, vous devez tester correctement vos implémentations pour vous assurer qu’elles fonctionnent. Ensuite, après chaque modification, vous devez le tester à nouveau.

Avec les derniers agents de codage, le développement de scripts de test locaux complets est ultra rapide, et c’est quelque chose que je fais tous les jours lorsque j’écris du code en tant que data scientist.

Dans cet article, je vais vous expliquer pourquoi vous devez créer une configuration de test locale efficace en exécutant une image Docker et en envoyant des événements de test. Je montrerai également comment je le fais moi-même et comment cela m’aide à devenir un ingénieur plus efficace.

Je parlerai principalement de la façon de travailler avec Infrastructure as Code (IaC), car c’est principalement ce avec quoi je travaille au quotidien. Cependant, le concept d’exécution efficace de votre code localement s’applique à toute programmation.

Pourquoi vous devez exécuter du code localement

Tout d’abord, je souhaite expliquer pourquoi nous devons exécuter du code localement. La réponse simple est la suivante :

La vitesse d’itération est l’un des aspects les plus importants pour mettre efficacement du code fonctionnel en production.

Plus vite vous pouvez parcourir votre code, mieux c’est. Lorsque vous développez une nouvelle fonctionnalité (ou corrigez une ancienne fonctionnalité), vous souhaitez tester rapidement si elle fonctionne, puis corriger le code de manière itérative jusqu’à ce qu’il fonctionne comme prévu.

Si vous devez attendre 5 à 15 minutes pour que votre code soit déployé avant de le tester, vous avez un sérieux problème. Chaque fois que vous ne parvenez pas à résoudre un problème en une seule fois, vous perdez 5 à 15 minutes à simplement attendre le déploiement.

Au lieu de cela, vous devez exécuter votre code localement. Par exemple, si vous travaillez avec IaC, tel qu’AWS CDK, vous pouvez créer et exécuter des images Docker localement, en répliquant essentiellement l’environnement de production, mais sur votre propre ordinateur. De cette façon, la boucle d’itération est simple et le temps nécessaire pour créer l’image Docker et exécuter le code.

La création de l’image Docker est généralement très rapide, étant donné que Docker met en cache les versions précédentes. Ainsi, la plupart de votre temps est probablement consacré à exécuter le code avec une entrée de test et à vérifier que la sortie est comme prévu.

Si vous travaillez sur une application Web, vous devriez (et vous le faites probablement déjà) exécuter l’application localement avant de déployer votre code. Il ne devrait y avoir aucune différence lorsque vous travaillez avec IaC.

Comment se développer localement comme s’il s’agissait d’un environnement de production

Un aspect important lors du développement local est que vous êtes capable de reproduire fidèlement l’environnement de production. Si vous écrivez IaC, créez des images Docker et exécutez l’image Docker localement :

Vous testez avec exactement le même code, avec les mêmes chemins d’entrée, et si vous mettez en miroir votre fichier .env dans le fichier .env de production, vous mettez également en miroir toutes les variables. Ainsi, exécuter des images Docker localement est la voie à suivre si vous pouvez le faire.

Créez des scripts locaux avec des agents de codage

Avant la sortie d’agents de codage comme Cursor et Claude Code, il était généralement fastidieux de configurer du code pour tout exécuter localement. Vous deviez créer correctement l’image Docker, la configurer pour qu’elle s’exécute avec votre fichier .env, etc. Ou vous souhaiterez peut-être plutôt exécuter votre code localement en tant que serveur FastAPI, auquel cas vous serez confronté à des défis similaires.

Ce n’est cependant plus un problème. Pour commencer à s’exécuter localement, je fournis généralement à Cursor l’instruction suivante :

Create a shell script for me to run this code locally. The shell script
should run the docker image, and have an optional --build flag, which builds
the docker image before running it. The docker image should load environment
variables from the .env file.

Cela crée un script shell efficace que vous pouvez utiliser. J’aime l’option –– construire tag, car la création de l’image Docker prend parfois beaucoup de temps et je n’ai pas toujours besoin de la créer avant de l’exécuter.

De plus, les facteurs suivants me permettent d’exécuter le script facilement :

• Je ne stocke jamais de vrais secrets dans .env. Je stocke uniquement les références secrètes, que mon code récupère ensuite auprès d’AWS Secrets Manager. Ainsi, je peux transmettre mon fichier env sans craindre de divulguer des secrets. De plus, cela permet aux autres d’exécuter plus facilement les scripts lorsqu’ils extraient le code de GitHub.
• Je crée un autre fichier avec des événements de test, dans lequel je peux facilement envoyer des événements à l’image Docker en cours d’exécution. De cette façon, je peux facilement vérifier l’entrée et la sortie
• Je déploie les scripts de test sur Git, afin que tout le monde y ait également accès. Cela inclut le fichier env comme mentionné, car il ne contient aucun secret

Vous disposez désormais de la configuration exacte dont vous avez besoin pour exécuter et tester votre code localement. Chaque fois que vous apportez des modifications, vous reconstruisez l’image Docker et envoyez les événements de test, en vous assurant que tout fonctionne comme prévu.

Je recommande de configurer ces scripts de test locaux pour tous vos dépôts et de les transférer vers Git pour les partager. Avoir accès à ces scripts rendra toute votre équipe plus efficace en tant que programmeurs.

Autres conseils pour exécuter localement

Je souhaite également partager deux conseils supplémentaires pour être encore plus efficace, compte tenu de ces fichiers de tests locaux :

• Exécuter et tester l’image Docker avec des hooks de pré-validation
• Donnez à votre agent de codage l’accès à ces scripts

Hooks de pré-validation

Les hooks de pré-commit sont du code qui s’exécute avant chaque validation sur git. Les hooks de pré-validation typiques incluent :

• Courir noir . pour le formatage
• Courir monpy pour la sécurité des types
• Courir tests pytest pour être sûr que tous les tests réussissent

Avoir un hook de pré-validation garantit que vous n’oublierez jamais d’exécuter de telles commandes avant de pousser votre code. C’est incroyablement utile et permet de gagner beaucoup de temps. Il m’est difficile de compter le nombre de fois où j’ai oublié d’exécuter un formatage noir avant de valider, et les tests de déploiement finissent par échouer 5 minutes plus tard, ce qui me coûte beaucoup de temps.

Si la création, l’exécution et les tests sur l’image Docker ne prennent pas beaucoup de temps, je recommande également de l’ajouter aux hooks de pré-validation. De cette façon, vous garantissez qu’avant de transmettre un code, vous avez testé que le code s’exécute dans un environnement de production et que vous obtenez le résultat attendu pour une entrée donnée. L’implémenter en tant que hook de pré-validation vous fera probablement gagner beaucoup de temps à l’avenir.

Donner au curseur l’accès aux scripts de test

Le deuxième conseil est que je donne toujours un accès Cursor et Claude Code pour exécuter mes scripts de test. Je dis ensuite à Cursor d’exécuter les scripts de test après avoir apporté des modifications et avant de mettre fin à son implémentation actuelle.

Faire exécuter votre agent de codage et tester les images Docker augmentera considérablement le nombre de fois où il sera capable de réaliser une implémentation unique.

Cela vous fera gagner beaucoup de temps lorsque votre agent de codage implémentera une fonctionnalité, et vous devrez ensuite exécuter et tester manuellement l’image Docker. Si vous rencontrez maintenant une erreur, vous devez la coller dans votre agent de codage et le cycle se répète jusqu’à ce que le code fonctionne.

C’est une perte de temps et vous devriez vous efforcer d’éviter cela. Donner à votre agent de codage l’accès aux scripts de test revient essentiellement à lui donner un outil qui améliore considérablement les performances des tâches d’ingénierie logicielle. Je ne saurais trop insister sur le temps que cela me fait gagner.

Conclusion

Dans cet article, j’ai expliqué comment créer localement des environnements de production réalistes en créant des scripts pour créer, exécuter et tester des images Docker localement. Cela réduit la vitesse d’itération, qui est un élément essentiel pour être un programmeur efficace. De plus, j’ai expliqué comment procéder dans la pratique : en invitant Cursor à créer les scripts de test et quelques exemples d’événements que je peux exécuter sur l’image Docker. Je donne ensuite accès à Cursor et Claude Code pour exécuter ces scripts, rendant ma programmation beaucoup plus efficace.

Je pense qu’avoir une vitesse d’itération rapide est essentiel pour presque toutes les tâches de génie logiciel, et c’est quelque chose que vous devriez rechercher. Créer des fichiers de test locaux et y donner accès à votre agent de codage augmente considérablement la vitesse d’itération, c’est pourquoi je pense que le faire moi-même a considérablement augmenté ma productivité en tant que programmeur.

👉 Mes ressources gratuites

🚀 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 :

📩 Abonnez-vous à ma newsletter

🧑‍💻 Entrer en contact

🔗 LinkedIn

🐦 X/Twitter

✍️ Moyen