Valeurs, pratiques et principes de développement

/!\ This page documenting our methodology and values is in french.

Nous détaillons dans ce document les valeurs, pratiques et principes de développement des projets MonitorFish et MonitorEnv. Nous nous basons sur l’Extreme Programming (ou XP). Cette page est co-construite ; n'importe qui peut écrire et demander un ajout ou une modification au reste de l'équipe.

Valeurs

• Communication
  C'est le moyen fondamental pour éviter les problèmes. Les pratiques que préconise l'XP imposent une communication intense. Les tests, la revue de code, le priorisation et la recette obligent les développeurs·ses et le reste de l'équipe à communiquer. Aussi, toute modification / breaking change d’une partie de l’application doit être revue en équipe.
• Simplicité
  La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps. Une application simple sera plus facile à faire évoluer.
• Feedback
  Le retour d'information est primordial pour le programmeur et le client. Les tests unitaires indiquent si le code fonctionne. Les tests fonctionnels donnent l'avancement du projet. Les livraisons fréquentes permettent de tester les fonctionnalités rapidement.
• Courage
  Certains changements demandent beaucoup de courage. Il faut parfois changer l'architecture d'un projet, jeter du code pour en produire un meilleur ou essayer une nouvelle technique. Le courage permet de sortir d'une situation inadaptée. C'est difficile, mais la simplicité, le feedback et la communication rendent ces tâches accessibles.
• Respect
  Cette valeur fut ajoutée dans la deuxième édition de Extreme Programming Explained de K. Beck. Cette valeur inclut le respect pour les autres, ainsi que le respect de soi. Les programmeurs ne devraient jamais valider les modifications qui cassent la compilation, qui font échouer les tests unitaires existants ou qui retardent le travail de leurs pairs. Les membres respectent leur propre travail en cherchant toujours la qualité et la meilleure conception pour la solution et cela grâce au refactoring.

Principes

Voici quelques principes que nous appliquons lorsque que nous codons :

• Ne pas ajouter de fonctionnalités plus tôt que prévu
• N'optimiser qu'à la fin
• Boyscout rule :
  On privilégie la modification et le refactoring au fur et à mesure que l'on "tombe" sur du code existant, plutôt que de créer des tâches techniques de refactoring
• YAGNI: You Ain’t Gonna Need It
• KISS: Keep It Simple, Stupid

Pratiques

• Intégration continue
  Lorsqu'une tâche est terminée, les modifications sont intégrées au plus vite dans le produit complet. On évite ainsi la surcharge de travail liée à l'intégration de tous les éléments avant la livraison. Les tests facilitent grandement cette intégration : quand tous les tests passent, l'intégration est terminée.
• Petites livraisons
  Les livraisons doivent être les plus fréquentes possible. L'intégration continue et les tests réduisent considérablement le coût de livraison.
• Rythme soutenable
  L'équipe ne fait pas d'heures supplémentaires. Si le cas se présente, il faut revoir le planning.
• Tests de recette (ou tests fonctionnels)
  À partir des scénarios définis, l'équipe crée des procédures de test qui permettent de vérifier l'avancement du développement. Lorsque tous les tests fonctionnels passent, l'itération est terminée. Ces tests sont souvent automatisés mais ce n'est pas toujours possible. En effet, seuls les tests de non-régression peuvent être potentiellement automatisés du fait de leur récurrence.
• Conception simple
  L'objectif d'une itération est de mettre en œuvre les scénarios sélectionnés et uniquement cela. Envisager les prochaines évolutions ferait perdre du temps sans avoir la garantie d'un gain ultérieur. Les tests permettront de changer l'architecture plus tard si nécessaire. Plus l'application est simple, plus il sera facile de la faire évoluer lors des prochaines itérations.
• Utilisation de métaphores
  On utilise des métaphores et des analogies pour décrire le système et son fonctionnement. Le fonctionnel et le technique se comprennent beaucoup mieux lorsqu'ils sont d'accord sur les termes qu'ils emploient.
• Remaniement du code
  Amélioration régulière de la qualité du code sans en modifier le comportement. On retravaille le code pour repartir sur de meilleures bases tout en gardant les mêmes fonctionnalités. Les phases de refactoring n'apportent rien au client mais permettent aux développeurs d'avancer dans de meilleures conditions et donc plus vite.
• Appropriation collective du code
  L'équipe est collectivement responsable de l'application. Chaque développeur peut faire des modifications dans toutes les portions du code, même celles qu'il n'a pas écrites. Les tests diront si quelque chose ne fonctionne plus.
• Convention de nommage
  Puisque tous les développeurs interviennent sur tout le code, il est indispensable de respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.