Clean Code

Extrait de la formation en ligne

PROGRAMME

(formule payante)

  • 🔒 Protéger un code existant avec des tests
  • 🔒 S’assurer de la couverture du code
  • 🔒 Tester c’est documenter
  • 🔒 Refactorer pour préparer une nouvelle fonctionnalité
  • 🔒 Introduire la nouvelle fonctionnalité en TDD
  • 🔒 Les bases du pair-programming
  • 🔒 Live #3
  • 🔒 Les bases des Stubs (bouchons), s’isoler des dépendances non testables
  • 🔒 Les bases de Spies (espions), tester des méthodes
  • 🔒 Et les Mocks (simulacres) dans tout ça ?
  • 🔒 Stratégie #1 : Éliminer les Stubs
    Stratégie #2 :
  • 🔒 Introduire une couture (Seam)
  • 🔒 Et si vous n’aimez pas les Stubs et les Spies ?
  • 🔒 Éviter les bugs de spécifications, travailler avec des exemples
  • 🔒 Éliminer les exceptions
  • 🔒 Dé-duplicaquer le code (et les tests)
  • 🔒 Réduire le besoin de mise à jour des tests
  • 🔒 Séparer le code testable du code non testable
  • 🔒 Tester le code non testable (tests d’intégration ciblés)
  • 🔒 Organiser un coding dojo avec son équipe
  • 🔒 Concevoir sa stratégie de tests avec la pyramide des tests
  • 🔒 Parler de la dette technique à son sponsor
  • 🔒 Gérer la dette technique dans son backlog produit
  • 🔒 Live #5
  • 🔒 Bibliographie
  • 🔒 Rappels des concepts objet
  • 🔒 Maîtriser son IDE
  • 🔒 Intégration continue
  • 🔒 Déploiement continu
  • 🔒 BDD (Behaviour Driven Development) pour faire du TDD

D'où vient la dette technique ?

Pourquoi la dette technique est-elle si présente dans nos projets ? Si c’est aussi courant, c’est qu’il y a des raisons systémiques. Pour éviter de faire le Don Quijote et se battre contre des moulins inébranlables, nous devons comprendre les forces qui entraînent l’accumulation de dette technique et trouver des astuces pour changer les choses, souvent en nous-mêmes, pour améliorer la situation. Dans cette vidéo, je présente quelques-unes des ces forces.

Face à un code désorganisé, on choisit souvent de ne rien faire pour éviter de “tout casser”. Dans ce contexte que l’on peut qualifier d’entropie (désorganisation), l’inaction est considérée comme moins risquée puisque l’on n’a pas suffisamment d’expérience de tests pour améliorer la situation. C’est l’entropie couplée à l’inaction qui amènent fatalement à une accumulation de la dette technique.

Pourtant une autre voie existe. En choisissant dès le départ de mettre en place des tests, de s’entraîner à les écrire plus rapidement, on se donne les moyens d’exploiter au maximum le refactoring indispensable pour maintenir le projet en bon état.

Panier
 
Retour en haut