Générer des tâches et implémenter du code

Effectué

Les plans techniques fournissent une orientation architecturale, mais l’implémentation nécessite des étapes concrètes et exploitables. Cette unité couvre les techniques avancées de génération et de gestion des tâches pour les scénarios d’entreprise.

Examiner les principes fondamentaux des tâches

La commande de /speckit.tasks GitHub Spec Kit convertit les décisions architecturales de haut niveau en éléments de travail spécifiques dans le fichier tasks.md. Chaque tâche représente une unité de travail discrète qui peut être implémentée, testée et vérifiée indépendamment.

Caractéristiques clés des tâches bien définies :

• Actionnable : indique clairement ce qui doit être fait.
• Testable : la vérification de l’achèvement est simple.
• Indépendant : peut être terminé sans attendre des travaux non liés.
• À durée déterminée: Peut être effectué dans un délai raisonnable (de quelques heures à une journée).

Organisation basée sur des phases

Les fonctionnalités complexes bénéficient de l’organisation des tâches en phases. Par exemple : Configuration, Foundation, Core Functionality, UI/Integration, Security et Testing. Chaque phase représente un regroupement logique qui s’appuie sur un jalon.

Avantages de la répartition des tâches

Les répartitions de tâches servent à plusieurs fins au-delà de l’organisation du travail. Ils aident l’IA à générer du code ciblé pour des objectifs spécifiques plutôt que de tenter d’implémenter des fonctionnalités entières dans des opérations uniques. Ils créent des points de vérification naturels où vous pouvez tester des implémentations partielles avant de continuer. Ils permettent un suivi précis de la progression en affichant exactement ce qui est complet et ce qui reste. Ils facilitent la coordination des équipes en rendant les dépendances explicites.

Pour la fonctionnalité de chargement de document, le plan décrit l’architecture globale et les choix technologiques. La liste des tâches traduit les décisions architecturales en actions spécifiques : créez une table de base de données, implémentez un point de terminaison d’API, générez un composant React, ajoutez une logique de validation, écrivez des tests. Chaque tâche est assez petite pour se terminer dans un délai raisonnable, tandis qu’elle est suffisamment grande pour représenter une progression significative.

Examiner la structure et l’organisation des tâches

Une liste de tâches bien structurée organise le travail de manière logique, séquence les dépendances de manière appropriée et fournit des directives claires pour l'implémentation.

Organisation basée sur des phases

Les fonctionnalités complexes bénéficient d’une organisation basée sur des phases. Chaque phase représente un regroupement logique de tâches associées qui s’appuient sur un jalon spécifique.

Pour la fonctionnalité de chargement de document, une structure de phase classique peut inclure :

• Phase 1 : Fondation et configuration

  • Configurez la configuration de la connexion stockage Blob Azure dans appsettings.json.
  • Créez la table DocumentMetadata dans la base de données SQL avec un schéma approprié.
  • Ajoutez le package NuGet Azure.Storage.Blobs au projet back-end.
  • Créez la classe DocumentService qui encapsule les opérations de stockage.

• Phase 2 : Fonctionnalité de chargement de base

  • Implémentez le point de terminaison POST /api/documents/upload dans DocumentsController.
  • Ajoutez une logique de validation de fichier (taille, type) à DocumentService.
  • Implémentez une méthode de chargement du Stockage Blob avec gestion des erreurs.
  • Enregistrez les métadonnées de document dans la base de données après le chargement réussi.
  • Retournez au client le résultat du chargement contenant l’ID de document et l’URL.

• Phase 3 : Implémentation frontale

  • Créez un composant React DocumentUpload avec une entrée de fichier.
  • Ajoutez la taille de fichier et la validation de type dans le composant.
  • Implémenter l’indicateur de progression du chargement.
  • Gérez les réponses de réussite et d’erreur lors du chargement.
  • Actualisez la liste des documents après le chargement réussi.

