1. Le Nommage : Soyez Expressifs
Le nom d’une variable ou d’une fonction doit dire pourquoi elle existe, ce qu’elle fait et comment on l’utilise.❌ Mauvais (Peu clair)
✅ Bon (Explicite)
2. Les Fonctions : Faites une seule chose (SRP)
Une fonction (ou un composant) doit avoir une seule responsabilité. Si tu as besoin du mot “et” pour décrire ce que fait ta fonction, c’est qu’elle doit être découpée.❌ Mauvais (NestJS - Service “fourre-tout”)
✅ Bon (Responsabilités séparées)
Le Service Principal (Responsabilité : Créer) Il ne sait pas qu’un mail doit être envoyé, il dit juste : “J’ai fini mon travail”.3. Le Principe de “Don’t Repeat Yourself” (DRY)
Évite de copier-coller. Si tu vois la même logique deux fois, centralise-la.❌ Mauvais (React - Duplication)
✅ Bon (Composant réutilisable)
4. Les Commentaires : Le code doit s’expliquer seul
N’utilise les commentaires que pour expliquer le “Pourquoi” (décisions complexes), jamais le “Quoi”. Si le code est complexe, renomme tes variables.❌ Mauvais
✅ Bon
5. Les Principes SOLID (Le “S” et le “O”)
Pour les juniors, focus sur ces deux-là en priorité :| Principe | Définition simple |
|---|---|
| Single Responsibility | Un fichier = Une mission. |
| Open/Closed | Ton code doit être ouvert à l’extension mais fermé à la modification. |
S : Single Responsibility Principle (SRP)
“Une classe ou une fonction ne devrait avoir qu’une seule raison de changer.” Si ton fichier s’occupe à la fois de calculer un prix, de formater une date et d’envoyer une notification, il a trop de raisons de changer. Si le format de la date change, tu risques de casser le calcul du prix par erreur. ❌ Le mauvais élève (La classe “Dieu”) Ici, la classeInvoice (Facture) fait tout.
InvoiceCalculator: Ne connaît que les chiffres.InvoicePrinter: Ne connaît que le HTML/PDF.InvoiceRepository: Ne connaît que la base de données.
O : Open/Closed Principle (OCP)
“Ouvert à l’extension, fermé à la modification.” C’est le principe le plus difficile à comprendre au début. Cela signifie que tu devrais pouvoir ajouter une nouvelle fonctionnalité à ton application sans modifier le code existant. On ajoute du nouveau code au lieu de changer l’ancien. ❌ Mauvais : Le switch infini Imaginons un système qui calcule les frais de port selon le pays. Chaque fois qu’on ajoute un pays, on doit modifier la fonction existante.Pourquoi est-ce vital pour un Junior ?
- S (Single Responsibility) : Rend ton code testable. Il est facile de tester une petite fonction qui fait une seule chose. C’est impossible si elle fait 200 lignes.
- O (Open/Closed) : Rend ton code stable. Si tu n’as pas besoin de modifier une fonction qui marche déjà pour ajouter une option, tu ne risques pas de créer de nouveaux bugs (régressions) dans l’existant.
En résumé : Le S nous aide à savoir où mettre le code, le O nous aide à savoir comment l’organiser pour qu’il puisse grandir sans casser.
6. Structure et Clean Architecture (NestJS)
En NestJS, respectez la hiérarchie pour ne pas transformer les contrôleurs en usines à gaz.Règle d’or :
- Controller : Reçoit la requête, valide les données (DTO), renvoie la réponse. Pas de logique métier.
- Service : Contient toute la logique métier.
- Repository/Entity : Gère l’accès aux données.
Exemple de structure propre :
Résumé pour l’équipe
- Lisibilité > Brièveté : On s’en fiche que le code soit court, on veut qu’il soit clair.
- Petit, c’est mieux : Des fonctions de moins de 20 lignes, des composants de moins de 100 lignes.
- Supprime le code mort : Si une fonction n’est plus utilisée, on l’efface (Git est là pour s’en souvenir).
