Développement de logiciels avec Devin : Expédition d'une tranche verticale (partie 2)

Bienvenue ! Dans le premier tutoriel de cette série, Devin a dépoussiéré mon vieux repo fp-ts-exercices et a ouvert un PR de mise à niveau des dépendances. Dans cette deuxième partie, nous augmentons la difficulté et construisons des fonctionnalités complètes.

Vous pouvez accéder à tous les tutoriels de la série Devin ici :

1. Mise en place et première Pull Request (Partie 1)
2. Expédition d'une tranche verticale avec Devin (Partie 2) 
3. Intégrations, tests et CI/CD (Partie 3) 
4. Sécurité, déploiement, maintenance (partie 4)

Lorsque vous aurez atteint le bas de cette deuxième partie, vous aurez.. :

• A Terrain de jeu Next.js 14, où les apprenants modifient le code dans le navigateur ;
• des tests Vitest en direct qui passent au vert (ou au rouge) en temps réel ; et
• A NestJS avec base de données SQL qui enregistre les progrès avec rien de plus qu'un UUID anonyme dans localStorage.

En cours de route, nous laisserons Devin générer sa propre liste de tâches, nous le regarderons jongler avec les tickets frontaux et dorsaux, et nous interviendrons lorsqu'il tombera sur des gremlins de configuration. Je vous montrerai où j'ai dépensé (et économisé) des ACU, ce que j'ai réparé à la main et comment maintenir l'efficacité des sessions.

Récapitulation et conditions préalables

Tout au long de cette série de tutoriels, nous travaillerons sur mon repo d'exercices fp-ts (autrefois) abandonné.

Le projet est une collection de petits défis destinés à enseigner des concepts de programmation fonctionnelle (comme Option, Either, etc.) en TypeScript. Pour l'instant, il s'agit d'un repo cloné et exécuté : les apprenants l'extraient, éditent les fichiers localement et exécutent les tests dans leur propre terminal.

L'objectif est de transformer ces exercices en un terrain de jeu interactif basé sur un navigateur, où les gens peuvent lire une explication, modifier le code dans un éditeur de page et voir les tests réussir (ou échouer) instantanément. Les apprenants auront également la possibilité de se connecter pour enregistrer leurs progrès.

Ce que nous avons accompli dans la première partie

Rappelez-vous que dans le premier tutoriel, nous :

• Modernisation de l'ancien repo de fp-ts : dernières dépendances, linting, vérifications de type.
• Connecté Devin à GitHub et prouvé qu'il peut ouvrir une pull request propre.

Outils locaux dont vous avez besoin pour la deuxième partie

Pour ce deuxième tutoriel, nous aurons besoin de :

• Node 20+ et npm 10 (avec prise en charge des espaces de travail dès le départ).
• Docker exécutant un conteneur PostgreSQL (ou une instance locale de PostgreSQL).

Paramètres recommandés pour Devin

Je recommande les paramètres suivants pour Devin :

• Fixez un plafond souple de 5 UCA par session dans Paramètres > Utilisation et limites; nous allons lancer une nouvelle session pour chaque phase.
• Gardez l'onglet timelapse visible pour faire une pause ou donner un coup de coude à Devin s'il s'arrête.

Laisser Devin rédiger le plan de match

J'ai pensé qu'il serait intéressant de commencer par tester les capacités de planification de Devin. J'ai créé une invite et j'ai demandé à Devin, à l'aide de la fonction "Ask" (actuellement gratuite en version bêta), de m'aider à planifier le travail que nous ferons aujourd'hui.

Prompt :

Je souhaite transformer mon repo Node + TypeScript existant fp-ts-exercises (actuellement des exercices CLI clonés et exécutés) en une plate-forme d'apprentissage basée sur un navigateur qui suit les progrès. 

Expérience cible : 

- Les apprenants ouvrent une application web Next.js, choisissent un exercice, éditent le code dans le navigateur et voient les tests Vitest réussir ou échouer instantanément. 

- Les progrès (les limaces terminées) sont stockés côté serveur et rechargés lors des visites ultérieures, mais nous n'ajoutons pas encore de comptes d'utilisateurs (utilisez un UUID anonyme stocké dans le navigateur). 

Je penche pour les choix technologiques : 

- Frontend : Next.js 14 (React 18, App Router) 

- Éditeur et gestionnaire de code : Sandpack + @vitest/browser 

