Générateur de documents d’intégration pour l’architecture de la base de code
De Wikiprompt, l’encyclopédie libre de prompts
Générateur de documents d’intégration pour l’architecture de la base de code Invite système complet pour les assistants de codage IA afin d'analyser une base de code et de produire un document d'intégration technique détaillé couvrant l'architecture, la pile technologique, les flux, les tests, et plus encore.
Contenu du PromptEnregistrer
🌐
**Contexte :**
Je suis un développeur qui vient de rejoindre le projet et je vous utilise, vous, assistant de codage IA, pour acquérir une compréhension approfondie de la base de code existante. Mon objectif est de devenir productif le plus rapidement possible et de prendre des décisions techniques éclairées sur la base d'une compréhension solide du système actuel.
**Objectif principal :**
Analyser le code source fourni dans ce projet/espace de travail et générer un document Markdown détaillé, clair et bien structuré qui explique l'architecture du système, ses fonctionnalités, ses flux principaux, ses composants clés et sa pile technologique. Ce document doit servir de guide d'intégration technique. Dans la mesure du possible, améliorez la navigabilité en fournissant des liens directs vers les fichiers, classes et fonctions pertinents, ainsi que des exemples de code qui aident à clarifier les concepts.
---
## Instructions détaillées - Veuillez traiter les points suivants :
### 1. Résumé des fichiers README / Instructions
- Recherchez des fichiers tels que README.md, LEIAME.md, CONTRIBUTING.md ou une documentation similaire.
- Fournissez un résumé objectif mais détaillé des sections les plus pertinentes pour un nouveau développeur, notamment :
- Présentation du projet
- Comment configurer et exécuter le système localement
- Normes et conventions adoptées
- Directives de contribution (si disponibles)
---
### 2. Pile technologique détaillée
- Identifiez et listez la pile technologique complète utilisée dans le projet :
- Langage(s) de programmation, y compris les versions lorsqu'elles sont détectables (par exemple, à partir de package.json, pom.xml, .tool-versions, requirements.txt, build.gradle, etc.).
- Frameworks principaux (backend, frontend, etc. - par exemple, Spring Boot, .NET, React, Angular, Vue, Django, Rails).
- Base(s) de données :
- Type (SQL / NoSQL)
- Nom (PostgreSQL, MongoDB, etc.)
- Style d'architecture de base (par exemple, Monolithe, Microservices, Serverless, MVC, MVVM, Clean Architecture).
- Plateforme cloud (si identifiable via SDK ou configuration - AWS, Azure, GCP).
- Outils de build et gestionnaires de paquets (Maven, Gradle, npm, yarn, pip).
- Toute autre technologie pertinente (mise en cache, courtiers de messages, conteneurisation - Docker, Kubernetes).
- Référencez et liez les fichiers de configuration qui démontrent chaque élément.
---
### 3. Présentation du système et objectif
- Décrivez clairement ce que fait le système et à qui il s'adresse.
- Quels problèmes résout-il ?
- Listez les fonctionnalités de base.
- Si possible, reliez le système aux domaines métier concernés.
- Fournissez une description de haut niveau des principales fonctionnalités.
---
### 4. Structure du projet et recommandations de lecture
- Point d'entrée : Par où dois-je commencer à explorer le code ? Identifiez les principaux points d'entrée (par exemple, main.go, index.js, Program.cs, app.py, Application.java). Fournissez des liens directs vers ces fichiers.
- Organisation générale : Expliquez la structure globale des dossiers et fichiers. Mettez en évidence les conventions importantes. Utilisez des exemples réels de noms de dossiers et de fichiers.
- Configuration : Existe-t-il des fichiers de configuration principaux ? (par exemple, config.yaml, .env, appsettings.json) Quelles configurations sont critiques ? Fournissez des liens.
- Recommandation de lecture : Suggérez un ordre ou un ensemble de fichiers/modules clés qui devraient être lus en premier pour saisir rapidement les concepts fondamentaux du projet.
---
### 5. Composants clés
- Identifiez et décrivez les modules, classes, fonctions ou services les plus importants ou centraux.
- Expliquez les responsabilités de chaque composant.
- Décrivez leurs responsabilités et interdépendances.
- Pour chaque composant :
- Incluez un extrait de code représentatif
- Fournissez un lien vers l'endroit où il est implémenté
- Fournissez des liens directs et des exemples de code dans la mesure du possible.
---
### 6. Flux d'exécution et de données
- Décrivez les flux de travail ou processus métier les plus courants ou critiques (par exemple, traitement des commandes, authentification des utilisateurs).
- Expliquez comment les données circulent dans le système :
- Où les données sont persistées
- Comment elles sont lues, modifiées et propagées
- Dans la mesure du possible, illustrez avec des exemples et liez aux fonctions ou classes pertinentes.
#### 6.1 Aperçu du schéma de base de données (si applicable)
- Pour les applications axées sur les données :
- Identifiez les principales entités/tables/collections
- Décrivez leurs relations principales
- Basez-vous sur les modèles ORM, les migrations ou les fichiers de schéma si disponibles
---
### 7. Dépendances et intégrations
- Dépendances : Listez les principales bibliothèques externes, frameworks et SDK utilisés. Expliquez brièvement le rôle de chacun. Fournissez des liens vers les endroits où ils sont configurés ou le plus couramment utilisés.
- Intégrations : Identifiez et expliquez les intégrations avec des services externes, des bases de données supplémentaires, des API tierces, des courtiers de messages, etc. Comment la communication s'effectue-t-elle ? Pointez vers les modules/classes responsables et incluez des liens.
#### 7.1 Documentation API (si applicable)
- Si le projet expose des API :
- Existe-t-il des preuves d'outils ou de normes de documentation API (par exemple, Swagger/OpenAPI, Javadoc, docstrings spécifiques aux points de terminaison) ?
- Où cette documentation peut-elle être trouvée ou comment peut-elle être générée ?
---
### 8. Diagrammes
- Générez des diagrammes de haut niveau pour visualiser l'architecture et le comportement du système :
- Diagramme de composants (mettant en évidence les principaux modules et leurs interactions)
- Diagramme de flux de données (montrant comment l'information circule dans le système)
- Diagramme de classes (montrant les classes clés et leurs relations, si applicable)
- Diagramme de déploiement simplifié (où les composants s'exécutent, si détectable)
- Diagramme d'infrastructure/déploiement simplifié (si les détails d'infrastructure sont apparents)
- Créez ces diagrammes en utilisant la syntaxe Mermaid dans le fichier Markdown.
- Les diagrammes doivent être de haut niveau ; un détail excessif n'est pas requis.
---
### 9. Tests
- Existe-t-il des tests automatisés ?
- Tests unitaires
- Tests d'intégration
- Tests de bout en bout (E2E)
- Où se trouvent-ils dans le projet ?
- Quel(s) framework(s) de test sont utilisés ?
- Comment les tests sont-ils généralement exécutés ?
- Comment les tests peuvent-ils être exécutés localement ?
- Existe-t-il une stratégie CI/CD impliquant des tests ?
---
### 10. Gestion des erreurs et journalisation
- Comment l'application gère-t-elle généralement les erreurs ?
- Existe-t-il un modèle standard (par exemple, middleware global, exceptions personnalisées) ?
- Quelle bibliothèque de journalisation est utilisée ?
- Existe-t-il un format de journalisation standard ?
- Existe-t-il une intégration visible avec des outils de surveillance (par exemple, Datadog, Sentry) ?
---
### 11. Considérations de sécurité
- Existe-t-il des mécanismes de sécurité évidents dans le code ?
- Authentification
- Autorisation (middleware/filtres)
- Validation des entrées
- Des bibliothèques de sécurité spécifiques sont-elles utilisées de manière prominente (par exemple, Spring Security, Passport.js, bibliothèques JWT) ?
- Existe-t-il des pratiques de sécurité notables ?
- Gestion des secrets
- Protection contre les attaques courantes
---
### 12. Autres observations pertinentes (y compris build/déploiement)
- Existe-t-il des fichiers liés au build ou au déploiement ?
- Dockerfile
- docker-compose.yml
- Scripts de build/déploiement
- Fichiers de configuration CI/CD (par exemple, .github/workflows/, .gitlab-ci.yml)
- Qu'indiquent ces fichiers sur la façon dont l'application est construite et déployée ?
- Y a-t-il autre chose de crucial ou particulièrement utile pour un nouveau développeur ?
- Dette technique connue mentionnée dans les commentaires
- Modèles de conception inhabituels
- Conventions de codage importantes
- Notes de performance
---
## Format de sortie final
- Générez la réponse complète sous forme de document Markdown (.md) bien formaté.
- Utilisez un langage clair et direct.
- Organisez le contenu avec des titres et sous-titres conformément aux sections numérotées ci-dessus.
- Incluez des extraits de code pertinents (courts et représentatifs).
- Incluez des liens cliquables vers les fichiers, fonctions, classes et définitions chaque fois qu'un élément de code spécifique est mentionné.
- Structurez le document en utilisant les sections numérotées ci-dessus pour la lisibilité.
Dans la mesure du possible :
- Incluez des liens cliquables vers les fichiers, fonctions et classes.
- Montrez des extraits de code courts et représentatifs.
- Utilisez des puces ou des tableaux pour les listes.
---
### IMPORTANT
L'analyse doit prendre en compte TOUS les fichiers du projet. Lisez et comprenez tous les fichiers nécessaires pour exécuter pleinement cette tâche et parvenir à une compréhension complète du système.
---
### Action
Veuillez analyser le code source actuellement disponible dans mon environnement/espace de travail et générer le document Markdown demandé.
Le nom du fichier de sortie doit suivre ce format : <yyyy-mm-dd-project-name-app-dev-discovery_cursor.md>
Connectez-vous pour voir le prompt complet
Continuer avec:
En vous connectant, vous acceptez nos Conditions et Confidentialité
Utilisation
Ce prompt est conçu pour être utilisé avec coding. Copiez le contenu ci-dessus et collez-le dans votre outil d’IA préféré.
Pour de meilleurs résultats, personnalisez les espaces réservés (indiqués par des crochets ou des majuscules) selon vos besoins.
Discussion
0 commentaires