// ❌ Commentaires qui blessent
"Ce code est nul"
"Tu n'as pas compris le pattern"
"C'est du code de débutant"
"Encore cette erreur classique..."

// ✅ Commentaires qui construisent
"Ce pattern pourrait être simplifié avec..."
"As-tu considéré cette alternative ?"
"Cette approche fonctionne, et voici une variation possible..."
"J'ai fait la même erreur récemment, voici ce que j'ai appris..."

# Templates pour code review constructive

## Pour suggérer une amélioration
💡 **Suggestion**: Cette fonction pourrait bénéficier de...
**Pourquoi**: [explication du bénéfice]
**Exemple**: [code ou lien vers documentation]
**Priorité**: Nice-to-have / Important / Bloquant

## Pour partager de la connaissance
📚 **Partage**: J'ai découvert récemment que...
**Lien utile**: [documentation/article]
**Dans notre contexte**: [adaptation spécifique au projet]

## Pour poser une question
🤔 **Question**: Peux-tu m'expliquer le choix de...
**Mon interrogation**: [ce qui n'est pas clair]
**Objectif**: Mieux comprendre ta logique

## Pour féliciter
🎉 **Bravo**: Excellent travail sur...
**Ce que j'apprécie**: [aspect spécifique]
**Impact**: [bénéfice pour l'équipe/projet]

// Grille de décision pour prioriser les commentaires
const reviewPriorities = {
  BLOQUANT: {
    criteria: [
      'Bug de sécurité',
      'Régression fonctionnelle',
      'Performance critique dégradée',
      'Violation architecture majeure'
    ],
    action: 'Fix obligatoire avant merge',
    example: 'Faille SQL injection dans la requête de login'
  },
  
  IMPORTANT: {
    criteria: [
      'Lisibilité compromise',
      'Maintenance difficile',
      'Tests insuffisants',
      'Duplication de code significative'
    ],
    action: 'Discussion requise, fix probable',
    example: 'Fonction de 200 lignes sans décomposition'
  },
  
  SUGGESTION: {
    criteria: [
      'Style coding non respecté',
      'Nommage améliorable',
      'Pattern plus élégant possible',
      'Documentation manquante'
    ],
    action: 'Amélioration bienvenue mais pas bloquante',
    example: 'Variable `data` pourrait être plus explicite'
  },
  
  APPRENTISSAGE: {
    criteria: [
      'Partage de connaissance',
      'Trick utile',
      'Ressource intéressante',
      'Context historique'
    ],
    action: 'Information pure, aucune action requise',
    example: 'TIL: Cette lib a une méthode plus concise'
  }
};

// Métriques pour review saine
const healthyReviewMetrics = {
  commentRatio: {
    positive: '20%', // Encouragements, félicitations
    constructive: '60%', // Suggestions d'amélioration
    questions: '15%', // Demandes de clarification
    bloquant: '5%' // Vraiment critique seulement
  },
  
  timeToReview: {
    target: '< 24h', // Premier passage
    explanation: 'Plus c\'est rapide, plus le contexte est frais'
  },
  
  iterationCount: {
    average: 2.5, // Allers-retours moyens
    target: '< 4', // Au-delà, discussion directe recommandée
  }
};

# 📋 Checklist PR - Côté Auteur

## Code prêt
- [ ] Fonctionne en local (tests passent)
- [ ] Pas de console.log / debugger oubliés
- [ ] Formatting automatique appliqué
- [ ] Nommage explicite (variables, fonctions, fichiers)

## Tests & Documentation  
- [ ] Tests unitaires pour nouvelle logique
- [ ] Tests existants toujours verts
- [ ] Documentation mise à jour si nécessaire
- [ ] README actualisé si changement d'API

## Communication
- [ ] Titre de PR descriptif
- [ ] Description explique le "pourquoi"
- [ ] Screenshots pour changements UI
- [ ] Reviewers assignés selon expertise

## Contexte métier
- [ ] Lien vers ticket/user story
- [ ] Impact utilisateur expliqué
- [ ] Cas limites considérés
- [ ] Migration/rollback plan si nécessaire

# Template description PR

## 🎯 Objectif
Résoudre le problème de [description concise du problème]

## 🔧 Solution
- Ajout de [fonctionnalité X] via [approche technique]
- Modification de [composant Y] pour [raison]
- Suppression de [code obsolète Z]

## 🧪 Comment tester
1. Aller sur la page /dashboard
2. Cliquer sur "Nouveau projet"
3. Vérifier que [comportement attendu]

## 📸 Screenshots/Vidéo
[Si changement UI/UX]

## ⚠️ Points d'attention
- Migration de données requise (script fourni)
- Changement d'API (backward compatible)
- Performance : [impact mesuré]

## 📚 Ressources
- [Lien documentation technique]
- [Article de référence utilisé]
- [Discussion Slack/ticket original]

// Méthode de review en plusieurs passes
const reviewPasses = {
  pass1_overview: {
    focus: 'Vision globale',
    questions: [
      'L\'approche générale est-elle cohérente ?',
      'L\'architecture est-elle respectée ?',
      'Les changements sont-ils proportionnés au besoin ?'
    ],
    duration: '5-10 minutes'
  },
  
  pass2_logic: {
    focus: 'Logique métier',
    questions: [
      'La logique est-elle correcte ?',
      'Les cas limites sont-ils gérés ?',
      'Les validations sont-elles suffisantes ?'
    ],
    duration: '15-20 minutes'
  },
  
  pass3_quality: {
    focus: 'Qualité du code',
    questions: [
      'Le code est-il lisible ?',
      'Y a-t-il de la duplication ?',
      'Les noms sont-ils explicites ?'
    ],
    duration: '10-15 minutes'
  },
  
  pass4_tests: {
    focus: 'Couverture tests',
    questions: [
      'Les tests couvrent-ils les cas importants ?',
      'Les tests sont-ils maintenables ?',
      'Manque-t-il des tests d\'intégration ?'
    ],
    duration: '10 minutes'
  }
};

// Configuration ESLint pour pre-review automatique
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended'
  ],
  rules: {
    // Éviter les discussions sur le style
    'prettier/prettier': 'error',
    
    // Sécurité automatique
    'no-eval': 'error',
    'no-implied-eval': 'error',
    
    // Qualité basique
    'no-unused-vars': 'error',
    'no-console': 'warn',
    'prefer-const': 'error',
    
    // Lisibilité
    'max-lines': ['warn', 300],
    'max-params': ['warn', 4],
    'complexity': ['warn', 10]
  }
};