- API : NestJS 13 avec @nestjs/graphql (Apollo Driver) 

- Base de données : Prisma 5 avec PostgreSQL 

- Espace de travail : espaces de travail npm ordinaires (apps/web, apps/api, packages/exercices) 

Proposez un plan de mise en œuvre étape par étape (liste de tâches) qui donne vie à cette tranche verticale. Estimez le coût relatif de l'ACU pour chaque tâche et signalez toute étape de longue durée (par exemple, les grandes migrations ou les installations de dépendances lourdes).

Devin nous a utilement renvoyé une liste de tâches en six phases avec des estimations d'ACU pour chacune d'entre elles, et a signalé les étapes "d'installation à forte dépendance".

Réponse de Devin :

Phase 1 : Configuration de l'espace de travail (2-3 ACU)

• Initialiser la structure de l'espace de travail npm (1 ACU)
• Créer apps/web, apps/apiet packages/exercices les répertoires
• Configurez la racine package.json avec les définitions de l'espace de travail
• Déplacez les fichiers d'exercices existants vers paquets/exercices/src/
• Configurer Next.js 14 frontend (1-2 ACU - Long-running : dependency install)Initialiser Next.js avec App Router dans apps/webConfigurer TypeScript et Tailwind CSSConfigurer la structure de routage de base

Phase 2 : Migration du paquet d'exercices (3-4 ACU)

• Extraction du contenu de l'exercice vers le paquet partagé (2 ACU)
• Créer paquets/exercices avec extraction des métadonnées de l'exercice
• Analyser les fichiers d'exercices existants pour les extraire :
• Instructions
• Code de démarrage
• Solutions
• Définir des interfaces TypeScript pour la structure de l'exercice
• Mise en œuvre du système de découverte des exercices (1-2 ACU)
• Construire un scanner de système de fichiers (comme fs.readdirSync dans exercise.js:17-28)
• Exporter les métadonnées de l'exercice : titre, description, difficulté, essais

Phase 3 : API backend (4-5 ACU)

• Configurer l'API NestJS avec GraphQL (2 ACU - Longue durée : installation des dépendances)
• Initialiser le projet NestJS dans apps/api
• Configurer le serveur Apollo GraphQL
• Configuration des points d'extrémité du bilan de santé de base
• Implémenter Prisma + PostgreSQL (2 ACU - Longue durée : mise en place de la base de données)
• Schéma de conception pour :
• Sessions d'utilisateurs
• Exercices terminés
• Mise en place du client Prisma et des migrations
• Créer des curseurs de suivi de l'avancement des travaux
• Gestion des sessions d'utilisateurs anonymes (1 ACU)
• Générer un UUID et le stocker dans le navigateur localStorage
• Activer la persistance de la progression basée sur la session sans authentification

Phase 4 : Fonctionnalités de base du Frontend (5-6 ACU)

• Interface navigateur d'exercice (2 ACU)
• Liste des exercices par catégorie (option, soit, tâcheetc.)
• Montrer les indicateurs de progrès et l'état d'avancement des travaux
• Permettre la sélection et la navigation des exercices
• Intégration de l'éditeur de code Sandpack (2-3 ACU - En cours depuis longtemps : Installation d'un bac à sable (Sandpack setup)
• Configurer Sandpack avec le support TypeScript
• Chargez le code de démarrage et fp-ts dépendances
• Mise en place d'un système de fichiers pour les fichiers d'exercices et de tests
• Intégration du navigateur Vitest (1 ACU)
• Remplacer execSync Les appels à Vitest (exercise.js:45-47) par @vitest/browser
• Permettre l'exécution des tests en temps réel et l'affichage des résultats

Phase 5 : Curriculum vitae (2-3 ACU)

• Gestion de l'avancement des travaux côté client (1 ACU)
• Configuration du client Apollo pour GraphQL
• Synchronisation de la progression avec le backend
• Détection de l'achèvement de l'exercice (1-2 ACU)
• Adaptez la logique de détection de succès existante (exercice.js:48-49)
• Déclencher des mises à jour de la progression du backend en cas de réussite du test

Phase 6 : Polonais et déploiement (2-3 ACU)

• Améliorations UI/UX (1-2 ACU)
• Assurer une conception adaptée aux besoins
• Ajouter les états de chargement et la gestion des erreurs
• Améliorer l'affichage des instructions d'exercices
• Configuration du déploiement de la production (1 ACU)
• Configurez Docker pour les deux applications
• Gérer les variables d'environnement
• Mise en place du déploiement de la base de données