• Phase 4 : Sécurité et validation

  • Ajoutez une vérification d’authentification d’ID Microsoft Entra au point de terminaison de chargement.
  • Implémentez la validation de type de fichier côté serveur à l’aide de nombres magiques.
  • Ajoutez des limites de taille de requête qui empêchent les attaques DoS.
  • Validez les extensions de fichier par rapport à une liste autorisée.
  • Ajoutez la journalisation d’audit pour les opérations de chargement.

• Phase 5 : Test et documentation

  • Écrire des tests unitaires pour les méthodes de chargement DocumentService.
  • Créez un test d’intégration pour un flux de chargement complet.
  • Ajouter des tests de scénario d’erreur (type de fichier non valide, taille dépassée).
  • Point de terminaison d’API de document dans OpenAPI/Swagger.
  • Mettez à jour la documentation utilisateur avec des instructions de chargement.

Cette approche par phases crée des jalons naturels. Après la phase 2, vous disposez d’un back-end opérationnel mais minimal. Après la phase 3, les utilisateurs peuvent charger des fichiers. Après la phase 4, le système est sécurisé et prêt pour la production. Après la phase 5, tout est testé et documenté.

Granularité et étendue des tâches

Chaque tâche doit être correctement délimitée , spécifique suffisamment pour fournir une direction claire, mais pas si détaillée qu’elle devient un micromanagement prescriptif.

Les tâches bien étendues partagent ces caractéristiques :

• Actionnable : la tâche indique clairement ce qui doit être fait.
• Testable : vous pouvez vérifier quand la tâche est terminée.
• Indépendant dans la mesure du possible : la tâche peut être effectuée sans attendre les travaux non liés.
• Limitée dans le temps : un développeur peut effectuer la tâche dans un délai raisonnable (généralement des heures à un jour, et non des semaines).

Exemple de tâche bien étendue : « Implémenter le point de terminaison POST /api/documents/upload qui accepte les chargements de fichiers à plusieurs parties, valide que la taille du fichier est inférieure à 50 Mo, stocke le fichier dans Stockage Blob Azure et retourne l’URL de l’objet blob et l’ID de document ».

Cette tâche est spécifique à ce qu'il faut créer (un point de terminaison), à ce qu'elle accepte (des fichiers multi-parties), aux validations à appliquer (limite de taille), à l'emplacement où stocker les fichiers (Stockage Blob Azure) et à ce qu'il faut retourner (URL et ID). Un développeur sait exactement ce qu’il faut implémenter.

Voici un exemple de tâche insuffisante : « Effectuer le travail de chargement ». Cet exemple ne fournit aucune aide exploitable sur ce que signifie « travail » ou sur les composants impliqués.

Voici un exemple de tâche trop prescriptive : « À la ligne 47 de DocumentsController.cs, ajoutez une méthode nommée UploadDocument avec des paramètres (fichier IFormFile, string userId) et implémentez-la à l’aide exactement de ces étapes... » Cette description de tâche supprime l’agence des développeurs et ne tient pas compte de l’évolution de la structure du code.

Dépendances et séquencement des tâches

L’ordre des tâches importe. Certaines tâches doivent être effectuées avant que d’autres puissent commencer.

Les modifications de schéma de base de données sont généralement apportées en premier, car le code principal dépend de l’existence du schéma. Les points de terminaison d'API back-end précèdent les composants frontaux qui appellent ces points de terminaison. La configuration précède le code qui utilise cette configuration. Le test se produit après que le code testé existe.

La liste des tâches doit séquencer le travail pour réduire le blocage. Si les tâches frontales et principales sont indépendantes, elles peuvent continuer en parallèle. Si plusieurs points de terminaison principaux existent, les développeurs peuvent implémenter les tâches simultanément.

Pour la fonctionnalité de chargement de document, la séquence logique garantit :