// Scripts pre-commit automatiques
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged && npm test",
      "pre-push": "npm run test:coverage"
    }
  },
  "lint-staged": {
    "*.{js,ts}": [
      "eslint --fix",
      "prettier --write",
      "git add"
    ],
    "*.{json,md}": [
      "prettier --write",
      "git add"
    ]
  }
}

// Adaptation du style de review selon l'expérience
const mentoringStrategies = {
  junior: {
    approach: 'Pédagogique',
    focus: [
      'Expliquer les "pourquoi"',
      'Proposer des alternatives avec exemples',
      'Partager ressources d\'apprentissage',
      'Encourager les bonnes pratiques'
    ],
    example: `
    💡 Excellente logique ! Pour la lisibilité, on peut extraire cette condition :
    
    \`\`\`javascript
    // Au lieu de
    if (user.age >= 18 && user.verified && user.subscription.active) {
      // ...
    }
    
    // On pourrait avoir
    const canAccessPremium = user.age >= 18 && 
                           user.verified && 
                           user.subscription.active;
    if (canAccessPremium) {
      // ...
    }
    \`\`\`
    
    📚 Article intéressant sur l'extraction de conditions : [lien]
    `
  },
  
  medior: {
    approach: 'Collaborative',
    focus: [
      'Discuter des alternatives',
      'Challenger les choix techniques',
      'Partager expérience similaire',
      'Encourager l\'autonomie'
    ],
    example: `
    🤔 Intéressant choix d'utiliser Observer pattern ici. 
    As-tu considéré les alternatives ?
    
    Avantages de ton approche :
    - Découplage fort
    - Extensibilité
    
    Possibles inconvénients :
    - Complexité debug
    - Performance si beaucoup d'observers
    
    Dans notre contexte, que penses-tu d'une approche plus simple 
    comme un callback direct ?
    `
  },
  
  senior: {
    approach: 'Expertise partagée',
    focus: [
      'Discuter architecture globale',
      'Anticiper impacts futurs',
      'Valider cohérence système',
      'Partager vision produit'
    ],
    example: `
    👍 Solide implémentation ! Quelques réflexions :
    
    Architecture : Ce pattern s'alignerait bien avec notre 
    évolution vers event-sourcing.
    
    Performance : Avec la croissance prévue, prévoir un index 
    sur cette colonne ?
    
    Métier : As-tu sync avec l'équipe produit sur ce flow ? 
    Je me souviens d'discussions sur l'évolution du parcours.
    `
  }
};

# 📖 Guide des standards équipe (vivant)

## Patterns favorisés

### Gestion d'erreur
```javascript
// ✅ Pattern équipe pour async/await
try {
  const result = await apiCall();
  return { success: true, data: result };
} catch (error) {
  logger.error('API call failed', { error, context });
  return { success: false, error: error.message };
}

// ✅ Utiliser Joi pour validation complexe
const userSchema = Joi.object({
  email: Joi.string().email().required(),
  age: Joi.number().integer().min(13).max(120)
});

// Éviter absolument
getData(id, function(data) {
  processData(data, function(result) {
    saveResult(result, function(saved) {
      // ...
    });
  });
});

// Éviter les mutations d'objets props
function updateUser(user) {
  user.lastLogin = new Date(); // ❌ Mutation
  return user;
}

// Préférer l'immutabilité
function updateUser(user) {
  return { ...user, lastLogin: new Date() }; // ✅
}

// Configuration bot code review
const reviewBot = {
  // Vérifications automatiques
  autoChecks: [
    'Code coverage > 80%',
    'No ESLint errors',
    'Build successful',
    'No console.log in production code',
    'Package.json updated if dependencies changed'
  ],
  
  // Assignation intelligente
  reviewerAssignment: {
    byExpertise: {
      'src/api/**': ['@alice', '@bob'], // Backend experts
      'src/ui/**': ['@charlie', '@diana'], // Frontend experts
      'src/database/**': ['@eve'] // DB expert
    },
    byWorkload: 'Balance review load across team',
    skipAuthor: true,
    minReviewers: 2
  },
  
  // Notifications contextuelles
  notifications: {
    slack: {
      newPR: '#code-review',
      approved: '#deployments',
      conflicts: '#urgent-review'
    },
    email: {
      staleReview: 'After 48h without review'
    }
  }
};

// Exemple de message bot utile
const botMessage = `
🤖 **Review Assistant**

