afterwork/CONTRIBUTING.md

🤝 Guide de Contribution - AfterWork

Merci de votre intérêt pour contribuer au projet AfterWork ! Ce document vous guidera à travers le processus de contribution.

📋 Table des Matières

• Code de Conduite
• Comment Contribuer
• Standards de Code
• Processus de Pull Request
• Conventions de Commit
• Architecture du Projet

---

📜 Code de Conduite

En participant à ce projet, vous acceptez de respecter notre code de conduite :

• Être respectueux envers tous les contributeurs
• Accepter les critiques constructives
• Se concentrer sur ce qui est le mieux pour la communauté
• Faire preuve d'empathie envers les autres membres

---

🚀 Comment Contribuer

1. Fork et Clone

# Fork le repository sur GitHub
# Puis clone votre fork
git clone https://github.com/votre-username/afterwork.git
cd afterwork

2. Créer une Branche

# Créer une branche pour votre feature/fix
git checkout -b feature/nom-de-votre-feature

# Ou pour un bugfix
git checkout -b fix/nom-du-bug

3. Développer

• Écrivez du code propre et testé
• Suivez les standards de code du projet
• Ajoutez des tests pour les nouvelles fonctionnalités
• Documentez votre code

4. Tester

# Lancer les tests
flutter test

# Vérifier le linting
flutter analyze

# Formater le code
dart format .

5. Commit

# Ajouter vos changements
git add .

# Commit avec un message descriptif
git commit -m "feat: ajouter fonctionnalité X"

6. Push et Pull Request

# Push vers votre fork
git push origin feature/nom-de-votre-feature

# Créer une Pull Request sur GitHub

---

💻 Standards de Code

Formatage

• Indentation : 2 espaces
• Ligne max : 80 caractères (flexible pour la lisibilité)
• Trailing commas : Obligatoires pour les listes multi-lignes

Conventions de Nommage

// Classes : PascalCase
class UserProfile {}

// Fichiers : snake_case
// user_profile.dart

// Variables et fonctions : camelCase
String userName = 'John';
void getUserById() {}

// Constantes : lowerCamelCase
const String apiBaseUrl = 'https://api.example.com';

// Constantes privées : _lowerCamelCase
const String _privateKey = 'secret';

Widgets

// Toujours utiliser const pour les widgets immuables
const Text('Hello World');

// Préférer les constructeurs const
class MyWidget extends StatelessWidget {
  const MyWidget({super.key});
  
  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }
}

// Trailing comma pour meilleure lisibilité
return Container(
  padding: const EdgeInsets.all(16),
  child: Column(
    children: [
      const Text('Title'),
      const SizedBox(height: 8),
      const Text('Subtitle'),
    ],
  ),
);

Documentation

/// Récupère un utilisateur par son ID.
///
/// [userId] L'identifiant unique de l'utilisateur.
/// 
/// Retourne un [User] ou null si non trouvé.
/// 
/// Throws [ServerException] si l'API est inaccessible.
Future<User?> getUserById(String userId) async {
  // Implementation
}

Gestion des Erreurs

// Utiliser try-catch pour les opérations à risque
try {
  final result = await apiCall();
  return Right(result);
} on ServerException catch (e) {
  return Left(ServerFailure(e.message));
} catch (e) {
  return Left(UnexpectedFailure());
}

---

🔄 Processus de Pull Request

Checklist avant PR

• Le code compile sans erreur
• Tous les tests passent (flutter test)
• Le linting est propre (flutter analyze)
• Le code est formaté (dart format .)
• Les nouvelles fonctionnalités ont des tests
• La documentation est à jour
• Les commits suivent les conventions

Template de PR

## Description
Brève description des changements

## Type de changement
- [ ] Bug fix
- [ ] Nouvelle fonctionnalité
- [ ] Breaking change
- [ ] Documentation

## Tests
- [ ] Tests unitaires ajoutés/mis à jour
- [ ] Tests d'intégration ajoutés/mis à jour
- [ ] Tests manuels effectués

## Captures d'écran (si applicable)
Ajoutez des captures d'écran ici

## Checklist
- [ ] Mon code suit les standards du projet
- [ ] J'ai effectué une auto-review
- [ ] J'ai commenté les parties complexes
- [ ] J'ai mis à jour la documentation
- [ ] Mes changements ne génèrent pas de warnings
- [ ] J'ai ajouté des tests
- [ ] Tous les tests passent

---

📝 Conventions de Commit

Nous utilisons les Conventional Commits :

Format

<type>(<scope>): <subject>

<body>

<footer>

Types

• feat : Nouvelle fonctionnalité
• fix : Correction de bug
• docs : Documentation uniquement
• style : Formatage, points-virgules manquants, etc.
• refactor : Refactoring de code
• perf : Amélioration de performance
• test : Ajout ou correction de tests
• chore : Maintenance, dépendances, etc.

Exemples

# Feature
git commit -m "feat(auth): ajouter authentification biométrique"

# Bug fix
git commit -m "fix(events): corriger crash lors du chargement"

# Documentation
git commit -m "docs(readme): mettre à jour instructions d'installation"

# Refactoring
git commit -m "refactor(user): extraire logique de validation"

# Breaking change
git commit -m "feat(api): changer format de réponse

BREAKING CHANGE: Le format de réponse de l'API a changé"

---

🏗 Architecture du Projet

Clean Architecture

Le projet suit les principes de Clean Architecture :

lib/
├── core/           # Code partagé (constantes, utils, thèmes)
├── domain/         # Logique métier pure (entités, usecases)
├── data/           # Implémentation data (models, repositories)
└── presentation/   # UI (screens, widgets, state management)

Règles

1. Domain ne dépend de rien
2. Data dépend de Domain
3. Presentation dépend de Domain (et peut utiliser Data via interfaces)
4. Les dépendances pointent toujours vers l'intérieur

Exemple d'ajout de fonctionnalité

1. Créer l'entité dans domain/entities/
2. Créer le use case dans domain/usecases/
3. Créer le modèle dans data/models/
4. Créer le repository dans data/repositories/
5. Créer le BLoC/Provider dans presentation/state_management/
6. Créer l'UI dans presentation/screens/ ou presentation/widgets/

---

🧪 Tests

Structure des Tests

test/
├── domain/
│   ├── entities/
│   └── usecases/
├── data/
│   ├── models/
│   └── repositories/
└── presentation/
    ├── screens/
    └── widgets/

Exemple de Test Unitaire

import 'package:flutter_test/flutter_test.dart';

void main() {
  group('User Entity', () {
    test('should create user with valid data', () {
      // Arrange
      const userId = '123';
      const email = 'test@example.com';
      
      // Act
      final user = User(
        userId: userId,
        email: email,
        // ...
      );
      
      // Assert
      expect(user.userId, userId);
      expect(user.email, email);
    });
  });
}

---

📚 Ressources

• Flutter Documentation
• Dart Style Guide
• Clean Architecture
• BLoC Pattern

---

❓ Questions

Si vous avez des questions, n'hésitez pas à :

• Ouvrir une issue
• Contacter l'équipe de développement

---

Merci de contribuer à AfterWork ! 🚀