1. La configuration et la configuration de la base de données se produisent en premier (aucune dépendance).
2. L’implémentation de l’API principale suit la configuration de la base de données (dépend du schéma).
3. Les composants frontaux suivent l’implémentation de l’API (dépendent des points de terminaison existants).
4. Le renforcement de la sécurité se produit après la fonctionnalité principale (dépend du code existant).
5. Les tests se produisent après toute l’implémentation (dépend du code terminé).

Cette séquence de tâches permet une progression continue sans attendre la fin du travail non lié.

Générer des tâches à l’aide de /speckit.tasks

GitHub Spec Kit génère des listes de tâches via la /speckit.tasks commande dans GitHub Copilot Chat. Cette commande traite à la fois spec.md et plan.md pour produire une liste complète et triée des tâches d’implémentation.

L’IA analyse la spécification pour comprendre ce qui doit être généré, passe en revue le plan pour comprendre l’approche architecturale et génère des tâches qui permettent de combler l’écart entre ces documents et le code réel. Le fichier tasks.md résultant contient des tâches numérotées ou à puces, souvent structurées en phases pour les fonctionnalités complexes.

Appeler la commande de génération de tâches

Ouvrez GitHub Copilot Chat dans Visual Studio Code et entrez /speckit.tasks. GitHub Copilot traite la spécification et planifie la génération d’une liste de tâches structurée. Le processus de génération se termine généralement dans quelques instants, produisant une répartition complète du travail d’implémentation.

La liste des tâches hérite automatiquement du contexte de votre spécification et de votre plan. Si le plan spécifie « utiliser Stockage Blob Azure », les tâches générées incluent des étapes spécifiques pour la configuration des connexions au Stockage Blob, l’implémentation de la logique de chargement ainsi que la gestion des erreurs de stockage.

Vérifier et valider la liste des tâches

La liste des tâches nécessite une révision critique pour garantir l’exactitude et l’exhaustivité.

Vérifier la couverture des éléments de plan

Comparez tasks.md systématiquement à plan.md. Chaque étape de décision et d’implémentation architecturale du plan doit correspondre à une ou plusieurs tâches.

Si le plan spécifie « implémenter la validation côté serveur », les tâches spécifiques doivent couvrir la validation du type de fichier, la validation de la taille de fichier et la gestion des réponses aux erreurs. Si le plan mentionne « journalisation d’audit », une tâche doit traiter la création d’entrées de journal pour les opérations de chargement.

Les tâches manquantes indiquent des éléments de génération ou de plan incomplets qui ne se traduisent pas en travail concret. Résolvez ce problème en ajoutant manuellement des tâches ou en fournissant plus de contexte et de régénération.

Rechercher les lacunes logiques

Recherchez les lacunes de fonctionnalités qui ne sont pas évidentes du plan, mais deviennent apparentes lors de l’examen des détails de l’implémentation.

Les lacunes courantes sont les suivantes :

• Gestion des erreurs : existe-t-il des tâches pour gérer les erreurs réseau, les échecs de stockage ou les problèmes de base de données ?
• Cas limites : Que se passe-t-il lorsque les utilisateurs téléversent des fichiers avec des noms identiques ? Comment les chargements simultanés sont-ils gérés ?
• Configuration : Les chaînes de connexion, les clés API et les points de terminaison de service sont-ils correctement configurés ?
• Commentaires des utilisateurs : Comment les utilisateurs savent-ils quand les chargements sont terminés ou échouent ?
• Nettoyage des données : si un chargement réussit partiellement, échoue, le nettoyage est-il géré ?

Identifiez ces lacunes lors de l’examen et ajoutez les tâches appropriées avant le début de l’implémentation.

Évaluer l’ordre des tâches et les dépendances

Vérifiez que les tâches sont correctement séquencées. Les tâches de schéma de base de données doivent précéder le code qui accède à ces tables. Les tâches de point de terminaison d’API doivent précéder les composants frontaux qui appellent ces points de terminaison.