**✅ Automated checks passed**
- Build: Success
- Tests: 47/47 passing
- Coverage: 84% (+2%)
- Linting: No issues

**📊 PR Stats**
- Lines changed: +142/-38
- Files modified: 6
- Complexity added: Low

**👥 Suggested reviewers**
- @alice (API expertise)
- @bob (testing patterns)

**📋 Pre-review checklist**
- [ ] Breaking changes documented?
- [ ] Performance impact considered?
- [ ] Security implications reviewed?
`;

// Métriques code review pour amélioration continue
const reviewMetrics = {
  speed: {
    timeToFirstReview: {
      current: '18h',
      target: '< 24h',
      trend: 'improving'
    },
    timeToApproval: {
      current: '2.3 days',
      target: '< 3 days',
      trend: 'stable'
    }
  },
  
  quality: {
    iterationsPerPR: {
      current: 2.1,
      target: '< 3',
      trend: 'improving'
    },
    bugsFoundInReview: {
      current: '12%',
      description: 'PRs where review caught bugs',
      trend: 'stable'
    }
  },
  
  collaboration: {
    participationRate: {
      current: '85%',
      description: 'Team members actively reviewing',
      target: '> 80%'
    },
    knowledgeSharing: {
      current: '34 comments/week',
      description: 'Learning-focused comments',
      trend: 'growing'
    }
  },
  
  satisfaction: {
    reviewerBurnout: {
      metric: 'Reviews per person per week',
      current: '8.5',
      target: '< 10'
    },
    authorSatisfaction: {
      metric: 'Survey: Review process helpful',
      current: '4.2/5',
      target: '> 4/5'
    }
  }
};

# 🔄 Rétro Code Review - Template

## Ce qui marche bien
- [ ] Feedback constructif et bienveillant
- [ ] Temps de review respectés
- [ ] Apprentissage mutuel visible
- [ ] Standards équipe clairs

## Points d'amélioration
- [ ] Reviews trop longues/détaillées
- [ ] Manque d'expertise sur certains sujets
- [ ] Processus lourd pour petites PRs
- [ ] Communication asynchrone difficile

## Actions pour le mois
1. **[Action concrète]** - Responsable: @someone - Échéance: date
2. **[Action concrète]** - Responsable: @someone - Échéance: date
3. **[Action concrète]** - Responsable: @someone - Échéance: date

## Expérimentations à tenter
- [ ] Pair review pour PRs complexes
- [ ] Review sessions live ponctuelles
- [ ] Rotation expertise pour apprentissage
- [ ] Guidelines spécifiques par type de PR

# 🤝 Résolution désaccord technique

## 1. Clarification des positions
- **Position A**: [Résumé objectif]
- **Position B**: [Résumé objectif]
- **Zone d'accord**: [Points communs identifiés]

## 2. Critères de décision
- [ ] Performance/scalabilité
- [ ] Maintenabilité à long terme
- [ ] Compétences équipe actuelles
- [ ] Temps de développement
- [ ] Risques techniques
- [ ] Cohérence architecture

## 3. Expérimentation si nécessaire
- [ ] Prototype rapide des deux approches
- [ ] Mesure objective des critères
- [ ] Consultation expertise externe

## 4. Décision et documentation
- **Décision**: [Choix final avec justification]
- **Compromis**: [Concessions des deux côtés]
- **Apprentissage**: [Ce qu'on retient pour l'avenir]

// Stratégies prévention burnout review
const burnoutPrevention = {
  workloadBalance: {
    maxReviewsPerDay: 3,
    maxComplexReviewsPerWeek: 2,
    rotationPrinciple: 'Distribute expertise, avoid bottlenecks',
    breakAfterDifficultReview: '30min cooldown recommended'
  },
  
  reviewTimeboxing: {
    simpleChanges: '15min max',
    standardFeatures: '45min max', 
    complexArchitecture: '1.5h max then discuss live',
    emergencyFixes: 'Pair review for speed + quality'
  },
  
  supportSystems: {
    pairReview: 'For learning or complex topics',
    expertConsultation: 'Escalate to domain expert when stuck',
    reviewFreeTime: '2h/day minimum for deep work',
    skipOption: 'Can decline if overloaded, reassign automatically'
  }
};