Coût total estimé : 18-24 ACU

Le plan était assez bon dans l'ensemble. J'ai changé certaines choses, notamment dans la phase six, puisque nous aborderons le déploiement dans le quatrième tutoriel.

Phase 1 : Espace de travail et échafaudage frontal

Objectif : Créez des espaces de travail npm, déplacez les fichiers existants et démarrez un shell Next.js 14 vierge.ACU burn : 3,66 (prévu 1-2).Résultat : Le repo contient maintenant /apps/web, partagé packages/exercises, et une application Next.js prête pour Tailwind fonctionnant sur localhost:3000.

L'invite

J'ai demandé à Devin de construire le plan qu'il a élaboré pour la première phase. Agentic Devin ne connaît pas le contexte de ce que vous avez pu demander précédemment dans la fonction "Ask Devin", vous devez donc créer une invite distincte et fournir le contexte. 

Je ne vais pas coller tous les messages dans cet article, mais voici le premier :

Prompt :

Tâche : Initialiser la structure de l'espace de travail npm et le frontend Next.js pour la plate-forme de navigation fp-ts-exercicesContexte :

Je suis en train de convertir mon système d'apprentissage basé sur l'interface de programmation fp-ts-exercices en une plateforme basée sur un navigateur. Le système actuel a des exercices organisés dans 10-from-either.exercise.ts:1-3 avec la configuration TypeScript dans tsconfig.json:88 et la configuration Vitest dans vitest.config.ts:7 .

Exigences :

• Créez la structure de l'espace de travail npm :
• Package.json racine avec la configuration de l'espace de travail pour apps/web, apps/api, packages/exercices
• Déplacez les fichiers d'exercices existants de l'actuel src/ vers packages/exercises/src/.
• Conservez la convention de dénomination des fichiers d'exercices actuels (.exercise.ts et .solution.ts).
• Initialisez Next.js 14 frontend dans apps/web :
• Utilisez App Router (et non Pages Router)
• Configurez TypeScript avec des paramètres stricts similaires à ceux de la version actuelle tsconfig.json:88
• Ajoutez le CSS de Tailwind pour le style
• Créer une structure de routage de base pour l'exercice de navigation
• Maintenir la compatibilité :
• S'assurer que la structure de l'exercice et les importations existantes fonctionnent toujours
• Maintenir les dépendances fp-ts accessibles dans l'espace de travail
• Préserver les modèles de configuration actuels de Vitest

Produits livrables :

• Package.json configuré dans l'espace de travail à la racine
• Application Next.js dans apps/web/ avec TypeScript et Tailwind
• Exercices migrés dans packages/exercices/
• Structure de routage de base (/exercices, /exercices/[catégorie], /exercices/[catégorie]/[slug])

Pile technologique :

• Next.js 14 avec App Router
• TypeScript (mode strict)
• Tailwind CSS
• espaces de travail npm (pas yarn/pnpm)

Soumission :

• S'assurer que les scripts lint et typecheck passent
• Créez un PR avec vos changements

Tous les messages que j'ai rédigés par la suite suivaient le même schéma : mise en évidence de la tâche, contexte, exigences, résultats attendus, paquet technologique et détails de la soumission.

Ce que Devin a réellement fait

Il a mis un certain temps à décider de son action (environ quatre minutes), mais il l'a fait :

1. Création du squelette de l'espace de travail
2. Migration de tous les dossiers d'exercices vers packages/exercises/src.
3. Bootstrapped Next.js 14 avec l'App Router, TypeScript et Tailwind.
4. Ajout des scripts lint et type-check à l'application frontend (après que je l'ai poussé).

Pourquoi le coût de l'ACU a-t-il augmenté ?

Le coût de l'ACU a augmenté parce que :

• Devin a passé une minute entière à tourner en boucle sur npm install après un délai d'attente du miroir.
• Il a tenté d'arrêter le serveur devs et les processus avec q dans Vim, puis Ctrl-C, et les deux ont échoué. Je lui ai laissé un peu de temps pour essayer de résoudre le problème lui-même, mais j'ai fini par intervenir manuellement et quitter les processus les deux fois. Chaque minute supplémentaire signifiait des UCA supplémentaires, et je n'aurais pas détecté ce problème rapidement si je n'avais pas suivi de près les actions de Devin.