Si vous trouvez des tâches hors ordre, resequencez-les manuellement. Par exemple, si une tâche frontale apparaît avant la tâche principale correspondante, déplacez-la vers la phase appropriée.

Envisagez les dépendances entre les tâches au sein de la même phase. Si la sortie d’une tâche est requise pour une autre tâche, vérifiez que la première tâche apparaît plus haut dans la séquence.

Valider la granularité des tâches

Vérifiez que chaque tâche est correctement étendue. Les tâches trop volumineuses (« implémenter l’intégralité du back-end ») doivent être divisées en éléments plus petits et gérables. Les tâches trop petites (« ajouter des points-virgules à la ligne 42 ») doivent être combinées en unités plus significatives.

Une tâche bien délimitée prend généralement quelques heures à un jour pour être complétée, peut être testée indépendamment et produit une progression démontrable.

Utiliser des tâches pour guider l’implémentation

Une fois validée, tasks.md devient votre feuille de route d’implémentation.

Progression systématique par le biais de tâches

Parcourez les tâches dans l’ordre, en effectuant chacune d’elles avant de passer à la suivante. Cette approche disciplinée garantit que rien n’est ignoré et fournit des indicateurs de progression clairs.

À mesure que vous effectuez chaque tâche :

1. Implémentez les fonctionnalités requises.
2. Testez l’implémentation pour vérifier l’exactitude.
3. Marquer la tâche comme terminée (ajoutez une case à cocher ou barrer le texte).
4. Validez vos modifications avec une référence à la tâche.

Cette approche systématique crée une liaison claire de piste d’audit entre le travail terminé et des tâches spécifiques.

Suivre la progression et communiquer l’état

La liste des tâches fournit une mesure objective de la progression. Si 15 de 30 tâches sont terminées, la fonctionnalité est d’environ 50% implémentées. Cette métrique permet de planifier des projets et de communiquer avec les parties prenantes.

Partagez tasks.md avec votre équipe pour communiquer ce qui est complet et ce qui reste. Les membres de l’équipe peuvent voir en un clin d’œil quels domaines ont besoin d’attention et où mettre l’accent sur les efforts de révision.

Adapter les tâches pendant l’implémentation

Si l’implémentation révèle de nouvelles exigences ou de meilleures approches, mettez à jour tasks.md en conséquence. La liste des tâches doit refléter la réalité, et non un plan obsolète.

Distribuer des tâches entre les membres de l’équipe

Des définitions claires de tâches permettent la distribution du travail entre plusieurs développeurs. L’équipe principale peut travailler sur des tâches d’API tandis que l’équipe frontale génère des composants d’interface utilisateur. Les administrateurs de base de données peuvent configurer des schémas pendant que les développeurs préparent la configuration.

L’appel explicite des dépendances de tâche permet d’empêcher le blocage. Si la tâche B dépend de la tâche A, vérifiez que la tâche A est affectée et hiérarchisée de manière appropriée. Critères de réalisation des tâches documentaires afin d'assurer des transitions fluides.

Générer du code à l’aide de /speckit.implement

La /speckit.implement commande utilise tasks.md pour générer du code systématiquement. Au lieu de tenter d’implémenter des fonctionnalités entières en une seule passe, l’IA fonctionne de manière séquentielle via des tâches. Cette approche produit du code plus ciblé et correct.

Vous pouvez appeler /speckit.implement avec un numéro de tâche spécifique, une plage de tâches ou une description de l’implémentation extraite du fichier tasks.md. L’IA fait référence spec.md, plan.md et tasks.md pour produire du code qui s’aligne sur l’architecture et les exigences globales.

Par exemple, pour implémenter le point de terminaison de chargement de document, vous pouvez entrer :

/speckit.implement Implement the MVP first strategy (Tasks: T001 - T027)

Cette commande demande à l’IA de se concentrer sur les tâches T001 à T027, générant du code qui répond aux exigences de chaque tâche en séquence.

