Aller au contenu

Checklist Onboarding Développeur DYNORS

Objectif : s’assurer qu’un nouveau développeur a vu et pratiqué les éléments essentiels avant de toucher à un vrai projet client.

1. Compréhension de la vision

  • [ ] A lu la page "Niveau 1 – Vision & Architecture Globale".
  • [ ] Comprend la différence entre :
  • dynors-core, dynors-internal, dynors-extensions.
  • Outils internes (RAGNAR, TAKKU, HEISENBERG, RED) vs projets clients.
  • Tenant / Tier / Type d’application (CLIENT_PROJECT, DYNORS_PRODUCT, etc.).

2. Compréhension technique de base

  • [ ] A lu la page "Projets clients & dynors-core".
  • [ ] Comprend le rôle de :
  • dynors-db (multi‑tenant, schémas, quotas).
  • dynors-security (JWT, OAuth2, rôles/permissions).
  • dynors-logging (logging centralisé, provider pluggable).

3. Pratique encadrée (TP SeckShop)

  • [ ] A suivi le TP "SeckShop Backend" jusqu’à :
  • création de l’app Spring Boot,
  • intégration dynors-core (db, security, logging),
  • endpoints CRUD simples (ex : Customer).
  • [ ] A ajouté au moins :
  • un log info métier significatif,
  • un log error géré via DynorsLogger.

4. Qualité & bonnes pratiques

  • [ ] Sait écrire un test d’intégration simple (Spring Boot test + PostgreSQL/H2).
  • [ ] Comprend l’importance :
  • de ne pas "casser" le multi‑tenant (pas de requêtes SQL brutes sans contexte),
  • de laisser dynors-db gérer les schémas et tenants.

5. Accès & outils

  • [ ] Dispose des accès nécessaires (GitLab, registry Maven, Sentry si utilisé).
  • [ ] Sait lancer :
  • mkdocs serve dans dynors-docs pour consulter la doc,
  • les projets internes de démonstration (ex : TAKKU, RAGNAR backend/ frontend).

Cette checklist peut être utilisée par le lead pour valider l’onboarding d’un nouveau développeur DYNORS.