Interventions humaines et enseignements tirés

Voici un résumé des corrections que j'ai dû apporter:

Le déplacement de grandes arborescences de fichiers est plus rapide à la main, et beaucoup moins coûteux puisque Devin facture au temps/tâche. J'ai déplacé les dossiers, je les ai validés et j'ai laissé l'agent prendre en compte la nouvelle structure. Il a été capable d'extraire mes modifications sans problème et de faire une fusion tout seul !

Cela dit, j'ai dû lui demander d'exécuter les scripts lint et typecheck, même si je l'avais spécifié dans mon invite initiale. En fin de compte, il les a fait fonctionner tous les deux, mais ils ont échoué. Devin a tout de même considéré qu'il s'agissait d'un succès et s'est rallié à la RP.

J'ai corrigé les deux problèmes localement, j'ai exécuté les scripts moi-même et j'ai lancé le nouveau serveur de développement web pour m'assurer qu'il démarrait comme prévu, et j'ai poussé le commit.

Phase 2 : Emballage des exercices

Objectif :  Extraire tous les fichiers d'épreuves dans un paquetage réutilisable packages/exercises et générer des métadonnées pour chaque exercice.ACU burn :  0,6 (prévu 2+).Résultat : Le paquet partagé exporte des métadonnées typées que l'application web et la future API peuvent importer à l'adresse import { exercises } from '@exercises/registry'.

Ce que Devin a réellement fait

Devin a créé :

• Interfaces TypeScript structurées pour les exercices, les métadonnées, les catégories et le catalogue complet.
• Analyseur d'exercices que :
• Extraction de métadonnées à partir de commentaires de code et de signatures de fonctions
• Analyse le code de départ, le code de la solution et les cas de test Vitest.
• Génération automatique de balises à partir de l' utilisation de fp-ts
• Convertit les noms en camelCase en titres lisibles
• Système de découverte d'exercices que :
• Recherche dans le système de fichiers les paires .exercise.ts et .solution.ts
• Construit un catalogue basé sur les mots-clés (par exemple, option-01 ).
• Organise les exercices par catégorie avec mise en cache pour plus de performance
• Des exportations pratiques pour l'interrogation des exercices et des catégories :
• getExercises(), getExerciseBySlug(), getExercisesByCategory(), getCategories(), getCategoryBySlug()

Pourquoi Devin a terminé en dessous du budget

Devin a réussi à maintenir le coût de l'ACU à un niveau peu élevé - voici comment il y est parvenu :

• Pas d'installation lourde ni d'appel au réseau
• Les déplacements de fichiers étaient simples ; Devin a utilisé git mv (bon marché) au lieu de copier-coller plus diff
• La génération de métadonnées est purement TypeScript, rapide à planifier et à exécuter.

Interventions humaines

Aucune cette fois-ci !

Tirant les leçons de la dernière fois, j'ai consulté la branche de Devin et j'ai exécuté les scripts localement. Tout a été compilé et le registre exporte des définitions de types propres, ce qui en fait un matériau d'entrée parfait pour l'interface utilisateur et l'API que nous construirons ensuite.

Phase 3 : NestJS + GraphQL API

Objectif : Créez un service NestJS 13 qui expose la progression de l'exercice via GraphQL et persiste les données dans PostgreSQL avec Prisma.ACU burn : 4.2 (prévu 4).Résultat : apps/api bottes sur localhost:4000/graphql. Vous pouvez interroger et modifier les enregistrements de progression en fonction d'un identifiant de session anonyme.

Ce que Devin a réellement fait

Pour la troisième phase, Devin :

1. Création d'une API NestJS complète sur apps/api avec TypeScript et Apollo GraphQL
2. Intégration de PostgreSQL avec Prisma ORM et mise en place d'un schéma avec les modèles Session et CompletedExercise
3. Mise en place d'une gestion de session anonyme utilisant les UUID (aucune authentification requise)
4. Construit des résolveurs GraphQL pour la création/validation de sessions, les requêtes d'exercices et le cursus.
5. Connexion du backend à l'exercise package partagé (packages/exercises ) pour la découverte des données
6. Configuration de CORS pour supporter la communication avec le frontend Next.js
7. Assurer la compatibilité de type entre le schéma GraphQL et les interfaces TypeScript existantes.
8. Mise en place de scripts de développement, de flux de migration de base de données et d'intégration de Prisma Studio.

