Software craft

TDD

Voir la page sur les tests

Clean code

• La règle du "boy-scout" => quand on touche une portion de code, la laisser dans un état meilleur que celui où on l'a trouvée (progressivement améliorer le code à chaque feature)
• Principes pour un code lisible et évolutif
  • Le code n’est-il pas trop complexe pour ce qu’il fait ? Peut-on le simplifier ? Les abstractions et autres généralisations introduites le sont-elles à bon escient ? Est-ce qu’on n’anticipe pas trop sur un possible futur ?
  • Comprendre l'intention du code à la première lecture (ce que le code cherche à faire) => avec le nommage approprié, organisation/découpage du code, et les commentaires
  • Eviter la duplication (si pertinent)
  • Le design mis en place autorise-t-il suffisamment de liberté pour la suite ?

BDD (Behavior-driven development)

= co-construction des spécifications, permet :

• une compréhension partagée entre tous
• des critères d'acceptation pour le développement
• des tests de non-régression
• une documentation vivante et évolutive (avec ces mêmes tests)

Principes :

• Assurer la présence simultanée de trois types de rôles (les "tres amigos")
  • un product owner qui représente le besoin (+ recherche la valeur pour les utilisateurs)
  • un développeur pour la mise en oeuvre (+ représente la faisabilité technique)
  • Un testeur pour challenger les deux autres
• Faire des ateliers de spécifications avec ces trois personnes

Automatisation des scénarios :

• Syntaxe Gherkin
  • Syntaxe plus formelle pour la rédaction des scénarios. Peut être interprété par des outils de tests automatisés.
  • A l'intérieur de fichiers nommés les "fichiers de features" ("feature files"). Un fichier = une feature, qui contient une succession d'exemples/de cas.
  • En anglais : given > when > then
  • En français : Sachant que/Etant donné > Quand/Lorsque > Alors/Donc
  • Exemple :

Example: Aucune remise en dessous de 50 € d’achat 
    Given un panier avec 2 articles pour un total de 49 €,
    When le client consulte son panier,
    Then le total n’inclut aucune remise

Pair & mob programming

Comment binômer

• Deux rôles classiques : pilote (driver) qui contrôle la machine, et copilote (navigator) qui n'agit pas sur la machine
• Alternance fréquente recommandée (itérations de 5 à 10 minutes)
• Se détacher de son ego

Styles de binômage

• Ping pong : coupler pairing et TDD => alterner à chaque fois qu'on termine une phase rouge (une personne écrit un test en échec puis l'autre implémente)
• Navigation strong style : une personne va exposer son idée et l'autre va l'implémenter
• Silent pair programming : les deux personnes ne sont pas autorisées à parler, écrire ou dessiner ; seul le code peut être utilisé pour communiquer
• Evil twin pair programming : variante du ping-pong pair programming. Proposer une implémentation avec le plus de mauvaise foi possible pour mettre en avant les cas limites

Pourquoi binômer ?

• Apprendre et progresser plus rapidement : sur le code, l'IDE, l'historique de l'application
• Transmettre l'info : pour éviter le bus factor
• Se motiver et s'entraider

Mob programming

(ou ensemble programming)

= une équipe entière sur une seule tâche sur un seul clavier

Sources

• Livre Software Craft de Cyrille Martraire