Skip to main content

Créer un outil de suivi des congés de l'équipe

Décrivez votre outil et Devin le conçoit, le teste et le valide de bout en bout.
AuthorCognition
CategoryDéveloppement de fonctionnalités
1

(Facultatif) Définir la portée de la base de code avec Ask Devin

Si vous disposez déjà d’outils internes dans votre application, utilisez Ask Devin pour comprendre les modèles existants avant de rédiger votre spécification. C’est particulièrement utile si vous voulez que le nouvel outil respecte l’architecture de ce qui est déjà en place :Utilisez les réponses pour compléter votre spécification avec des références de fichiers précises, des noms de composants et des modèles, afin que Devin crée quelque chose de cohérent avec vos outils existants. Vous pouvez également démarrer une session Devin directement depuis Ask Devin, et il conservera tout ce qu’il a appris comme contexte.
2

Rédigez une spécification détaillée

Les outils internes — outils de suivi du PTO, panneaux d’administration, scripts de données, utilitaires CLI — sont essentiels mais rarement prioritaires. Ils sont idéaux pour Devin, car les exigences sont bien définies, le public est votre équipe, et « ça fonctionne correctement » compte plus qu’un design au pixel près.Soyez précis quant à ce que fait l’outil, quelles données il stocke et à quels services il se connecte. Plus vous fournissez de détails, plus la première version sera proche de ce dont vous avez besoin.Vous pouvez aussi itérer sur votre spécification avec Ask Devin — collez un brouillon et demandez-lui d’identifier les lacunes ou de suggérer des améliorations en fonction de votre base de code.
3

Ajouter des identifiants

Transmettez toutes les API keys ou tokens dont Devin a besoin via Secrets — dans ce cas, l’URL du webhook Slack.L’approche la plus simple consiste à les stocker en tant que secrets d’organisation avant de démarrer la session :
  1. Allez dans Settings > Secrets et ajoutez SLACK_WEBHOOK_URL
  2. Devin accède aux secrets en tant que variables d’environnement, afin qu’ils ne se retrouvent jamais écrits en dur dans votre code source.
Les secrets d’organisation doivent être ajoutés avant de démarrer la session — ils sont injectés au démarrage de la session. Vous pouvez aussi fournir des secrets pendant la session via le chat, et Devin vous demandera de manière proactive toutes les informations d’identification dont il a besoin lorsqu’il rencontre des variables d’environnement manquantes.
4

Guidez la session à l’aide de commandes slash

Une fois la session démarrée, vous pouvez utiliser des commandes slash pour orienter le workflow de Devin :
  • /plan — Demandez à Devin de créer un plan de mise en œuvre détaillé avant d’écrire le moindre code. Passez le plan en revue et suggérez des modifications avant qu’il ne se lance dans le développement.
  • /test — Dites à Devin d’exécuter tous les tests et de vérifier son travail. Utilisez cette commande après chaque étape majeure pour détecter rapidement les problèmes.
  • /review — Demandez à Devin de relire son propre code pour trouver des bugs, des cas limites et des problèmes de style avant d’ouvrir la pull request (PR).
Ces commandes fonctionnent à tout moment pendant la session : utilisez /plan au début, /test après la réalisation de chaque fonctionnalité et /review avant la PR finale.
5

Devin le crée et vérifie qu’il fonctionne

Devin traite les outils internes comme n’importe quelle fonctionnalité de production : il écrit le code, ajoute des tests, puis ouvre l’application dans son navigateur intégré pour vérifier que l’interface fonctionne de bout en bout.
  1. Analyse votre base de code — Trouve vos composants DataTable et Calendar, lit votre schéma Prisma et étudie la mise en page existante de la page /internal/
  2. Crée la migration de base de données — Ajoute les tables pto_requests et pto_balances via Prisma
  3. Construit les pages — Formulaire de soumission de demande, file d’attente d’approbation pour les managers, vue calendrier et tableau de bord des soldes sous /internal/pto
  4. Intègre Slack — Envoie des notifications webhook lorsque des demandes sont soumises et lorsqu’elles sont approuvées ou refusées
  5. Écrit les tests — Tests unitaires pour les calculs de solde de PTO et la détection de chevauchement de dates, tests d’API pour les endpoints de demande, tests d’intégration pour le flux d’approbation
  6. Ouvre l’application dans son navigateur — Navigue vers chaque page, soumet une demande de PTO de test, l’approuve depuis la vue manager, vérifie la mise à jour du calendrier, contrôle les chiffres du tableau de bord et teste les cas limites comme les dates qui se chevauchent et les dépassements de solde
  7. Ouvre une PR — Livre l’ensemble : migration, script de seed, code de l’application, tests et une section de README expliquant comment utiliser l’outil
La vérification dans le navigateur détecte des problèmes que les tests automatisés ne repèrent pas : des formulaires mal mis en page, un calendrier qui s’affiche mais ne réagit pas aux clics, ou un bouton de soumission qui ne réinitialise pas le formulaire après réussite.
6

Étendez votre outil

Once the base tool works, add features in follow-up sessions :
7

Passez en revue la PR avec Devin Review

Une fois que Devin a ouvert la PR, utilisez Devin Review pour examiner les modifications. Devin Review dispose du contexte complet de votre base de code et peut détecter des bogues, des problèmes de sécurité et des incohérences de style dans l’ensemble des changements.