🛩️XTreme Programming

Comprendre les principes à la base du extreme programming

Incremental Planning

  1. Conception des User Stories

  2. Identification des tâches à réaliser pour l'user story en cours

  3. Définition d'une date de release

  4. Dev, integrate, tests

  5. 📦 Release !

  6. Evaluation de la release

Small releases

Faire des releases régulières permet d'améliorer la communication avec des points plus fréquents et de préciser le besoin utilisateur en ayant un feedback régulier. De même les changements dans le code à cause d'un changement dans le besoin seront plus simples à faire.

Simple design

Il faut se focus sur les demandes utilisateurs et ne pas les étendre, cela prendrait trop de temps (ne pas trop se focaliser là-dessus). Ne pas prévoir les futurs changements avec du code mort, des interface à une seule classe, faire simple, les changements ultérieurs serotn ... ultérieurs. Attention aux duplicas de fonctionnalités, viser la rationalité. Le moins possible de classes et de méthodes. S'adapter en permanence, les tests garantissent que le code ne devrait pas break.

Test first development

On écrit d'abord les tests, puis on dev, ce qui va faire passer les tests au fur et à mesure en passed.

Refactoring

Dès qu'un code doit être modifié, la question du refactoring doit être posée sur cette partie là (pas d'over thinking sur le reste). Si il y a des améliorations à faire, il faut les faire directement. Encore une fois, les tests sont là pour nous garantir que le code continue à fonctionner.

Pair programming

S'applique pour la review ou l'écriture de code devant aller en production.

Continuous integration

  1. Tester ses modifications avec ses test locaux

  2. Puis les intégrer sur la CI et tester avec les tests systèmes (ou même tester avec les tests systèmes avant le merge en CI).

On site customer

Un personnel du client doit être présent aux réus d'avancement du projet

Types de tests

On a trois types de tests:

  • les tests unitaires : telle fonction réalise dans tel contexte telle action

  • les tests de fonctionnalité : teste certaines fonctionnalités du logiciel

  • les test système : correspondent à des tests centraux voulus par l'utilisateur.

Les +

  • Faire un ADR (architecture decision record)

  • Faire peu de docs, sauf si très important, perte de temps.

Ressources

https://www.youtube.com/playlist?list=PLCku-ULHIQvnWyghG0JnYbVQm35DvJi29arrow-up-right https://www.youtube.com/watch?v=ev1wsZrfO3Marrow-up-right

Last updated