07. Méthodologie - BlacF0X/owl GitHub Wiki

A. Bonnes pratiques, Outils & Sécurité

  • Qualité du code : Nous utilisons TypeScript avec des règles strictes, ESLint pour l'analyse de code, et Prettier pour le formatage automatique afin de garantir un code propre et cohérent.
  • Gestion de projet : Les tâches sont gérées via les User Stories sur les Issues GitHub.
  • Outils de communication : Tous nos échanges, formels comme informels, se font sur Discord.
  • Consignes de sécurité : Il est interdit d'intégrer des clés secrètes ou des clés d'API directement dans le code. Celles-ci doivent être gérées via des variables d'environnement (voir le fichier .env.example).

B. Organisation du code & Conventions

Notre code source est structuré de manière modulaire, en suivant les conventions du App Router de Next.js :

  • app/ : Cœur de l'application. Il contient les pages (un dossier avec un fichier page.tsx), les layouts (layout.tsx) et les styles globaux (globals.css).
  • components/ : (Situé à la racine) Contient les composants React réutilisables dans toute l'application, comme la Navbar ou le Footer.
  • Styles : Les styles sont gérés via des CSS Modules (.module.css) co-localisés avec leurs composants respectifs pour garantir un style isolé et maintenable.
    • (Note : Nous privilégions cette approche pour un contrôle total sur le design. L'utilisation d'une bibliothèque comme Ant Design est envisagée uniquement si le besoin de composants pré-construits très complexes se présente.)

Nos configurations de linting et de formatage sont centralisées dans les fichiers eslint.config.mjs, .prettierrc et tsconfig.json à la racine du projet.

C. Utilisation de Git & GitHub

Notre flux de travail est centré sur la branche develop :

  1. Création de branche : Toute nouvelle fonctionnalité démarre d'une branche créée à partir de develop.
  2. Convention de nommage : Les branches doivent suivre le format feature/USXX-nom-de-lissue (par exemple : feature/US01-page-connexion).
  3. Pull Request (PR) : Une fois le développement terminé, une PR est ouverte vers develop.
  4. Revue de code : Chaque PR doit être relue et approuvée par au moins un autre membre de l'équipe avant de pouvoir être fusionnée.

D. Rythme de travail et communication

  • Réunions synchrones : Nous organisons des points d'équipe deux fois par semaine pour discuter de l'avancement, débloquer les problèmes et travailler ensemble.
  • Communication asynchrone : Les discussions quotidiennes et les questions urgentes sont gérées sur notre serveur Discord.