Fournir de l’aide pendant l’implémentation

L’IA peut nécessiter une assistance ou une autorisation pour poursuivre certaines tâches. Par exemple, si une tâche nécessite la création ou l’exécution de l’application, l’IA peut demander la confirmation avant de continuer.

En outre, l’IA peut détecter un bogue lors du test de l’implémentation d’une tâche. Fournissez des informations détaillées pour vous aider à diagnostiquer le problème. Vous pouvez également fournir un contexte ou des clarifications supplémentaires si l’IA rencontre des ambiguïtés.

Lorsque vous êtes invité à obtenir de l’aide dans l’affichage Conversation, une réponse rapide permet de maintenir l’implémentation en douceur.

Points de contrôle de vérification

Après avoir terminé une commande d’implémentation, vérifiez les résultats avant de continuer. Exécutez l’application, exécutez des tests et vérifiez que chaque tâche est implémentée et que son objectif est atteint. Cette vérification incrémentielle intercepte les problèmes dès qu’ils sont plus faciles à résoudre.

Maintenance de contexte entre les tâches

À mesure que vous progressez dans les tâches, le travail précédemment terminé fournit un contexte pour les tâches suivantes. L’IA peut référencer des implémentations antérieures lors de la création de fonctionnalités connexes, améliorer la qualité du code et maintenir la cohérence architecturale.

Gérer les défis liés aux tâches lors de l’implémentation

Les défis courants surviennent lors de la gestion des tâches d’implémentation.

Tâches qui augmentent dans l’étendue

Lorsqu’une tâche révèle une complexité inattendue lors de l’implémentation, suspendez et réévaluez. Décomposez la tâche gonflée en plusieurs tâches plus petites. Mettez à jour tasks.md pour refléter la portée réelle. Communiquez l’expansion de l’étendue aux parties prenantes.

Tâches bloquées

Les tâches deviennent parfois bloquées par des dépendances externes. Marquer les tâches bloquées explicitement dans tasks.md avec des raisons de bloc : « BLOCKED : Attente de l’approvisionnement de conteneurs stockage Blob Azure - ticket #1234 ». Effectuez le suivi des tâches bloquées séparément pour vous assurer qu’elles ne sont pas oubliées.

Changement des priorités

Les besoins métier évoluent. Lorsque les priorités changent, mettez à jour tasks.md en conséquence. Réorganisez vos tâches d’une manière qui reflète les nouvelles priorités. Ajoutez de nouvelles tâches pour les exigences émergentes. Envisagez de différer ou de supprimer des tâches qui ne sont plus précieuses.

Ambiguïté des tâches détectée lors de l’implémentation

Lorsque l’ambiguïté s’affiche, suspendez l’implémentation et recherchez des clarifications. Passez en revue la spécification et prévoyez de comprendre l’intention d’origine. Mettez à jour la description de la tâche avec une langue spécifique et non ambiguë avant de continuer.

Résumé

La génération de tâches transforme les plans architecturaux en étapes d’implémentation actionnables. Générez des listes de tâches en utilisant /speckit.tasks pour créer des répartitions structurées et basées sur des phases du travail d’implémentation. Passez en revue les tâches générées de manière critique pour garantir une couverture complète, un séquencement logique et une granularité appropriée. Utilisez la liste des tâches validée pour guider l’implémentation systématique, suivre la progression et coordonner les efforts de l’équipe.

La combinaison de spec.md, de plan.md et de tasks.md crée un framework de développement complet. La spécification définit ce qui doit être construit et pourquoi. Le plan définit comment le construire selon une perspective architecturale. Les tâches définissent les étapes spécifiques pour exécuter la build. Ensemble, ces artefacts transforment les exigences ambiguës en travaux de développement concrets et suivis qui maintiennent l’alignement avec les objectifs du projet tout au long de l’implémentation.