Le comportement au coeur de vos applications
•Télécharger en tant que PPSX, PDF•
0 j'aime•50 vues
Avec l'émergence des pratiques de craftmanship (TDD, BDD, DDD, notamment), nous avons l'occasion de piloter nos développements par les fonctionnalités et les comportements. Néanmoins, cela peut paraître encore obscure si nous n'en avons pas l'habitude. Je vous propose ici, à travers un exemple concret, une première approche avec React, Jest et Jest-Cucumber.
![2
S.O.L.I.D.
Oriented Object Design
Comme son nom l’indique, ce principe signifie qu’une classe ne doit posséder
qu’une et une seule responsabilité.
Single responsibility principle
"[...]La notion de sous-type telle que définie par Liskov et Wing est fondée sur
la notion de substituabilité : si S est un sous-type de T, alors tout objet de
type T peut être remplacé par un objet de type S sans altérer les propriétés
désirables du programme concerné.”
Liskov principle
L'objectif est d'utiliser les interfaces pour définir des contrats qui répondent à
un besoin fonctionnel pour créer une abstraction et réduire le couplage.
Interface segregation principle
Les classes et les méthodes doivent être ouvertes à l'extension mais fermées
à la modification.
Open close principle
Ce principe consiste à rendre indépendant les modules de haut niveau de
eux de bas niveau en inversant ces relations.
Dependency inversion principle](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Le comportement au coeur de vos applications
- 1. AU COEUR DE NOS APPLICATIONS Comportements Presentation avec du React dedans
- 2. 2 S.O.L.I.D. Oriented Object Design Comme son nom l’indique, ce principe signifie qu’une classe ne doit posséder qu’une et une seule responsabilité. Single responsibility principle "[...]La notion de sous-type telle que définie par Liskov et Wing est fondée sur la notion de substituabilité : si S est un sous-type de T, alors tout objet de type T peut être remplacé par un objet de type S sans altérer les propriétés désirables du programme concerné.” Liskov principle L'objectif est d'utiliser les interfaces pour définir des contrats qui répondent à un besoin fonctionnel pour créer une abstraction et réduire le couplage. Interface segregation principle Les classes et les méthodes doivent être ouvertes à l'extension mais fermées à la modification. Open close principle Ce principe consiste à rendre indépendant les modules de haut niveau de eux de bas niveau en inversant ces relations. Dependency inversion principle
- 3. 3 Pratiques Software Craftmanship DDD BDDTDD Expérimentation Design itératif Collaboration Focus métier Automatisation Test-first Vous êtes ici
- 4. 4 Gherkin 3 Amigos • Product Owner (Besoin) • Testeur (Risque) • Développeur (Technique) Scenarios d’exemples concrets Ecris dans un langage que tout le monde comprend Prêts à être automatisés
- 5. 5 B e n o i t F O N TA I N E T E C H L E A D E R @ A X A F R A N C E Qui suis-je ? @ B e n o t F O N TA I N E G i t h u b . c o m / C i n q M i n u t e s
- 6. 6
- 7. 7
- 8. 8
- 9. 9
- 10. En vrai, comment fait-on ? ACTION !
- 11. 11 MERCI ! Aller plus loin : Behavior Development Apprendre le Gherkin https://cucumber.io/docs/gherkin/reference/ Quelques vidéos http://bit.ly/bfeYtbe Sources Github https://github.com/CinqMinutes/jest-cucumber-examples
Notes de l'éditeur
- SOLID est un ensemble de principes qui répond à une problématique d'évolutivité du code source. Ils sont dans le livre Agile Software Development, Pinciples, Patterns and Practices de Robert C. Martin. Liskov principle Le principe de Liskov impose des restrictions sur les signatures sur la définition des sous-types : Contravariance des arguments de méthode dans le sous-type. Covariance du type de retour dans le sous-type. Aucune nouvelle exception ne doit être générée par la méthode du sous-type, sauf si celles-ci sont elles-mêmes des sous-types des exceptions levées par la méthode du supertype. Interface segregation principle L'utilisation systèmatique des interfaces pour chaque classe est un anti-pattern. Pensez à faire preuve de bon sens et de pragmatisme ! Dependency inversion principleLes modules de haut niveau et les modules de bas niveau dépendent d'abstractions pour casser le lien de dépendance haut vers bas. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.
- DDD n’est ni une méthode ni une technologie. DDD est une manière de penser la conception autour du code, de collaborer et de communiquer avec les experts fonctionnels. Le DDD a été introduit par Eric Evans en 2003. Il a construit cette approche de conception suite à des retours d’expérience. Le DDD est centré sur le métier de l’application et le code source qui l’implémente. Véritable objectif : permettre au PO de lire votre code (mais aussi testeur, etc.)