Où Devin a trébuché

Voici les problèmes que j'ai rencontrés au cours de la troisième phase et les corrections que j'ai dû apporter :

Enseignements tirés

Voici ce que j'en retiens :

• Config vs. code : Devin excelle une fois que le modèle de base du framework est en place, mais le diagnostic des problèmes de dépendance nécessite toujours un œil humain.
• Exécutez toujours le programme localement : J'avais déjà créé une base de données PostgreSQL locale sur ma machine, et les instructions de PR pour exécuter la migration Prisma et démarrer l'environnement de développement étaient claires et faciles à suivre (voir l'image ci-dessous). Le commentaire de Devin indique qu'il a réussi à exécuter l'API localement, mais npm run dev s'est planté jusqu'à ce que reflect-metadata soit ajouté.

• Devin sait gérer les commentaires des relations publiques. J'ai commenté le PR, expliquant à Devin que j'avais essayé d'exécuter l'API localement et que j'avais rencontré une erreur. J'ai immédiatement vu un petit émoji "œil", et la session a repris d'elle-même pour corriger l'erreur, qui a été corrigée quelques minutes plus tard.

• Vérifiez toujours la présence de fichiers secrets : Devin avait créé un fichier .env avec une variable DATABASE_URL, qui contenait un nom d'utilisateur et un mot de passe fictifs. Une fois tiré localement, j'ai changé le nom d'utilisateur et le mot de passe pour mes identifiants de base de données locale et je me suis assuré de supprimer le fichier du système de suivi git et de l'ajouter au site .gitignore. Nous verrons dans les prochains tutoriels comment manipuler les secrets en toute sécurité.

Phase 4 : Sandpack Playground & Live Tests

Objectif : Offrez aux apprenants un éditeur de navigateur qui exécute les solutions fp-ts et les contrôles Vitest en temps réel.Brûlure ACU : 7.2 (prévu 3-4).Résultat : La visite de /exercises/option-01 ouvre une vue fractionnée : L'éditeur Sandpack à gauche, le tunnel de test à droite, et un message de réussite s'affiche lorsque toutes les spécifications sont satisfaites.

Ce que Devin a réellement fait

Voici ce que Devin a fait pour la quatrième phase :

• Des pages d'inscription et de navigation construites pour l'exercice, avec prise en charge de catégories et d'éléments dynamiques.
• Editeur Sandpack intégré avec TypeScript, fp-ts et prise en charge du système de fichiers en temps réel
• Remplacement de l'exécution des tests CLI par Vitest dans le navigateur et retour d'information en direct
• Connexion du frontend au backend via Apollo Client pour un suivi des progrès par session.
• Implémentation d'une interface utilisateur réactive avec des états de chargement et une gestion des erreurs

Où Devin a brûlé des UCA supplémentaires

Devin a brûlé plus d'UCA que prévu pour cette phase - voici pourquoi :

Enseignements tirés

Voici ce que j'en retiens cette fois-ci :

• Regarder en silence = brûler de l'argent. Gardez l'onglet Timelapse ouvert, et si Devin fait une boucle, donnez-lui un coup de coude ou mettez-le en pause.
• Supprimez rapidement les codes morts. Devin ne supprime pas vraiment le code périmé de lui-même, à moins que vous ne le lui demandiez. J'ai fait l'erreur de lui demander de déplacer des fichiers sans que ne lui diseexplicitement de les supprimer, et nous nous sommes donc retrouvés avec de multiples points d'entrée qui ont grandement déconcerté le pauvre Devin dans cette phase.

Devin a pris un peu de temps ici. Il a tourné en boucle, essayant de résoudre les mêmes problèmes, ne connectant pas correctement le backend et le frontend, apportant des modifications, redémarrant les serveurs, vérifiant dans le navigateur si cela fonctionnait, etc. Il s'agissait d'un travail de développement ordinaire, je suppose...

Nous avons maintenant une application fonctionnelle. J'ai pu lancer les serveurs API et Web, naviguer vers localhost, modifier la fonction stub, appuyer sur Save et regarder le volet de test passer du rouge au vert. J'ai ensuite réalisé qu'il ne faisait le travail qu'à moitié et qu'il codait en dur le test et la solution du premier exercice sur chaque page d'exercice. Je l'ai signalé, et après d'autres boucles, il a pu le corriger et pousser ses correctifs.