├── summury ├── octo-culture-test-1.md ├── octo-culture-produit.md ├── octo-culture-devops-1.md ├── octo-culture-devops-3.md ├── octo-culture-devops-2.md ├── octo-culture-code.md ├── octo-culture-change.md ├── octo-culture-flow.md └── software-craft-pratiques-essentielles.md ├── rules ├── step-down.md ├── KISS.md ├── SOC.md ├── demeter.md ├── YAGNI.md └── DRY.md ├── solid ├── SRP.md ├── ISP.md ├── OCP.md ├── LSP.md └── DIP.md ├── off-topic ├── brooks.md ├── regles-developpeur.md └── lois-et-principes.md ├── appendices ├── mauvaises-pratiques.md ├── complexite.md ├── coding-dojos.md ├── ADR.md ├── dette-technique.md ├── maintenabilite.md ├── continuous-inspection.md ├── software-craftsmanship.md ├── code-review.md └── tests.md └── README.md /summury/octo-culture-test-1.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : OCTO - Culture Test Vol.1 - 2024 2 | 3 | :link: 4 | 5 | ## Préface 6 | 7 | > TODO 8 | 9 | ## Chapitre 1 : TODO 10 | 11 | TODO 12 | 13 | ## Chapitre 2 : TODO 14 | 15 | TODO 16 | 17 | ## Conclusion 18 | 19 | TODO 20 | 21 | --- 22 | :point_left: [Retour à l'accueil](../README.md) 23 | -------------------------------------------------------------------------------- /rules/step-down.md: -------------------------------------------------------------------------------- 1 | # Step-down rule - Règle de la descente 2 | 3 | Cette règle permet d'accroître la lisibilité du code et donc sa maintenabilité en préconisant d'organiser les fonctions dans un ordre évident de lecture, avec les fonctions appelées en dessous des appelantes, en partant du générique (= l'abstrait) vers le spécifique (= le concret). 4 | 5 | --- 6 | :point_left: [Retour à l'accueil](../README.md) 7 | -------------------------------------------------------------------------------- /solid/SRP.md: -------------------------------------------------------------------------------- 1 | # SRP : Single Responsibility Principle 2 | 3 | ## Définition 4 | 5 | > Il ne doit exister qu'une et une seule raison de modifier une classe ou un module. 6 | 7 | ## Détails 8 | 9 | TODO 10 | 11 | ## Références 12 | 13 | * [Wikipédia](https://fr.wikipedia.org/wiki/Principe_de_responsabilit%C3%A9_unique) 14 | * [Blog Analyse Logicielle](http://web2.cegepat.qc.ca/~claudeboutet/index.php/2017/02/17/principe-de-responsabilite-unique/) 15 | 16 | --- 17 | :point_left: [Retour à l'accueil](../README.md) 18 | -------------------------------------------------------------------------------- /rules/KISS.md: -------------------------------------------------------------------------------- 1 | # KISS : Keep It Simple, Stupid 2 | 3 | ## Définition 4 | 5 | > Principe dont la ligne directrice de conception qui préconise la simplicité dans la conception et que toute complexité non indispensable devrait être évitée dans toute la mesure du possible : **aller à l'essentiel**. 6 | 7 | ## Détails 8 | 9 | * Bref 10 | * Simple 11 | * Direct 12 | 13 | ## Avantages 14 | 15 | * Gain de temps 16 | * Gain de maintenabilité : moins de complexité 17 | 18 | ## Références 19 | 20 | * [Wikipédia](https://fr.wikipedia.org/wiki/Principe_KISS) 21 | 22 | --- 23 | :point_left: [Retour à l'accueil](../README.md) 24 | -------------------------------------------------------------------------------- /rules/SOC.md: -------------------------------------------------------------------------------- 1 | # Séparation des préoccupations (Separation Of Concerns) 2 | 3 | ## Définition 4 | 5 | > Des éléments n'ayant aucune relation conceptuelle dans un système n'ont pas à être modifiés en même temps. 6 | 7 | ## Détails 8 | 9 | > Les systèmes logiciels doivent séparer le processus de démarrage, lorsque les objets de l'application sont construits et les dépendances sont établies, de la logique d'exécution qui vient ensuite. 10 | 11 | ## Références 12 | 13 | * [Wikipédia](https://fr.wikipedia.org/wiki/S%C3%A9paration_des_pr%C3%A9occupations) 14 | 15 | --- 16 | :point_left: [Retour à l'accueil](../README.md) 17 | -------------------------------------------------------------------------------- /solid/ISP.md: -------------------------------------------------------------------------------- 1 | # ISP : Interface Segregation Principle 2 | 3 | ## Définition 4 | 5 | > Le principe de la ségrégation des interfaces indique qu’une classe ne doit pas avoir accès à des fonctions qui ne lui sont pas nécessaires. 6 | 7 | ## Détails 8 | 9 | * Le risque apparaît que des fonctions inutiles soient disponibles. 10 | * L'intérêt est également de réduire au maximum le couplage. 11 | 12 | ## Références 13 | 14 | * [Wikipédia](https://en.wikipedia.org/wiki/Interface_segregation_principle) 15 | * [Blog Analyse Logicielle](http://web2.cegepat.qc.ca/~claudeboutet/index.php/2017/03/03/segregation-des-interfaces/) 16 | * [Blog Matthias Jouan](https://blog.mjouan.fr/solid-partie-iv-interface-segregation-principle/) 17 | 18 | --- 19 | :point_left: [Retour à l'accueil](../README.md) 20 | -------------------------------------------------------------------------------- /rules/demeter.md: -------------------------------------------------------------------------------- 1 | # Loi de "Déméter" 2 | 3 | ## Définition 4 | 5 | > Un module ne doit pas connaître les détails internes des objets qu'il manipule. 6 | 7 | > Les modules ne connaissent que leurs collaborateurs immédiats et ne peuvent pas parcourir l'intégralité du système ou d'un graphe d'objets. 8 | 9 | ## Détails 10 | 11 | Les objets cachent leurs données et exposent des opérations. 12 | 13 | Une méthode f d'une classe C ne doit appeler que les méthodes des éléments suivants : 14 | 15 | * C 16 | * un objet créé par f 17 | * un objet passé en argument à f 18 | * un objet contenu dans une variable d'instance de C 19 | 20 | ## Références 21 | 22 | * [Wikipédia](https://fr.wikipedia.org/wiki/Loi_de_D%C3%A9m%C3%A9ter) 23 | 24 | --- 25 | :point_left: [Retour à l'accueil](../README.md) 26 | -------------------------------------------------------------------------------- /solid/OCP.md: -------------------------------------------------------------------------------- 1 | # OCP : Open-Closed Principle 2 | 3 | ## Définition 4 | 5 | > Capacité d'être ouvert à l'extension mais fermé aux modifications. 6 | 7 | ## Détails 8 | 9 | Il faut pouvoir modifier le comportement d'un module sans en modifier le code. 10 | 11 | ## Références 12 | 13 | * [Wikipédia](https://fr.wikipedia.org/wiki/Principe_ouvert/ferm%C3%A9) 14 | * [Blog Xebia](http://blog.xebia.fr/2014/05/19/screencast-sur-lopenclosed-principle/) 15 | * [Blog Pierre Gillon](http://www.pierregillon.com/2013/05/le-o-de-solid-openclosed-principle-ocp.html) 16 | * [Blog Emmanuel Deloget](http://blog.emmanueldeloget.com/index.php?post/2006/09/21/15-le-principe-ouvert-ferme) 17 | * [Blog Victor Freches](http://objet-java.blogspot.fr/2012/12/principe-ouvertferme-openclose.html) 18 | 19 | --- 20 | :point_left: [Retour à l'accueil](../README.md) 21 | -------------------------------------------------------------------------------- /solid/LSP.md: -------------------------------------------------------------------------------- 1 | # LSP : Liskov Substitution Principle 2 | 3 | ## Définition 4 | 5 | > Les sous classes doivent pouvoir être substituées à leur classe de base sans altération le comportement. On doit pour utiliser n'importe quelle classe dérivée de la classe de base sans avoir à modifier l'existant. 6 | 7 | ## Détails 8 | 9 | Principe édicté par Barbara Liskov en 1988 10 | 11 | ## Références 12 | 13 | * [Wikipédia](https://fr.wikipedia.org/wiki/Principe_de_substitution_de_Liskov) 14 | * [Article Vincent PENANDO](http://www.supinfo.com/articles/single/373-principe-substitution-liskov-lsp) 15 | * [Blog Emmanuel Deloget](http://blog.emmanueldeloget.com/index.php?post/2006/10/12/18-le-principe-de-substitution-de-liskov) 16 | * [dotnetdojo](http://www.dotnetdojo.com/concevoir-des-applications-solid-lsp/) 17 | 18 | --- 19 | :point_left: [Retour à l'accueil](../README.md) 20 | -------------------------------------------------------------------------------- /solid/DIP.md: -------------------------------------------------------------------------------- 1 | # DIP : Dependency Inversion Principle 2 | 3 | ## Définition 4 | 5 | > Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions. 6 | 7 | > Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions. 8 | 9 | ## Détails 10 | 11 | * A ne pas confondre avec l'injection de dépendances (DI) 12 | 13 | ## Références 14 | 15 | * [Wikipédia](https://fr.wikipedia.org/wiki/Inversion_des_d%C3%A9pendances) 16 | * [dotnetdojo](https://www.dotnetdojo.com/concevoir-des-applications-solid-avec-dip/) 17 | * [Le méchant blog](http://www.mechantblog.com/2014/05/solid-d-dependency-inversion/) 18 | * [Blog Emmanuel Deloget](http://blog.emmanueldeloget.com/index.php?post/2006/11/30/19-le-principe-d-inversion-de-dependance) 19 | 20 | --- 21 | :point_left: [Retour à l'accueil](../README.md) 22 | -------------------------------------------------------------------------------- /rules/YAGNI.md: -------------------------------------------------------------------------------- 1 | # YAGNI : You Ain't Gonna Need It 2 | 3 | ## Définition 4 | 5 | > Ce principe (issu de l'_eXtreme Programming_) indique de ne pas se baser sur d'hypothétiques évolutions futures pour faire les choix du présent. 6 | 7 | ## Détails 8 | 9 | * Notre code doit être pragmatique, non spéculatif. Il ne doit contenir que le nécessaire. 10 | * On ne prévoit pas des fonctionnalités et surtout on ne les développe que lorsqu'on en a réellement besoin. 11 | * Il est préférable de faire du refactoring uniquement quand on ajoute une fonctionnalité plutôt que de prévoir la future mise en place de celle-ci. 12 | 13 | ## Avantages 14 | 15 | * Gain de productivité 16 | * Gain de temps 17 | * Gain de maintenabilité : moins de complexité 18 | 19 | ## Références 20 | 21 | * [Wikipédia](https://fr.wikipedia.org/wiki/YAGNI) 22 | 23 | --- 24 | :point_left: [Retour à l'accueil](../README.md) 25 | -------------------------------------------------------------------------------- /summury/octo-culture-produit.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : OCTO - Culture Produit - 2023 2 | 3 | :link: 4 | 5 | ## Préface 6 | 7 | > Le _Product Management_ est une discipline doit vous mener à trouver vos utilisateurs, à les comprendre de manière durable, et à générer de la valeur et par extension du profit. 8 | 9 | ## Chapitre 1 : Les mots ont un sens 10 | 11 | TODO 12 | 13 | ## Chapitre 2 : Product Strategy : De l’inspiration à l’ambition 14 | 15 | TODO 16 | 17 | ## Chapitre 3 : Product Discovery : De l’ambition à la promesse 18 | 19 | TODO 20 | 21 | ## Chapitre 4 : Product Delivery : De la promesse à l’expérimentation 22 | 23 | TODO 24 | 25 | ## Chapitre 5 : Product Learning : De l’expérimentation à l’usage 26 | 27 | TODO 28 | 29 | ## Chapitre 6 : Product Structure : L'organisation produit 30 | 31 | TODO 32 | 33 | ## Conclusion 34 | 35 | TODO 36 | 37 | --- 38 | :point_left: [Retour à l'accueil](../README.md) 39 | -------------------------------------------------------------------------------- /off-topic/brooks.md: -------------------------------------------------------------------------------- 1 | # Loi de Brooks - deuxième version logicielle 2 | 3 | > Tout informaticien ayant réalisé la version originale d'un logiciel a tendance à incorporer dans la deuxième version toutes les fonctions qu'il n'avait pu intégrer, faute de temps, dans la première. Or cette initiative, apparemment heureuse, comporte de réels dangers : 4 | 5 | * bouleverser l'aspect du logiciel, auquel les utilisateurs de la version originale avaient fini par s’habituer; 6 | * automatiser des séquences de tâches que l'utilisateur effectuait volontiers lui-même dans la première version, ce qui alourdit l'interface; 7 | * promouvoir des fonctionnalités obsolescentes; 8 | * faire exploser la taille du logiciel; 9 | * et surtout perdre l'unité conceptuelle du logiciel (les spécifications d'origine) qui régissait la première version, en cherchant à imiter la concurrence. 10 | 11 | > Un informaticien développant une deuxième version devrait donc être conscient du besoin de stabilité de l'utilisateur moyen et du risque de dépassement des spécifications exigées. 12 | 13 | --- 14 | :point_left: [Retour à l'accueil](../README.md) 15 | -------------------------------------------------------------------------------- /appendices/mauvaises-pratiques.md: -------------------------------------------------------------------------------- 1 | # Mauvaises pratiques 2 | 3 | Liste de pratiques reconnues comme étant mauvaises voire néfastes. 4 | 5 | ## Généralités 6 | 7 | * Reporter la correction d'un problème à plus tard. 8 | * Axer ou concentrer la gestion de la qualité sur une personne et pas sur l'ensemble de l'équipe. 9 | 10 | ## Développements inutiles 11 | 12 | * Design complexe (_Over Design_). 13 | * Optimisation prématurée (_Over Engineering_). 14 | * Implémentation de fonctionnalités non désirées ou _au cas où_ (principe YAGNI _You Ain't Gonna Need It_). 15 | 16 | ## Refactoring risqué 17 | 18 | * Faire du _refactoring_ sans test. 19 | * Faire du _refactoring_ sans une bonne couverture de code. 20 | * Mélanger du _refactoring_ avec l'ajout de fonctionnalités ou d'autres modifications non liées. 21 | * Faire du _refactoring_ de masse (au lieu de petites étapes avec validation successives). 22 | 23 | ## Management 24 | 25 | * Dévaloriser le rôle des développeurs : _ce n'est que du code_. 26 | * Détournement des principes ou méthodes Agiles pour les calquer tant bien que mal sur le fonctionnement historique de l'entreprise. 27 | * Manque de confiance envers l'équipe. 28 | * Manque de responsabilisation de l'équipe. 29 | * Manque de délégation. 30 | 31 | --- 32 | :point_left: [Retour à l'accueil](../README.md) 33 | -------------------------------------------------------------------------------- /rules/DRY.md: -------------------------------------------------------------------------------- 1 | # DRY : Don't Repeat Yourself 2 | 3 | ## Définition 4 | 5 | > Principe qui consiste à éviter la redondance de code au travers de l’ensemble d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière. 6 | 7 | > Principe DRY : chaque élément de connaissance doit avoir une représentation UNIQUE, NON AMBIGUË, OFFICIELLE dans un système (cette représentation doit donc faire autorité) 8 | 9 | ## Détails 10 | 11 | * **La redondance est le principal ennemi d'un système bien conçu.** 12 | * **Une redondance représente en réalité une opportunité d'abstraction manquée.** 13 | * La duplication va à terme être oubliée, on pensera à faire une modification/évolution d'un côté mais on en oubliera forcément, tôt ou tard, d'autres. 14 | 15 | ## Avantages 16 | 17 | * Gain de productivité 18 | * Gain de robustesse 19 | * Gain de maintenabilité 20 | 21 | ## Inconvénients 22 | 23 | * Couplage fort ? Il faut mesurer entre le gain et l'intérêt entre la mutualisation et le couplage. 24 | * 2 éléments de même nom peuvent représenter des intentions différentes dans des contextes différents. 25 | * En essayant de rassembler ces 2 intentions on va complexifier et coupler 2 codes qui n'ont rien à voir. 26 | 27 | ## Références 28 | 29 | * [Wikipédia](https://fr.wikipedia.org/wiki/Ne_vous_r%C3%A9p%C3%A9tez_pas) 30 | * [Le principe DRY par Bruno Orsier](https://bruno-orsier.developpez.com/principes/dry/) 31 | 32 | --- 33 | :point_left: [Retour à l'accueil](../README.md) 34 | -------------------------------------------------------------------------------- /appendices/complexite.md: -------------------------------------------------------------------------------- 1 | # Notions de complexité 2 | 3 | On distinguera essentiellement 3 notions de complexité : 4 | 5 | * la [complexité essentielle](https://fr.wikipedia.org/wiki/Complexit%C3%A9_essentielle) 6 | * la complexité obligatoire 7 | * la [complexité accidentelle](https://fr.wikipedia.org/wiki/Complexit%C3%A9_accidentelle) 8 | 9 | ## Complexité essentielle 10 | 11 | > La complexité essentielle relative à un problème, généralement dans le cadre d'un projet informatique, désigne le degré de complexité minimal d'un programme pour résoudre un problème ou appliquer une solution. 12 | 13 | C'est sensé être uniquement la complexité du métier sous-jacent. **Celle-ci ne peut en aucun cas être réduite.** 14 | 15 | ## Complexité obligatoire 16 | 17 | > La complexité obligatoire est la complexité qui est nécessaire pour que le logiciel rende un service. 18 | 19 | ## Complexité accidentelle 20 | 21 | > En développement logiciel le terme complexité accidentelle désigne la complexité introduite dans des programmes informatiques non en raison de la complexité du problème, mais de manière accidentelle en raison de choix de développement non pertinents. 22 | 23 | ## Maîtriser la complexité 24 | 25 | Cette complexité doit être réduite et **à défaut il faut la maîtriser** car très coûteuse sur le long terme, par exemple via : 26 | 27 | * Décomposition 28 | * Abstractions 29 | * Application de _Design Patterns_ 30 | * Application du principe KISS 31 | * Application du principe de couplage faible / modularité 32 | * Application du principe d'orthogonalité 33 | * Pas d'_over-engineering_, d'optimisation prématurée, de fonctionnalités "au cas où" 34 | * _Refactoring_ régulier 35 | 36 | ## Références 37 | 38 | * [Blog Lilobase - Certaines complexités sont plus utiles que d’autres](https://www.lilobase.me/certaines-complexites-sont-plus-utiles-que-dautres/) 39 | 40 | --- 41 | :point_left: [Retour à l'accueil](../README.md) 42 | -------------------------------------------------------------------------------- /appendices/coding-dojos.md: -------------------------------------------------------------------------------- 1 | # Les Coding Dojos 2 | 3 | ## Présentation 4 | 5 | Les Coding Dojos, pratique issue de l'_eXtreme programming_, sont des séances de programmation à plusieurs qui peuvent prendre différentes formes : 1 instructeur ou des binômes tournant. 6 | 7 | Chaque Coding Dojo porte sur un sujet particulier et clairement identifié et validé avant la séance. Les Coding Dojos permettent d'expérimenter, de tester et d'apprendre en dehors du cadre d'un projet. 8 | 9 | :information_source: Remarques : 10 | 11 | * on ne cherche pas forcément à résoudre un problème, mais plutôt à pratiquer. 12 | * on ne cherche pas non plus la solution optimale ou la meilleure. 13 | * seules les personnes motivées doivent y participer. 14 | * ce doit être un moment convivial. 15 | * la pratique du TDD est fortement conseillée. 16 | 17 | ## Avantages 18 | 19 | * Entraînement / pratique 20 | * Apprentissage continu 21 | * Apprentissage collectif 22 | * Partage des connaissances 23 | * Cohésion d'équipe / entraide 24 | * Perfectionnement 25 | * Développer ses connaissances et apprendre de ses erreurs 26 | 27 | ## Différents types 28 | 29 | ### Kata 30 | 31 | C'est une démonstration en live de la réalisation d'un défi de programmation en partant de zéro. L'exercice est présenté et réalisé par la personne ayant choisi le sujet du coding dojo en expliquant chaque étape. 32 | 33 | ### Randori 34 | 35 | L'objectif est d'implémenter une solution de façon collaborative par binôme et en changeant régulièrement, les participants se succédant en binômes en _pair-programming_ pour faire avancer le sujet. 36 | 37 | ## Liens 38 | 39 | * :fr: [codingdojo.org](http://codingdojo.org/fr/) 40 | * :fr: [Page Wikipédia](https://fr.wikipedia.org/wiki/Coding_dojo) 41 | * :fr: [Un Chti café - Coding Dojo en entreprise](http://www.unchticafe.fr/2010/03/coding-dojo-en-entreprise.html) 42 | 43 | --- 44 | :point_left: [Retour à l'accueil](../README.md) 45 | -------------------------------------------------------------------------------- /summury/octo-culture-devops-1.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : OCTO - Culture DevOps vol. 1 - 2018 2 | 3 | :link: : 4 | 5 | ## Morceaux choisis 6 | 7 | - La véritable ambition de DevOps c'est de vouloir un produit logiciel qui soit à la fois de bonne qualité et disponible rapidement 8 | - La mutualisation des ressources et des expertises techniques dans une entité centrale d'ingénierie infrastructure et de production rencontre des limites 9 | - La philosophie Lean s'inscrit dans une vision long terme privilégiant le développement des personnes plutôt que les objectifs financiers à court terme 10 | - Donner l'autonomie sans la responsabilité ou la responsabilité sans l'autonomie c'est comme offrir un un hachoir à un bébé 11 | - DevOps doit faire passer l'organisation d'un modèle orienté projet et pools de compétences à un modèle orienté produit ou chaque équipe est en autonomie responsable 12 | - L'autonomie responsable est la convergence de la prise de décision, de la liberté d'action et de la responsabilité du résultat 13 | - ... des comités d'architecture ou de sécurité qui se positionnent comme des instances centrales d'approbation sur le chemin critique de chaque nouveau projet ... sont souvent perçues par les équipes comme au frein au Time to Market 14 | - Les savoirs ne se divisent pas, ils ne s'additionnent pas, mais ils se multiplient lorsqu'on les partage 15 | - Le poids des règles du passé peut étouffer à feu doux la capacité d'adaptation de l'organisation 16 | - L'échec est une opportunité d'apprendre, il convient dans ce contexte de ne pas sanctionner l'erreur 17 | - Le hacking de la culture doit se faire sur le modèle de contagion virale, en faisant changer les comportements localement pour qu'ils se transmettent de proche en proche 18 | - L'autonomie d'une équipe est fragile, elle peut aisément être abîmée par une dépendance vis-à-vis d'une expertise clé extérieure à l'équipe (la composition des membres de l'équipe doit évoluer dans le temps en fonction des besoins) 19 | - Faire partie de l'équipe induit un engagement proche du temps plein pour les activités de l'équipe et une participation assidue aux rituels 20 | - La transformation doit être portée au niveau le plus haut du SI, ni côté DEV ni côté OPS mais au dessus 21 | 22 | ## Anti-patterns 23 | 24 | - Dépendances de compétences clés en dehors de l'équipe 25 | - Mutualisation des ressources clés entre plusieurs équipes DevOps 26 | - Gouvernance technologique ou méthodologique trop assertive 27 | - Couplage fort entre les architectures de 2 produits 28 | - La distance géographique comme frein à la collaboration 29 | - L'équipe DevOps comme proxy entre DEV et OPS 30 | - Implémentation rigide d'ITIL 31 | 32 | ## Conclusion 33 | 34 | - Vous devrez déraciner les vieilles habitudes pour y planter la fragile graine de la culture DevOps. [page 83] 35 | - DevOps est une opportunité de prouver qu'il n'y a pas de fatalisme dans nos entreprises et que nous pouvons - peut être - vivre le bonheur d'avoir pour métier sa passion. [page 89] 36 | 37 | --- 38 | :point_left: [Retour à l'accueil](../README.md) 39 | -------------------------------------------------------------------------------- /appendices/ADR.md: -------------------------------------------------------------------------------- 1 | # Architectural Decision Records (ADR) 2 | 3 | ## Généralités 4 | 5 | L'idée est de créer **au plus proche** du code source un dossier contenant les décisions prises concernant l'architecture du projet (architecture applicative ou plus générale, on pourrait dire des "IDR" : _Important Decision Records_). 6 | 7 | C'est une sorte de journal de toutes les décisions architecturales prises durant la vie du projet. 8 | 9 | Ces décisions doivent donc y être toutes listées et **justifiées** pour pouvoir s'y référer à tout moment. 10 | 11 | La rédaction de ces fiches doit être la plus simple et la plus rapide possible, le format **Markdown** y est donc tout à fait adapté. 12 | 13 | ## Avantages 14 | 15 | * Comme pour un véhicule c'est en quelque sorte le carnet d'entretien de l'application permettant de connaître l'historique des choix fait sur le projet. 16 | * Apporte des éléments historiques et de contexte dans le cadre de nouveaux arrivants sur projet (facilite le _turn-over_). 17 | * Apporte des éléments historiques et de contexte pour les auditeurs. 18 | * Rédiger la documentation nous force à bien comprendre le sujet et à se poser des questions pouvant parfois remettre en cause la décision prise. 19 | 20 | ## Quelques règles que l'on peut s'imposer 21 | 22 | * Un fichier _Markdown_ par décision, par exemple en respectant un formalisme du type `20181001_decision.md`. 23 | * ... et contenant à minima les sections : 24 | * **Context** : _What is the issue we're seeing that is motivating this decision or change_ 25 | * **Decision** : _What is the change that we're actually doing_ 26 | * **Consequences** : _What becomes easier or more difficult to do because of this change_ 27 | * Optionnellement rajouter : 28 | * la date 29 | * les personnes ayant prises la décision 30 | * un statut : accepté, remplacé, ... 31 | * les alternatives non retenues 32 | 33 | ## Quand rédiger une ADR 34 | 35 | Quelques exemples : 36 | 37 | * Lors de l'ajout, le remplacement ou la suppression d'une bibliothèque. 38 | * Lors de la modification d'un contrat d'interface. 39 | * Lors du choix d'une dette technique volontaire. 40 | * Lors de la mise en oeuvre d'une solution corrective. 41 | 42 | ## Un exemple de modèle 43 | 44 | ```markdown 45 | # DATE : TITRE 46 | 47 | ## Qui(s) 48 | 49 | > Personne(s) en charge de la modification 50 | 51 | QUI ? 52 | 53 | ## Origine 54 | 55 | > Origine de la demande / du besoin 56 | 57 | * [ ] Issue 58 | * [ ] Ticket Jira 59 | * [ ] Initiative personnelle 60 | * [ ] Autre (détailler) 61 | 62 | ## Contexte 63 | 64 | > Description du besoin impliquant le changement 65 | 66 | QUOI ? 67 | 68 | ## Décision 69 | 70 | > Description de ce qui a été mis en place 71 | 72 | COMMENT ? 73 | 74 | ## Justification 75 | 76 | > Détail des justifications des décisions retenues 77 | 78 | POURQUOI ? 79 | 80 | ## Conséquences 81 | 82 | > Description des impacts que ce changement a impliqués 83 | 84 | TODO 85 | ``` 86 | 87 | ## Ressources 88 | 89 | * :uk: [Homepage of the ADR GitHub organization](https://adr.github.io/) 90 | * :uk: [Command-line tools for working with ADR](https://github.com/npryce/adr-tools) 91 | * :uk: Blog : [Managing Architecture Decision Records with ADR-Tools](https://www.hascode.com/2018/05/managing-architecture-decision-records-with-adr-tools/) 92 | * :fr: Vidéo : [[DevFest Toulouse 2018] Architecture Decision Records: Réconciliez vous avec votre doc - Arnaud Bos](https://www.youtube.com/watch?v=EDYplU1PB5s) 93 | * :fr: Vidéo : [[Devoxx 2024 Paris] ADR: Le chaînon manquant](https://www.youtube.com/watch?v=LdmOaSDn000) 94 | 95 | --- 96 | :point_left: [Retour à l'accueil](../README.md) 97 | -------------------------------------------------------------------------------- /appendices/dette-technique.md: -------------------------------------------------------------------------------- 1 | # Notions de dette technique et de pourriture 2 | 3 | :pushpin: Concept introduit par Ward Cunningham en 1992 et qui précise que la dette technique permet de prendre des raccourcis afin d'aller plus vite dans l'élaboration de la solution mais avec une perspective obligatoire de remboursement de celle-ci. 4 | 5 | C'est un concept qui est à ne pas confondre avec celui de pourriture (détérioration du code). 6 | 7 | * Cette dégradation est **volontaire** ou **intentionnelle** pour une période déterminée et son _remboursement_ est déjà planifié **c'est de la dette technique**. 8 | * Cette dégradation est **assumée** sans intention de la rembourser **ce n'est donc pas de la dette technique, c'est de la pourriture**. 9 | * Cette dégradation est **inconsciente** (dans le pire des cas où les intervenants ne mesurent même pas son ampleur) **ce n'est donc pas de la dette technique, c'est de la pourriture**. 10 | 11 | La pourriture est donc l'accumulation de risques impliqués par les choix techniques effectués tout au long de la vie d'un projet. 12 | Autrement dit c'est l'ensemble des choix que l'on fait et qui provoqueront des **contraintes** et des **coûts** ultérieurs. 13 | 14 | C'est une menace omniprésente qui peut à tout moment mettre en péril un projet, par exemple l'accumulation de risques ou l'absence de respect des bonnes pratiques de conception et de développement. 15 | 16 | ## Détection de la pourriture 17 | 18 | ### Quotidiennement 19 | 20 | * Peur de modifier une partie du code. 21 | * Des difficultés pour ajouter de nouvelles fonctionnalités. 22 | * Les chiffrages évolutifs anormalement élevés pour une partie du code. 23 | * Les temps de développement sont de plus en plus long (forte baisse de vélocité). 24 | * Les régressions sont en augmentation et les bugs sont de plus en plus fréquents. 25 | * Seules certaines personnes sont capables de maintenir une partie du code ou pire, la connaissance s'est perdue avec le temps ou les changements de personnes. 26 | 27 | ### Technologiquement 28 | 29 | * Utilisation de technologies obsolètes (frameworks, composants applicatifs, ...). 30 | * Absence de montée de version des dépendances et framework. 31 | * Absence de montée de version des serveurs d'applications ou web. 32 | * Absence de montée de version des infrastructures. 33 | * Absence d'outillage et d'automatisation du packaging. 34 | * Absence d'outillage du poste de travail. 35 | * Application Web ne fonctionnant que sur un seul type de Browser Web (exemple IE8). 36 | 37 | ### Méthodologiquement 38 | 39 | * Mauvais choix d'architecture ou architecture obsolète. 40 | * Non-respect des normes et standards. 41 | * Pas ou peu de documentation (techniques et fonctionnelle). 42 | * Pas ou peu d’intégration continue. 43 | * Pas ou peu de contrôles qualité (SonarQube, selenium, ...). 44 | * Pas ou peu de tests unitaires / tests automatisés. 45 | * Pas ou peu de revue de code régulières. 46 | * Duplication de fonctionnalités d'un composant dans un autre ou tout autre duplication. 47 | 48 | ## Risques identifiés 49 | 50 | * Baisse de vélocité avec l'augmentation de la taille de la base de code. 51 | * La pourriture s'accroît tout au long de la vie du projet. 52 | * Des temps de développement de plus en plus long, une augmentation des régressions et des bugs de plus en plus fréquents. 53 | * Le coût de la dette augmente jusqu'à un point où il n'est plus possible de la rembourser intégralement. 54 | * La pourriture s'accroît tout au long de la vie du projet. 55 | 56 | ## Ressources 57 | 58 | * Vidéo : [Software Crafts·wo·manship - Dette technique et entropie du logiciel (Arnaud Lemaire)](https://www.youtube.com/watch?v=VKe9EE4MUxk) - 1h40 59 | * Vidéo : [La dette technique, est-ce une fatalité ? (Mickael Wegerich)](https://www.youtube.com/watch?v=C2COBA4EFrM) - 30min. 60 | 61 | --- 62 | :point_left: [Retour à l'accueil](../README.md) 63 | -------------------------------------------------------------------------------- /off-topic/regles-developpeur.md: -------------------------------------------------------------------------------- 1 | # Les grandes règles du développeur 2 | 3 | ## Les fondamentaux avant les frameworks ou les langages 4 | 5 | Il est fondamental de maîtriser les concepts sous-jacents, les principes de conceptions, les Design Patterns, ... comme autant de socles solides avant de se lancer dans des nouveaux frameworks ou langages. 6 | 7 | ## _Clear Code_ plutôt que _Cleaver Code_ 8 | 9 | Le code doit absolument être lisible car il sera lu et relu par des humains et pas par des machines. 10 | 11 | Le code doit donc être simple pour être maintenable. 12 | 13 | ## Ne jamais négliger la qualité 14 | 15 | L'absence de qualité n'est pas de la dette technique que l'on remboursera. La qualité ne doit en aucun cas être sacrifiée. 16 | 17 | De plus _Clean Code_ doit être considéré comme un pré-requis pas comme un but à atteindre. C'est la base. Mais ce n'est pas suffisant. 18 | 19 | ## Nommer correctement 20 | 21 | Donner des noms clairs et précis aux objets, classes, méthodes, variables, ... Lever les ambiguïtés. 22 | 23 | Si l'on n'arrive pas à nommer clairement un concept, une variable, ... c'est qu'il y a un problème de compréhension autour de celui-ci. 24 | 25 | ## Profiter de toutes les situations 26 | 27 | ... même les moins motivantes ou gratifiantes à première vue : 28 | 29 | * pour apprendre de nouvelles choses 30 | * pour améliorer les choses en place (scripter une tâche automatisable par exemple) 31 | * pour capitaliser (documentation, kata, ...) 32 | 33 | ## _Write All Things_ 34 | 35 | Tout écrire, tout tracer. Pourquoi ? 36 | 37 | * éviter d'avoir à se répéter 38 | * éviter qu'une information ne se perde : elle est accessible, en tout lieu et en tout temps 39 | * partager, capitaliser 40 | * ne pas oublier, pouvoir y revenir plus tard. 41 | 42 | Quelques outils : 43 | 44 | * JIRA / Trello 45 | * Evernote / OneNote / Google Keep 46 | * TodoList 47 | * Post-it 48 | * etc... 49 | 50 | ## Les bonnes pratiques du développeur 51 | 52 | :link: 53 | 54 | ## Ressources 55 | 56 | ### Talk : "Entre industrialisation et artisanat, le métier de développeur" par Arnaud Lemaire 57 | 58 | * [BreizhCamp 2019](https://www.youtube.com/watch?v=itGmiTS_IPw) 59 | 60 | ### Talk : "Développeur, reprends le digital en main!" par Alain Hélaïli 61 | 62 | * [DEVOXX 2018](https://www.youtube.com/watch?v=dUKavg7H3VM) 63 | 64 | > **Transformation numérique** 65 | 66 | * Le développeur devrait être leader sur ces transformations 67 | * Le coût d’un projet devient essentiellement celui du développeur et donc sa productivité 68 | * Le développeur n'est pas un ouvrier spécialisé, c'est un mélange de raisonnement et de créativité 69 | * La transformation doit venir par le bas avec les idées des développeurs 70 | * L'innovation ne doit pas se comparer au marché existant mais au nouveau marché qu'elle va créer 71 | 72 | > **Transformation agile** 73 | 74 | * L'agilité n'est pas le cycle en V raccourci 75 | * Agile (a majuscule) n'est pas agile (a minuscule) 76 | * Manifeste : Individus et interactions avant les outils et les process => qu'est ce qu'on fait en 1er : on installe JIRA et on planifie les meetings * => tout faux ! 77 | * L’agilité s’arrête souvent au niveau de la gestion de projet, mais pas l'agilité de bout en bout ! 78 | * Notion de calcul du E-Factor et de toxicité de l'environnement de travail 79 | * Ceux qui choisissent les outils sont ceux qui les utilisent ! 80 | * Les "non développeurs" peuvent très bien utiliser des outils du développeur (git, markdown, ...) sans forcément obliger le développeur à perdre du temps dans des outils qui ne le concernent pas 81 | 82 | ### Talk : "La culture du programmeur" par Jean-Laurent de Morlhon 83 | 84 | > Développeur est un terme ambigu alors que programmeur est plus parlant et il désigne celui qui écrit et teste des programmes. 85 | 86 | > Le processus et la technique ne doivent pas prendre le pas l'un sur l'autre. Pour être un bon programmeur vous devez connaître tous les aspects du développement de logiciel. 87 | 88 | * [DEVOXX 2015](https://www.youtube.com/watch?v=tVguV3d8C_Q) 89 | * [Slides](https://fr.slideshare.net/jl.morlhon/culture-du-programmeur) 90 | 91 | ### Talk : "Guide de survie du développeur passionné en milieu hostile" par Christophe PONT et Charlotte CAVALIER 92 | 93 | * [DEVOXX 2017](https://www.youtube.com/watch?v=2mtE-IGEJLw) 94 | 95 | --- 96 | :point_left: [Retour à l'accueil](../README.md) 97 | -------------------------------------------------------------------------------- /summury/octo-culture-devops-3.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : OCTO - Culture DevOps vol. 3 - 2019 2 | 3 | :link: : _Hautement disponible, scalable, observable et sécurisée : l’infrastructure sera de qualité ou ne sera pas !_ 4 | 5 | ## Chapitre 1 - L'individu 6 | 7 | ### TDD : de nouveaux outils de tests d’infrastructure 8 | 9 | P22 : Coder consistant essentiellement à prendre une succession de décisions, il est impératif de travailler à avoir une boucle de _feed-back_ la plus rapide possible. 10 | 11 | Personne ne peut décemment penser déployer en continu du code qui ne 12 | serait pas suffisamment testé. 13 | 14 | P28 : vous assurez également la production d’une documentation via votre code de test. Si l’on se demande quel résultat est censée produire telle ou telle partie, les tests, en utilisant des cas et des valeurs concrètes, nous 15 | apporterons une réponse plus fiable qu’un document Word ou PDF obsolète. 16 | 17 | ### Limites et stratégie 18 | 19 | P38 : Écrire un test, c’est faire un investissement en temps. 20 | 21 | Plus un test est rapide (à développer et à exécuter), plus il sera exécuté souvent, plus il aura de la valeur. 22 | 23 | Nomenclature des tests logiciels 24 | 25 | ## Chapitre 2 - L'Équipe 26 | 27 | P49 : La connaissance ne circule jamais à 100 % lorsque chacun est sur son 28 | écran. 29 | 30 | ### Collective Code Ownership 31 | 32 | P50 : Pouvoir modifier le code de n’importe qui, n’importe quand, est un bon 33 | indicateur de la qualité d’un code. 34 | 35 | Code Reviews: Just Do It 36 | 37 | P52 : 38 | 39 | P53 : D'expérience, le mob programming est très bénéfique en début de projet lorsqu’on doit constamment prendre des décisions sur les conventions de l’équipe, les choix de design et les apprentissages fonctionnels et techniques. Il facilite l'amorce des sujets complexes et 40 | structurants, qui nécessitent un alignement des convictions et de l’expertise technique. 41 | 42 | ### Clean Code 43 | 44 | P56: L’architecture d’une stack applicative doit suivre les mêmes règles, et réussir à faire la part entre simplicité et efficacité. 45 | 46 | ### Continuous Integration 47 | 48 | P62 : Un pipeline qui n’exécute (presque) aucun test perd environ 99 % de son intérêt. Il permet juste d’envoyer plus vite des bugs en production. Pas de tests, pas de qualité. Pas de qualité, pas de confiance. Pas de confiance, pas de prod. 49 | 50 | ## Chapitre 3 - L'Entreprise 51 | 52 | P69 : chaque équipe est indépendamment constituée selon les expertises 53 | nécessaires à sa tâche, et est capable de prendre des décisions structurantes sans en référer à 8 étages de management. 54 | 55 | ...les équipes d’infrastructure sont encore trop dans leur monde : elles gèrent le run comme si c’était de leur unique responsabilité. Tant que l’on reste “dans les clous” de ce qu’ils proposent, tout va bien... 56 | 57 | ### Continuous Delivery 58 | 59 | P72 : Proscrire toute modification manuelle sur les machines. 60 | 61 | Si un changement doit être opéré, c’est en reconstruisant une nouvelle capacité (VM, conteneur...) à la place d’une ressource existante et non en modifiant une ressource existante. 62 | 63 | ### Prod-awareness 64 | 65 | P76 : Méthode des six chapeaux 66 | 67 | * Chapeau blanc : La neutralité 68 | * Chapeau rouge : La critique émotionnelle 69 | * Chapeau noir : La critique négative 70 | * Chapeau jaune : La critique positive 71 | * Chapeau vert : La créativité 72 | * Chapeau bleu : L'organisation 73 | 74 | P77 : Avoir conscience de la production, c’est se demander ce qui va casser en premier, et comment le limiter, ainsi que comment aller plus vite pour diagnostiquer et rétablir le service. 75 | 76 | P81 : L’observabilité n’est pas un luxe, ni quelque chose qui doit intervenir “juste avant une mise en prod”. Vous devez traiter cela comme un first-class citizen , au fur et à mesure de vos développements. 77 | 78 | ### Le rôle du management 79 | 80 | P88 : **Encouragez l’émergence d’une organisation apprenante : faites du partage des bonnes pratiques une valeur centrale de votre organisation.** 81 | 82 | ## Conclusion 83 | 84 | P99 : Au sein d’une équipe, l'émulation est la meilleure des dynamiques. 85 | 86 | --- 87 | :point_left: [Retour à l'accueil](../README.md) 88 | -------------------------------------------------------------------------------- /appendices/maintenabilite.md: -------------------------------------------------------------------------------- 1 | # Maintenabilité 2 | 3 | La maintenabilité qui est la capacité du programme à être modifié sans que les fonctions existantes ne soient altérées et sans perte de temps. 4 | On peut parler aussi d'évolutivité. On pourra également rajouter la capacité du logiciel à être testé facilement, la présence, l'ajustement et la qualité de la documentation ou encore le fait d’éviter de mélanger le code métier et le code technique. 5 | 6 | :warning: **C'est le critère sur lequel il faut mettre l'accent en priorité**. 7 | 8 | ## Indicateurs de maintenabilité générale 9 | 10 | Imaginons la situation suivante, un nouveau développeur arrive sur le projet pouvons-nous lui apporter : 11 | 12 | * [ ] la documentation fonctionnelle du projet 13 | * [ ] la documentation technique du projet (comment installer, configurer, préparer son poste de travail, ...) 14 | * [ ] les normes internes à respecter 15 | * [ ] le dictionnaire des des données ou un glossaire ou une description des acronymes utilisés 16 | * [ ] les moyens de versionner son code (système de gestion de versions : Git) 17 | * [ ] les moyens de tester son code (environnement, jeux de données, cas de test) 18 | * [ ] les moyens de suivre la qualité de son code (IDE, inspection continue, ...) 19 | * [ ] les moyens d'accompagnement et de montée en compétence sur le métier et les techniques 20 | * [ ] du support technique sur les technologies utilisées 21 | 22 | ## Indicateurs de maintenabilité du code 23 | 24 | * [ ] lisibilité : organisation, indentation et mise en forme générale 25 | * [ ] homogénéité : nommage et uniformisation via le respect des conventions de codage 26 | * [ ] couplage minimum (modules indépendants) 27 | * [ ] complexité cyclomatique minimale 28 | * [ ] présence de documentation, commentaires 29 | * [ ] dette technique maîtrisée 30 | * [ ] pas de _magic numbers_ ou autres termes non explicites (acronymes, ...) 31 | 32 | :information_source: Le développeur passe plus de temps à lire du code qu'à en écrire. Il est donc important de rendre celui-ci le plus **lisible** possible, notamment en exprimant clairement les intentions. Le code est écrit avant tout pour les humains et non pour les machines. 33 | 34 | ## Gains 35 | 36 | * Faciliter la compréhension du code s'est faciliter son appropriation. 37 | * Limiter les bugs. 38 | 39 | ## Bonnes pratiques 40 | 41 | ### L'importance du nommage 42 | 43 | :information_source: Les normes de nommages doivent être débattues, validées et documentées. 44 | 45 | * Favoriser toujours le confort de lecture par rapport au confort d'écriture. 46 | * Choisir des noms qui **révèlent les intentions**. Les commentaires deviennent de fait superflus. 47 | * Choisir des noms qui sont prononçables, facilitant ainsi la discussion entre développeurs. 48 | * Choisir des noms qui sont facile à rechercher. 49 | * Éviter les ajouts parasites inutiles : 50 | * pour une classe, comme les suffixes `*Data` ou `*Info`, le mot de base se suffit généralement à lui même. 51 | * pour une variable, comme des informations sur l'implémentation : `*List`, `*Map`, ... 52 | * Évidemment les noms de classes représentent des concepts : on utilise des noms, groupes nominaux. 53 | * Évidemment les noms de méthodes représentent des actions : on utilise des verbes, ou groupes verbaux. 54 | * Évidemment ne pas de mélanger différentes langues dans le même nom. 55 | * Adapter le nommage en fonction de leur _scope_ (portée) : 56 | * pour une variable plus sa portée est large plus son nom doit être long et informatif. 57 | * pour une classe ou une méthode, inversement, plus sa portée est grande et son propos générique plus son nom sera court et proche du concept quel traite. Une classe ou méthode privée effectuera elle un traitement beaucoup plus spécifique avec un nom beaucoup plus descriptif. 58 | * Utiliser plutôt des suffixes (`*DAO` que `DAO*`). Dans tous les cas respecter le choix et ne pas mélanger. 59 | * **Choisir un mot par concept :** statuer et documenter (document de normes, lexique) sur les termes à employer et ne pas employer différents termes pour exprimer la même chose. Exemples : 60 | * Lire : `query`, `find`, `select`, `fetch`, `retrieve`, ... 61 | * Mettre à jour : `update`, `modify`, `merge`, `replace`, ... 62 | * Classe de gestion : `*Helper`, `*Manager`, `*Handler`, ... 63 | * Outils : `*Tool`, `*Tools`, `*Util`, `*Utils`, ... 64 | * pire parfois on peut mélanger les concepts : `*Client`, `*Proxy`, `*Stub`, `*Mock`, `*Fake` 65 | 66 | ### L'importance de la documentation 67 | 68 | * Elle permet de poser les normes et lever les ambiguïtés. 69 | * Elle permet d'accompagner les nouveaux arrivants. 70 | * Elle permet de rafraîchir la mémoire des différents acteurs. 71 | * Elle renforce l'autonomie. 72 | * Elle force le développeur à expliquer son programme, ses choix et donc à se poser des questions, et parfois à se remettre en question en levant des par exemple des manques ou des incohérences. 73 | 74 | ### Les méthodes / fonctions 75 | 76 | * Éviter de passer trop de paramètres à une méthode. 77 | * Éviter de passer des paramètres `null` à une méthode : faire plusieurs méthodes. 78 | * Éviter de passer une valeur booléenne dans les paramètres d’une méthode : faire 2 méthodes. 79 | * Éviter de retourner `null`. 80 | * Éviter les effets de bord. Une méthode ne doit pas altérer/modifier ses paramètres d'entrée. A noter qu'en Java l'ajout du mot clef `final` ne garantie rien (seulement que la variable ne sera pas ré-affectée mais pas que son contenu ne soit pas altéré, c'est pour cela qu'il faut favoriser les implémentations immuables). 81 | 82 | --- 83 | :point_left: [Retour à l'accueil](../README.md) 84 | -------------------------------------------------------------------------------- /off-topic/lois-et-principes.md: -------------------------------------------------------------------------------- 1 | # Lois et principes 2 | 3 | ## Lois 4 | 5 | ### Loi de Conway 6 | 7 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Loi_de_Conway) 8 | 9 | > :fr: Les organisations qui définissent des systèmes ... sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation. 10 | 11 | ### Loi de Parkinson 12 | 13 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Loi_de_Parkinson) 14 | 15 | > :uk: _Work expands so as to fill the time available for its completion. General recognition of this fact is shown in the proverbial phrase: It is the busiest man who has time to spare)_ 16 | 17 | > :fr: Tout travail au sein d'une administration augmente jusqu’à occuper entièrement le temps qui lui est affecté. 18 | 19 | ### Loi de futilité de Parkinson 20 | 21 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Loi_de_futilit%C3%A9_de_Parkinson) 22 | 23 | > :fr: Les organisations donnent une importance disproportionnée à des questions futiles : les éléments les plus basiques et inutiles d'un projet seraient discutés longuement, car compris par tous et donc faciles à traiter, au détriment des éléments plus importants et complexes. 24 | 25 | ### Loi de Brooks 26 | 27 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Le_Mythe_du_mois-homme) 28 | 29 | > :fr: Ajouter des ressources humaines à un projet en retard sur les prévisions ne fait qu'accentuer ce retard. 30 | 31 | ### Loi de Hofstadter 32 | 33 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Loi_de_Hofstadter) 34 | 35 | Ou _Loi de glissement de planning_. 36 | 37 | > :fr: Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. 38 | 39 | ### Loi de Murphy 40 | 41 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Loi_de_Murphy) 42 | 43 | > :fr: Tout ce qui est susceptible de mal tourner tournera mal. 44 | 45 | > :fr: **Variante :** S'il existe au moins deux façons de faire quelque chose et qu'au moins l'une de ces façons peut entraîner une catastrophe, il se trouvera forcément quelqu'un quelque part pour emprunter cette voie. 46 | 47 | > :fr: **Variante : Corollaire de Finagle :** Si quelque chose peut tourner mal, se sera au pire moment. 48 | 49 | ### Loi de Say 50 | 51 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Loi_de_Say) 52 | 53 | > :fr: L'offre crée sa propre demande. 54 | 55 | ### Loi de Carlson 56 | 57 | > :fr: Un travail réalisé en continu prend moins de temps et d’énergie que lorsqu'il est réalisé en plusieurs fois 58 | 59 | ### Loi de Laborit 60 | 61 | Ou **Loi du moindre effort.** 62 | 63 | > :fr: Chaque individu a une inclination naturelle à d'abord faire les choses qui lui font plaisir. 64 | 65 | > :fr: Le comportement humain nous incite à faire en premier ce qui nous fait plaisir. Au travail nous avons tendance par instinct à « chercher la satisfaction immédiate » et à « fuir le stress ». 66 | 67 | ### Loi de Goodhart 68 | 69 | > :fr: Lorsqu'une mesure devient un objectif, elle cesse d'être une mesure pertinente. 70 | 71 | ### Loi d'Eagleson 72 | 73 | > :fr: N'importe quel code que vous n'avez pas examiné depuis six mois ou plus aurait tout aussi bien pu être écrit par quelqu'un d'autre. 74 | 75 | ### Loi de Godwin 76 | 77 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Loi_de_Godwin) 78 | 79 | > :fr: Plus une discussion en ligne dure longtemps, plus la probabilité d'y trouver une comparaison impliquant les nazis ou Adolf Hitler s’approche de 1. 80 | 81 | ## Principes 82 | 83 | ### Principe de Peter 84 | 85 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Principe_de_Peter) 86 | 87 | > :fr: Dans une hiérarchie, tout employé a tendance à s'élever à son niveau d'incompétence. 88 | 89 | > :fr: **Corollaire :** Avec le temps, tout poste sera occupé par un employé incapable d'en assumer la responsabilité. 90 | 91 | ### Principe de Dilbert 92 | 93 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Principe_de_Dilbert) 94 | 95 | > :fr: Les gens les moins compétents sont systématiquement affectés aux postes où ils risquent de causer le moins de dégâts : ceux de managers. 96 | 97 | Version aggravée et humoristique du principe de Peter 98 | 99 | ### Principe de Pareto 100 | 101 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Principe_de_Pareto) 102 | 103 | > :fr: environ 80% des effets sont le produit de 20% des causes. 104 | 105 | ### Rasoir d'Ockham 106 | 107 | Ou **principe de simplicité**, **principe d'économie** ou **principe de parcimonie**. 108 | 109 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Rasoir_d%27Ockham) 110 | 111 | > :fr: Les hypothèses suffisantes les plus simples doivent être préférées. 112 | 113 | ### Rasoir d'Hanlon 114 | 115 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Rasoir_d%27Hanlon) 116 | 117 | > :uk: _Never attribute to malice that which is adequately explained by stupidity._ 118 | 119 | > :fr: Ne jamais attribuer à la malveillance ce que la bêtise suffit à expliquer. 120 | 121 | ## Autres 122 | 123 | ### La courbe d'Allen 124 | 125 | La courbe de Thomas J. Allen décrit une décroissance exponentielle de la communication entre 2 personnes en fonction de la distance qui les sépare. Autrement dit la probabilité de communication entre deux individus baisse extrêmement rapidement en fonction de la distance les séparant. 126 | 127 | Être à plus de 30m a les mêmes effets que d'être à plusieurs kilomètres. 128 | 129 | ### Mythe du mois-homme 130 | 131 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Le_Mythe_du_mois-homme) 132 | 133 | --- 134 | :point_left: [Retour à l'accueil](../README.md) 135 | -------------------------------------------------------------------------------- /summury/octo-culture-devops-2.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : OCTO - Culture DevOps vol. 2 - 2018 2 | 3 | :link: : _Le nouveau guide de survie des dev', ops et architectes !_ 4 | 5 | ## Chapitre 1 - Une API REST sinon rien 6 | 7 | * Une API est un produit avant tout (_API as a Product_) et se conçoit avec des garde-fous. 8 | * Exposer des API devient plus important que l'exposition d'interfaces Web ou le traitement de tickets. 9 | * L'API va permettre aux utilisateurs de créer leurs propres fonctionnalités par dessus l'infrastructure, démultipliant sa richesse. 10 | 11 | ## Chapitre 2 - L'open source 12 | 13 | * Nous ne sommes plus de simples utilisateurs d'une solution mais également des contributeurs en capacité de l'améliorer 14 | 15 | ## Chapitre 3 - Les architectures distribuées 16 | 17 | * Pour atteindre ces 2 objectifs (performance et disponibilité) il faut arrêter de penser scalabilité verticale (_scale-up_) et pivoter à 90° vers la scalabilité horizontale (_scale-out_). 18 | 19 | ## Chapitre 4 - L'orientation SDx 20 | 21 | * Il faut penser programmation, code et configuration pour représenter une architecture. 22 | * Offrir une SDx à vos clients vous impose une rigueur à toute épreuve dans l'automatisation de votre infra, pour être toujours prêt à réagir aux imprévus. 23 | 24 | ## Chapitre 5 - L'Infrastructure as Code 25 | 26 | * Si un DAT (dossier d'architecture technique) est régulièrement faux, pas à jour, incomplet, imprécis, une plateforme fraîchement bâtie par de l'IaC est nécessairement à l'exact image du code qui l'a produite. 27 | * Si l'on commence à modifier les machines à la main, cette assertion ne reste pas vraie très longtemps. 28 | * L'IaC est née bien avant l'apparition du terme _DevOps_. 29 | * Les pratiques _DevOps_ l'ont simplement rendue indispensable. 30 | * Les langages d'IaC sont généralement conçus autour du paradigme de programmation déclarative : 31 | * Déclaratif : Puppet, Terraform, Chef, CFEngine 32 | * Impératif : Fabric, Capistrano 33 | * Hybride : Ansible 34 | * Modes de fonctionnement : push/pull : 35 | * Mode agent de type _pull_ : Puppet, Chef, CFEngine 36 | * Mode _push_ à partir d'une machine de contrôle : Ansible, Terraform, Fabric, Capistrano 37 | * Tous les produits ne ciblent pas le même objectif. 38 | * Les outils : 39 | * Puppet : _la Rolls des IaC_ projet de référence tant au niveau de son fonctionnement qu'au niveau de l'écosystème qu'il draine. 40 | * Ansible : _le couteau suisse de l'IaC_, à la fois capable d'adresser l'approvisionnement des machines que l'orchestration "futée" du déploiement des applications. 41 | * Hashicorp Terraform : spécialisé dans l'approvisionnement des infrastructures sur des _clouds_ ou diverses technologies de virtualisation. 42 | * L'IaC atteint un niveau de maturité qui la rend incontournable de nos jours. 43 | * Le risque n'est toutefois pas éliminé à 100% si la manipulation de l'IaC ne s'accompagne pas d'une hygiène irréprochable dans la gestion et la qualité du code. 44 | * Toute l'infrastructure peut être décrite, installée, testée et versionnée. 45 | * Les administrateurs peuvent se concentrer sur l'amélioration du SI plutôt que sur des tâches facilement robotisables, sans valeur ajoutée à l'intelligence humaine. 46 | 47 | ## Chapitre 6 - La conteneurisation 48 | 49 | * Les conteneurs véhiculent des concepts vecteurs de transformations profondes de notre industrie. 50 | * _Docker_ est le fruit de l'assemblage - génial, de plusieurs concepts pré-existants. 51 | * Conteneurs et machines virtuelles permettent _in fine_ d'isoler des applications ou des processus. 52 | * La particularité de _Windows_ est de proposer deux modes de fonctionnement : faire tourner des conteneurs Window Natifs ou démarrer des portions de système Linux virtualisé pour permettre l'exécution de conteneur Linux. 53 | * Puisqu'il se résume au démarrage d'une application le coût de démarrage du conteneur est négligeable. 54 | * Dans l'esprit _Docker_ suit le principe du _rebuild_ plutôt que celui d'_upgrade_. 55 | * Une mise à jour se fait en reconstruisant une nouvelle image et en remplaçant un ancien conteneur par un nouveau basé sur cette image. 56 | * L'intérêt de ce découpage en couches est la possibilité pour 2 images (ou plus) de partager les mêmes couches, réduisant ainsi l'espace de stockage nécessaire. 57 | * Les applications doivent être pensées pour être proprement et fréquemment arrêtées et redémarrées mais aussi : 58 | * Applications dite _stateless_. 59 | * Séparation du code et de la configuration, principe du _build once, run everywhere_. 60 | * Exposition d'URL de _healthcheck_. 61 | * Exposition d'URL de métriques. 62 | * Production de logs sur les sorties standards. 63 | * Il y a une réelle nécessité de repenser les applications et les processus pour utiliser correctement les conteneurs. 64 | 65 | ## Chapitre 7 - Le cloud 66 | 67 | * Il devient très compliqué, voire impossible de conserver des versions obsolètes de logiciels (OS, middlewares, ...) 68 | * La portabilité implique malheureusement de se contenter du plus petit dénominateur commun. 69 | * Cette propension à utiliser une application ou un services à la limite - voire ne dehors - de son cadre est un frein à son passage sur le _cloud_. 70 | * Infrastructures immuables : le déploiement _blue/green_ permet de déployer une nouvelle version d'un système sans interrompre le bon fonctionnement du service. 71 | * Si vous songez à mettre votre _cloud_ derrière un outil de _ticketing_, sous la responsabilité d'un centre de service, pour en maîtriser ses usages, alors vous ne tirerez jamais parti des réels avantages du _cloud_. Vous n'avez au final, que déplacé vos serveurs dans le _datacenter_ de quelqu'un d'autre. 72 | 73 | ## Chapitre 8 - Et à part ça ? 74 | 75 | * Le mouvement _DevOps_ a remis le génie logiciel au coeur du monde de l'exploitation informatique. 76 | * Conception responsable, empreinte du numérique (_green it_), ... 77 | 78 | ## Conclusion 79 | 80 | * Vouloir absolument mettre en oeuvre tout le catalogue de ces frameworks dans son SI reviendrait à faire du "_Cargo Cult_", c'est à dire à procéder par mimétisme en s'imaginant être mature sur le sujet _DevOps_ uniquement parce qu'on a choisi tous les outils à la mode. 81 | * Sans une réelle discipline et une recherche perpétuelle de qualité dans leur mise en oeuvre, ces innovations sont vouées à faire de gros dégâts dans nos SI. 82 | * La production et les opérations sont, par nature, des lieux où le conservatisme est de mise. Or, il faut définitivement remettre ne cause ce mythe qui n'a plus lieu d'être à l'heure du numérique. 83 | 84 | --- 85 | :point_left: [Retour à l'accueil](../README.md) 86 | -------------------------------------------------------------------------------- /summury/octo-culture-code.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : OCTO - Culture Code - 2016 2 | 3 | :link: : _Software Craftsmanship : Better Places with Better Code_ 4 | 5 | ## Introduction 6 | 7 | - Nous sommes convaincus que créer des logiciels de qualité ne coûte pas plus cher, au contraire. Malheureusement, la situation dans de beaucoup d’entreprises est préoccupante. 8 | - On peut avoir l'impression d'obtenir le même logiciel avec ou sans tests automatisés [...] mais c'est dans le temps que l'écart se creusera. 9 | - Le développement de logiciels est un savoir-faire, qui s’acquiert via l’expérience et l’accompagnement de ses pairs, comme dans l’artisanat. Une simple formation n’est pas suffisante. 10 | - Software Craftsmanship (artisanat logiciel) : il ne suffit pas qu’un logiciel fonctionne, il faut également qu’il soit bien conçu. 11 | - La non-qualité du code a également des conséquences économiques concrètes 12 | - L’absence de culture de la qualité explique aussi souvent un piètre degré de satisfaction et un désengagement des développeurs 13 | 14 | ## Better Places 15 | 16 | - Pour réaliser des produits de haute qualité, il faut s’appuyer sur des personnes compétentes, motivées et même passionnées, et qui cherchent à apprendre et à s’améliorer en continu. 17 | - Travailler dans un cadre où la qualité des réalisations est négligée devient vite démotivant, notamment pour les développeurs, au risque de voir les meilleurs partir dans une autre entreprise ; un développeur préfère investir du temps pour des fonctionnalités futures plutôt qu’éponger les bugs du passé... 18 | - c’est une culture, celle de la qualité logicielle 19 | - Pour agir au mieux dans l’équipe, et collaborer efficacement avec chacun, il est utile de comprendre un minimum le métier de chacun 20 | - Adopter les valeurs « Craft » est une bonne première étape mais les partager avec ses collègues et encore plus aux managers, est la clé pour pouvoir produire du code de qualité au sein de votre entreprise. 21 | - Les développeurs sont des professionnels du développement, il est indispensable de leur accorder une certaine autonomie dans leurs pratiques. 22 | - La création de logiciel est un métier passionnant et même plutôt fun, pour peu que l’on puisse l’exercer avec application et professionnalisme dans un environnement favorable. 23 | - la qualité du code que produit votre entreprise est une affaire dont vous (=> les managers) devez vous préoccuper. 24 | - Le code est une source de valeur pour l’entreprise, et cette valeur doit être préservée par la mise en place de pratiques de développement de qualité. 25 | - Le premier principe du manager responsable d’équipes de développement est de considérer le code développé par ses équipes comme un « actif », au même titre que tout autre moyen de produire de la valeur dans l’entreprise. 26 | - Sans une discipline de tests unitaires et de revues de code, le nombre de bugs dans l’application augmente imperceptiblement. 27 | - Le manager d’une équipe de développement devrait être « dur avec les mauvaises pratiques, doux avec les personnes » 28 | - l’impact de la non-qualité sur un projet détériore les performances de son service, mais est de plus préjudiciable à la culture de l’entreprise ainsi qu’à son image 29 | - Aidez les développeurs à diffuser les bonnes pratiques en encourageant la mise en place de communautés de pratiques dans l’entreprise 30 | - Le code logiciel produit est un actif apportant de la valeur à la société qui le produit. À ce titre, il est primordial pour une organisation de tout mettre en oeuvre pour en prendre soin. 31 | - La responsabilité de cette qualité n’incombe pas seulement aux développeurs 32 | - La plupart des équipes ont besoin d’un Tech Lead qui les emmène vers une forte culture de la qualité. 33 | - Le but est de favoriser un fonctionnement collectif, dans lequel l’équipe peut prendre ses propres décisions, au lieu d’attendre simplement les ordres 34 | - Dette technique tactique : un expédient temporaire, un écart ponctuel aux standards de l’équipe, pour lequel une solution de recouvrement est non seulement identifiée, mais en plus planifiée dans le temps 35 | - Dette technique endémique : revient à désigner le code de mauvaise qualité, pour lequel aucune solution n’a été planifiée. 36 | - Vous ne pouvez pas mener un développement logiciel à coups de dettes techniques répétées, et encore moins en vous appuyant sur du code de mauvaise qualité. 37 | - Travailler seulement sur les dégâts sans tenter de changer les facteurs, c’est comme tenter d’écoper sans rechercher les voies d’eau. 38 | 39 | ## Better Code 40 | 41 | ### La revue de code 42 | 43 | - **l'outillage ne peut en aucun cas remplacer la revue de code**. Même si un grand nombre de défauts potentiels peut être relevé automatiquement, il serait dangereux de penser qu'on peut se reposer intégralement dessus. 44 | - La revue de code est une pratique technique. Donc seules les personnes compétentes techniquement doivent y participer, les animer et suivre les corrections. 45 | - la relecture du code produit est une pratique essentielle pour la qualité de l'ouvrage. Elle permet de **détecter les défauts au plus tôt et à moindre coût, renforce la propriété collective du code, favorise l'apprentissage et améliore la qualité des échanges entre développeurs**. 46 | 47 | ### Les tests 48 | 49 | - Beaucoup d'organisations ont des douleurs dans la mise en place de leur stratégie de tests, allant parfois jusqu'à abandonner les changements initiés. 50 | - Faire participer un testeur ou un analyste métier à l'élaboration des tests unitaires n'a que peu de sens : ils concernent uniquement les développeurs. 51 | - C'est un véritable gâchis d'utiliser l'énergie d'un testeur pour découvrir des défauts évidents, alors qu'il pourrait par exemple se concentrer sur des tests exploratoires. 52 | - Les tests de bout en bout ou d'IHM ne sont quant à eux pas toujours rentables en termes d'automatisation. 53 | - L'automatisation des tests fonctionnels au niveau de l'interface graphique [...] sont très sensibles aux modifications dues aux évolutions fréquentes des interfaces. Ils sont donc victimes de "faux négatifs". 54 | - Il est préférable de se concentrer sur des cas critiques dont le non-fonctionnement pourrait porter atteinte à l'activité de l'organisation. 55 | - tout code qui n'est pas couvert par des test automatisés est du _Legacy_. 56 | - Les tests deviennent une pratique centrale de l'équipe de réalisation du produit. 57 | - Mettre l'accent sur l'automatisation des tests de construction permet aussi de limiter l'effort sur les tests de contrôle, et de concentrer l'énergie des testeurs là où ils apportent le plus de valeur. 58 | - Tout temps utilisé avant le déploiement pour prévenir des défauts est du temps investi judicieusement. 59 | - Le design n'émergeait pas avec les tests, et je n'écrivais que ceux auxquels l'implémentation me faisait penser. 60 | 61 | --- 62 | :point_left: [Retour à l'accueil](../README.md) 63 | -------------------------------------------------------------------------------- /appendices/continuous-inspection.md: -------------------------------------------------------------------------------- 1 | # Inspection continue 2 | 3 | Les contrôles qualité ont pour principal intérêt de pouvoir remonter le plus rapidement possible des informations sur le produit en cours de développement afin de permettre à l’équipe de réagir tout aussi rapidement afin de minimiser les impacts. Un problème découvert trop tard peut avoir des conséquences en termes de budget, de délai ou d’image vis à vis des clients. Le coût peut en effet être multiplié par 5 si le défaut est détecté après la mise en production du produit. 4 | 5 | ## Principes et enjeux 6 | 7 | Le but de l'inspection continue, initiée par la société [_SonarSource SA_](https://www.sonarsource.com/), est de répondre aux problématiques posées par les revues humaines. Ces revues : 8 | 9 | * ne sont pas assez exhaustives 10 | * sont subjectives 11 | * interviennent trop tardivement 12 | * n'impliquent pas assez les acteurs 13 | 14 | L'inspection continue (donc outillée) permet : 15 | 16 | * d'être exécutée régulièrement (lors d'un _push_ sur le SCM par exemple) 17 | * d'obtenir un _feedback_ très rapide voire immédiat pendant que le code est encore _chaud_ dans les esprits 18 | * d'impliquer les développeurs dans un cercle vertueux d'apprentissage et d'amélioration continue 19 | * d'impliquer les développeurs dans un effort commun 20 | * d'offrir des tableaux de bord et de mesurer l'évolution au fil du temps 21 | * d'obtenir des mesures sur la base de code complète ainsi que sur le nouveau code (différentiel) 22 | * d'être objective car basée sur des règles et bonnes ou mauvaises pratiques connues 23 | 24 | :bulb: L'inspection continue est donc à mettre en place **dès le début d'un projet**, ce qui est très facile avec des outils comme _GitLab-CI_. 25 | 26 | :warning: Il est également évidemment dangereux de considérer que l'on peut se reposer uniquement sur cette pratique. Il faut bien sur la compléter avec les techniques de revue de code "humaines" : collectives et par des pairs. 27 | 28 | ## Outillage 29 | 30 | Nombre d'outils sont disponibles (directement ou non) pour remonter rapidement aux développeurs des indicateurs sur la qualité du code produit : 31 | 32 | * Les remontées d'informations directement dans l'IDE (soit nativement soit via des plugins type _SonarLint_ ou _FindBugs_). 33 | * Les contrôles de compilation et de succès des tests lors d'un _push_ (via _Jenkins_, _GitLab CI_, ...). 34 | * Les contrôles outillés quotidiens via _SonarQube_ (qui ajoutent en plus un suivi temporel grâce aux _Dashboards_). 35 | * Les analyses via des outils d'APM : l’_Application Performance Monitoring_ suit les transactions de bout en bout permettant la remontée d'informations et de métriques de toutes sortes. 36 | 37 | ### Les outils SonarQube et SonarLint 38 | 39 | #### SonarQube 40 | 41 | _SonarQube_ (anciennement _sonar_ et à ne pas confondre avec _SonarJ_) édité par la société _SonarSource SA_ est le standard du marché dans le domaine de l'analyse de la qualité du code d'une application et supporte plus d'une vingtaine de langages. 42 | _SonarQube_ définit 3 catégories de violations : 43 | 44 | * _Bugs :_ Bug avéré ou du code manifestement erroné ou très susceptible de générer un comportement inattendu. 45 | * _Vulnérabilités :_ provenant de code potentiellement vulnérable à l'exploitation par les pirates. 46 | * _Mauvaises pratiques (_Code Smells_) :_ provenant de code qui va dégrader la maintenabilité, la robustesse ou la performance. Elles sont mesurées et affichées principalement en termes de temps qu'elles prendront pour être corriger. 47 | 48 | _SonarQube_ définit également pour chaque anomalie relevée un niveau de criticité parmi 5, du plus au moins important : 49 | 50 | * _Bloquant_ (_blocker_) : anomalie à corriger immédiatement. 51 | * _Critique_ (_critical_) : anomalie à corriger rapidement. 52 | * _Majeur_ (_major_) : anomalie à étudier, une correction planifiée est souhaitable. 53 | * _Mineur_ (_minor_) : anomalie à prendre en compte si possible (souvent facile à corriger). 54 | * _Informatif_ (_info_) : anomalie à prendre en compte si possible (souvent facile à corriger). 55 | 56 | Enfin l'outil peut même amender automatiquement les _merge request_ (via [un plugin](https://github.com/gabrie-allaigre/sonar-gitlab-plugin)), les violations étant visibles dès lors directement dans GitLab. 57 | 58 | #### SonarLint 59 | 60 | _SonarLint_ du même éditeur est un _plugin_ disponible pour différents IDE (Eclipse, IntelliJ IDEA, VS Code, ...) permettant d'avoir un retour immédiat (_Fix issues before they exist_) lors de l'écriture du code (donc avant le commit) sans devoir attendre de lancer une analyse _SonarQube_. 61 | 62 | :warning: Comme tout outil, ils peuvent produire des faux-positifs, il conviendra d'analyser les rapports et anomalies relevées avec un esprit critique et ne pas se _jeter_ forcément sur tout. Dans le doute vous pouvez solliciter les équipes support. 63 | 64 | ### Tableau comparatif 65 | 66 | Quelques outils utilisables pour de l'inspection continue "au poste" (feedback immédiat) ou automatisée (feedback asynchrone) : 67 | 68 | | Langage | Objectif | Feedback immédiat dans l'IDE | Feedback asynchrone via l'inspection continue | 69 | | ------- | -------- | ---------------------------- | --------------------------------------------- | 70 | | Java | Mesurer la qualité du code source | [SonarLint (Eclipse, IntelliJ, VS Code)](https://www.sonarlint.org/) | [SonarQube](https://www.sonarqube.org/) | 71 | | Java | Déterminer la couverture de code par les tests | [EclEmma (Eclipse)](https://www.eclemma.org/), Run with Coverage (IntelliJ) | [JaCoco](https://www.jacoco.org/jacoco/trunk/doc/), [Cobertura](http://cobertura.github.io/cobertura/) | 72 | | Java | Analyser les vulnérabilités dans les dépendances tierce partie | [Snyk Vulnerabilities Scanning (IntelliJ)](https://blog.jetbrains.com/idea/2019/03/catching-vulnerabilities-instantly-in-your-intellij-idea-environment/) | [Snyk CLI](https://snyk.io/docs/using-snyk/) | 73 | | Java | Analyser les vulnérabilités dans les dépendances tierce partie | [OWASP Dependency Check](https://jeremylong.github.io/DependencyCheck/dependency-check-maven/index.html) | [OWASP Dependency Track](https://dependencytrack.org/) | 74 | | Shell | Analyse statique de code script shell | [ShellCheck (extension VS Code)](https://github.com/timonwong/vscode-shellcheck) | [ShellCheck](https://www.shellcheck.net/) + SonarQube | 75 | | JavaScript | Analyser les vulnérabilités dans les dépendances tierce partie | [Snyk CLI](https://snyk.io/docs/snyk-for-nodejs/) | [Snyk CLI](https://snyk.io/docs/continuous-integration/) | 76 | | JavaScript | Analyse statique de code JavaScript | [JSHint](https://jshint.com/) (+ [extension VS Code](https://marketplace.visualstudio.com/items?itemName=dbaeumer.jshint)) | SonarQube | 77 | | TypeScript | Analyse statique de code TypeScript | [TSLint](https://palantir.github.io/tslint/) (+ [extension VS Code](https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-typescript-tslint-plugin)) | ? | 78 | 79 | ## Ressources 80 | 81 | * :gb: [SonarSource White Paper](https://www.sonarsource.com/resources/white-papers/continuous-inspection.html) 82 | * :gb: [SonarQube](https://www.sonarqube.org/features/clean-code/) 83 | * :fr: [Blog JetBrains : Gagnez du temps sur les révisions de code et la planification de projet avec l’analyse statique](https://blog.jetbrains.com/fr/qodana/2022/01/gagnez-du-temps-sur-les-revisions-de-code-et-la-planification-de-projet-avec-l-analyse-statique/) 84 | 85 | --- 86 | :point_left: [Retour à l'accueil](../README.md) 87 | -------------------------------------------------------------------------------- /appendices/software-craftsmanship.md: -------------------------------------------------------------------------------- 1 | # Software Craftsmanship 2 | 3 | ## Historique 4 | 5 | :pushpin: [Le Manifeste](http://manifesto.softwarecraftsmanship.org/#/fr-fr) 6 | 7 | :information_source: 2009 : mise en place du "Manifesto for Software Craftsmanship" très fortement inspiré du Manifeste Agile et par le livre "The Pragmatic Programmer" publié en 1999 par Andrew Hunt et David Thomas. (avec pour base l'eXtreme Programming). 8 | 9 | Synthèse : 10 | 11 | * Avec l'orienté objet et DDD, nous pouvons modéliser le métier de nos clients. 12 | * Avec l'agile, nous pouvons faire le minimum de logiciel suffisant pour les satisfaire. 13 | * Avec les pratiques XP, nous garantissons que le logiciel est maintenable et qu'il fonctionne dans tous les cas prévus. 14 | 15 | ## La culture 16 | 17 | Leitmotiv : élever le niveau, atteindre un haut niveau de qualité 18 | 19 | * Le _Software Craftsmanship_ est donc plutôt considéré comme une culture qu'une méthode à proprement parler, une culture de la qualité logicielle. 20 | * La non qualité a un coût stratégique, mais aussi financier : une application truffée de défauts sera toujours plus coûteuse à faire évoluer, et les clients qui n'ont plus confiance risquent de ne plus vouloir payer. Il faut donc réduire le périmètre mais pas la qualité. 21 | * Diffuser la culture de la qualité : binômage, Kata, Coding Dojo, Brown Bag Lunch, revues de code, ... essentiellement tirées de XP (eXtreme Programming). 22 | * Insuffler un état d'esprit dans l'équipe. 23 | 24 | ## Concepts 25 | 26 | * Une solution doit être bien conçue techniquement mais également doit pouvoir d'évoluer rapidement. 27 | * Remettre l'accent sur les pratiques d'ingénierie logicielle et d'excellence technique. 28 | * Tout comme connaître une langue ne fait pas de vous un écrivain à succès, connaître un langage informatique ne fait pas automatiquement de vous un bon développeur. 29 | 30 | ## L'humain 31 | 32 | * La non qualité a un coût humain : travailler dans ce cadre devient vite démotivant, notamment pour les développeurs, au risque de voir les meilleurs partir dans une autre entreprise. 33 | * Certains ont adopté ces valeurs, sont souvent passionnés par leur métier : coder n'est pas qu'un moyen de gagner sa vie mais un moyen de transmettre sa vision, de donner du sens à son métier (envisager son métier comme une passion ou un art). 34 | * Beaucoup d'autres développeurs n'ont que peu ou pas conscience qu'on peut réaliser des logiciels autrement. 35 | * Développeur est une carrière à part entière, à opposer à un changement de carrière en devenant par exemple manager, architecte ou chef de projet. 36 | * Les qualités les plus fréquentes et appréciées étant le savoir-faire, l'engagement et le pragmatisme. 37 | * Le mouvement souhaite que tous les acteurs du métier deviennent professionnels et que cela deviennent la norme. 38 | * Il faut s'appuyer sur un Tech Lead qui va aider l'équipe à progresser jusqu'à ce qu'elle devienne autonome. 39 | 40 | ## Les valeurs 41 | 42 | * Professionnalisme : mettre en œuvre toutes les pratiques connues pour être les meilleures chacune dans leur contexte, pour écrire et entretenir du code. 43 | * Favoriser la collaboration et la communication entre les différents acteurs afin d'assurer la cohérence du projet, c'est une communauté qui partage, s'accompagne, s'entraide. 44 | * Pragmatisme : on ne cherche pas absolument la perfection, on cherche à faire au mieux en tenant compte du contexte. 45 | * Chercher à apprendre, encore et toujours (démarche d'amélioration continue). 46 | * Le logiciel doit être simple, économique et efficace avant tout. Ensuite on peut faire beau bien écrit et bien architecturé. 47 | * Toutes ces valeurs doivent être partagées. 48 | 49 | ## Les moyens 50 | 51 | ### Les techniques 52 | 53 | * **Test First** : Écriture d'un test unitaire avant l'implémentation 54 | * **Test-Driven Development (TDD)** : basé sur _Test First_ mais ajoute la notion de cycle _Red/Green/Refactor_ 55 | * **Continuous Integration** 56 | * vérifier et remonter rapidement le code produit 57 | * mesurer la qualité 58 | * construction du livrable 59 | * **Pair Programming** 60 | * partage de la connaissance métier et technique 61 | * plusieurs points de vue confrontés en permanence 62 | * chacun apprend des techniques et de l'expérience de l'autre 63 | * **Refactoring** : Revoir de manière continue la conception et la lisibilité du code en vue de son amélioration 64 | * **Code review** : par un équipier, par l'ensemble de l'équipe ou bien par un œil externe 65 | * permet de partager la connaissance avec toute l'équipe, et de faire émerger des critiques constructives afin de retravailler le code en conséquence 66 | * permet d'obtenir un retour (_feedback_) rapide 67 | * **Behavior Driven Development (BDD)** 68 | * L'art de rédiger de façon collaborative (métier + développeurs + testeurs) les spécifications d'une application 69 | * Les scénarios sont illustrés à l'aide de cas précis 70 | * Permet de favoriser la compréhension des fonctionnalités par tous 71 | * On utilise généralement le langage _Guerkin_ (exemple avec l'outil _Cucumber_) 72 | * **Domain Driven Design (DDD)** : L'ensemble du code doit être conçu, organisé et écrit, en vue de refléter le domaine pour lequel il existe 73 | 74 | ### Recevoir 75 | 76 | #### Formation 77 | 78 | * **Veille technologique** 79 | * participation à des événements 80 | * suivi de sites web, blogs, news 81 | * suivi des leaders d'influence de l'IT (Twitter, ...) 82 | * mise en oeuvre des _getting started_ 83 | * **Mentorat, tutorat** 84 | * accompagnement par des personnes expérimentées 85 | * partage des connaissances 86 | * **e-Learning, MOOC (Massive Open Online Courses)** 87 | * **Lecture d'ouvrages** 88 | 89 | #### Événements 90 | 91 | * Coding games, quizzes 92 | * Hackathon : challenge d'innovation proposant de développer un logiciel en équipe, dans un délai imparti 93 | * [Coding Dojos](coding-dojos.md) (Kata, Randori) 94 | * Brown Bag Lunch 95 | * Meetups 96 | * Conférences (Devoxx, Mix-IT, Breizh Camp, DevFest, ...) 97 | 98 | ### Partager 99 | 100 | * Rédaction d'articles 101 | * Mentorat, tutorat 102 | * Proposer et animer des formations, des Kata ou Coding Dojo 103 | 104 | ## Ressources 105 | 106 | ### Liens 107 | 108 | * [Blog et Podcast Artisant développeur](http://artisandeveloppeur.fr/) 109 | * [Blog Octo](https://blog.octo.com/software-craftsmanship-une-culture-a-transmettre/) 110 | * [Blog Le Touilleur Express](http://www.touilleur-express.fr/2011/01/20/craftsmanship/) 111 | * [Le Software Craftsmanship, pour la professionnalisation du métier de développeur](http://www.arolla.fr/blog/2014/12/le-software-craftsmanship-pour-la-professionnalisation-du-metier-de-developpeur/) 112 | * [Être Craftsman, c'est un état d'esprit](https://www.novencia.com/craftsman-presentation/) 113 | * [Site d'Arnaud Lemaire / Lilobase](https://www.lilobase.me/) 114 | 115 | ### Vidéos 116 | 117 | * :fr: [BreizhCamp - Pascal Le Merrer - eXtreme Programming : LA méthode Agile ?](https://www.youtube.com/watch?v=ev1wsZrfO3M) 118 | * :fr: [BDX I/O 2018- Julien Carnelos - Crafters en 2018 : revisitez vos fondamentaux](https://www.youtube.com/watch?v=lVnZmoSeJ9I) 119 | * :fr: [BreizhCamp - Arnaud Lemaire - Entre industrialisation et artisanat, le métier de développeur](https://www.youtube.com/watch?v=itGmiTS_IPw) 120 | 121 | ### Livres 122 | 123 | * :gb: Uncle Bob - The Clean Coder 124 | * :gb: [Sandro Mancuso - The Software Craftsman](https://blog.cellenza.com/software-craftsmanship/analyse-the-software-craftsman-sandro-mancuso/) 125 | * :gb: [Andrew Hunt et David Thomas - The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) 126 | * :fr: [Software craft : TDD, Clean Code et autres pratiques essentielles](https://www.dunod.com/sciences-techniques/software-craft-tdd-clean-code-et-autres-pratiques-essentielles) 127 | 128 | --- 129 | :point_left: [Retour à l'accueil](../README.md) 130 | -------------------------------------------------------------------------------- /summury/octo-culture-change.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : OCTO - Culture Change - 2019 2 | 3 | :link: : _Le guide de remise en forme de votre organisation par l'agilité_ 4 | 5 | > Réussir sa transformation Agile, ce n'est pas avaler une pilule méthodologique, il s'agit d'apprendre, progressivement, un tout nouveau mode de vie..." 6 | 7 | > Le succès rencontré par les Méthodes Agiles auprès des équipes IT depuis plus de quinze ans a entériné l'impuissance de la gestion de projet “classique” face aux nouveaux défis technologiques. 8 | 9 | ## Introduction 10 | 11 | - Certains parlent de LA méthode Agile pour évoquer SCRUM. Tout le monde parle d'Agilité, mais plus personne ne peut être sûr d'y associer la même signification que son voisin. 12 | - l'Agilité c'est la capacité d'adaptation rapide à son environnement. 13 | - Viser l'Agilité à l'échelle c'est chercher une organisation capable de prendre des virages serrés en pleine course et ce sans partir en tête à queue. 14 | - _Think Big, Start Small, Learn Fast_ 15 | 16 | ## Chapitre 1 - Il était une fois, un leader qui avait une intention 17 | 18 | - pour incarner cette transformation, le top management doit souvent se transformer lui-même, dans ses valeurs et dans ses attitudes 19 | - Autoriser et faire autoriser à tester, expérimenter, échouer, donner du temps pour cela. 20 | - la capacité de transformation d'une organisation est proportionnelle à la capacité d'évolution personnelle de son leader 21 | - C'est en se plaçant dans un modèle associé (changer avec équipes) et non dissocié (demander à ses équipes de changer) qu'un leader peut favoriser la transformation de son organisation. 22 | - Paradoxe: PArler d'autonomie et de responsabilité mais un pointage à l'heure près. 23 | - Paradoxe: Prôner l'excellence d'équipes multi-compétentes pour travailler de manière itérative et incrémentale mais externaliser l'essentiel des compétences techniques dans des centres de services. 24 | - Un chef de projet peut intégrer progressivement que son rôle n'est plus de faire du suivi individuel de l'avancement en point à point avec ses équipiers ni même d'animer ce nouveau stand-up meeting au quotidien, mais plutôt de poser et entretenir un nouveau cadre où les tâches à réaliser sont visibles et partagées et où l'autonomie, la responsabilité et l'auto-organisation de l'équipe permettent une meilleure collaboration. 25 | - Une transformation Agile, c'est aussi l'opportunité de sortir d'une situation inconfortable car devenue dénuée de sens, de passer d'un "simple" travail à un "véritable" emploi. 26 | - être le premier à suivre le mouvement est une forme sous-estimée de leadership. 27 | - _les hommes ne sont capables de soutenir leur intérêt pour un sujet particulier que pendant un temps limité_ 28 | - Chaque transformation Agile est différente et, au sein d'une même organisation, différentes entités feront émerger différentes formes d'Agilité. 29 | 30 | ## Chapitre 2 - Expérimenter pour apprendre 31 | 32 | - Conduire une transformation Agile, c'est mettre en place une approche basée sur l'expérimentation et l'apprentissage continus...sans trop compter sur des solutions toutes faites. 33 | - Notre organisation actuelle en silos ne nous permettra jamais d'être Agile, elle génère beaucoup trop de dépendances. 34 | - L'Agilité est incompatible avec un management de type "Command & Control". Aller vers l'Agilité c'est demander aux managers opérationnels de changer de métier, de rôle et de savoir faire. 35 | - Les silos d'expertises créés dans un souci de rationalisation ont le désavantage d'augmenter les dépendances et donc de limiter l'Agilité des sujets transverses à forte valeur ajoutée. Au contraire former des équipes pluridisciplinaires permet d'améliorer l'autonomie de ces équipes à traiter un sujet de bout en bout, gagnant ainsi en rapidité. 36 | - Dans l'organisation pendant que certains expérimentent de nouvelles pratiques et attirent les projecteurs, d'autres restent dans l'ombre par choix ou par contrainte. 37 | - Le leadership = la capacité de donner envie aux individus de progresser. 38 | - Il est impossible de demander aux managers de tenir un nouveau cadre Agile qu'ils ne maîtrisent pas, voire qu'ils ne comprennent pas. 39 | - Leader porteur de sens, mentor, et coach du système sont les trois postures et compétences clés à développer pour manager efficacement dans les nouvelles organisations collaboratives et Agiles. 40 | - Le coach Agile ou le scrum master cherche à se rendre dispensable. Cela peut tout à fait s'appliquer à un manager d'équipe. 41 | 42 | ## Chapitre 3 - Passer à l’échelle 43 | 44 | - La résilience de l'équipe n'est pas portée par le leader technique. Un développeur est un leader technique potentiel. 45 | - Il n'y a pas de solution parfaite; quand vous optimisez dans un sens grâce à un type de découpage, vous dégradez autre chose. 46 | - Le temps de prise de décision est à peu près multiplié par trois à chaque fois qu'on remonte d'un niveau dans la hiérarchie. 47 | - Clarifier les niveaux de délégation permet de réduire le volume d'information qui circule et de prendre davantage de décisions au niveau où l'information est générée. 48 | - C'est en se concentrant sur la direction et le cadre des décisions, plutôt que sur les décisions elles-mêmes, que l'on peut à la fois les accélérer et les améliorer. 49 | - Les affaires courantes (court terme) peuvent être décentralisées à un niveau bas. 50 | - Les personnes douées pour innover ne sont pas toujours les mêmes que celles qui excellent sur les projets ou la maintenant.qui 51 | - Si un élément est trop long, il es t à découper ene plus petits incréments de valeur qui tiennent dans cet horizon de temps. 52 | - Dans la pratique, tout budget non consommé sera coupé l'année suivante et chacun a donc intérêt à consommer tout son budget alloué, quitte à financer des projets ou des fonctionnalités inutiles. 53 | - Les variations trop importantes ou trop rapides des effectifs déstabilisent bien davantage que les variations sur les projets à traiter. 54 | - Une équipe est un groupe stable de personnes qui collaborent pour atteindre un objectif commun. 55 | - La meilleure façon d'attendre un objectif important pour l'entreprise est d'y dédier des collaborateurs. 56 | - Accepter de mettre en attente son besoin pour favoriser les livraisons fréquentes esr simple à comprendre mais difficile à appliquer. 57 | - Le mode distribué est jugé moins efficace car il génère de la perte d'informations et élargit peu le bassin de compétences. Il a aussi tendance à créer des clans au seins des équipes. 58 | - Dans le développement logiciel, cela nécessite que les standards de code soient clairs et partagés. 59 | - En pratique, le principe de porosité permet d'alléger l'impact d'une dépendance forte entre 2 équipes. 60 | - Il est indispensable de considérer les objectifs individuels et vérifier qu'ils ne sont pas antinomiques avec les objectifs du passage à l'échelle. 61 | - L'Agile repose sur le paradigme que nous ne pouvons pas tout prévoir et qu'il est plus efficace de s'adapter. 62 | - Si les personnes veulent juste changer de pratiques sans toucher aux principes, il est fortement probable que la transformation échoue. 63 | - Il est crucial d'inclure tôt les équipes RH pour qu'elles soient, elles aussi, acculturées à de nouvelles méthodes de travail et qu'elles comprennent ce qui va changer. 64 | - Pour "cloner" ces expertises, il faut passer par de la considération pour les sachants, du mentoring, des décisions d'investissement pour contrer la tendance à la perte de contrôle du savoir. 65 | - Plus les DRH seront éloignées du terrain, moins elles seront capables de répondre aux besoins. 66 | 67 | ## Chapitre 4 - Pérenniser : pour une transformation durable 68 | 69 | - La ligne d'arrivée n'existe que pour l'organisation parfaite. 70 | - Etre Agile c'est aussi toujours s'autoriser à faire différemment pour faire mieux. 71 | 72 | ## Chapitre 5 - Et après ? Appréhender le futur 73 | 74 | - L'Agilité ne pourra donc par définition, jamais se figer dans une méthode ou un framework définis, statiques. 75 | 76 | --- 77 | :point_left: [Retour à l'accueil](../README.md) 78 | -------------------------------------------------------------------------------- /summury/octo-culture-flow.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : OCTO - Culture Flow - 2021 2 | 3 | :link: : _Un nouveau rythme pour les organisations agiles_ 4 | 5 | ## Préface 6 | 7 | Pour aller plus vite, engagez moins de chantiers en parallèle, vous aurez une meilleure concentration et très probablement une meilleure qualité. 8 | 9 | ## Chapitre 1 - Les principes à adopter tels quels 10 | 11 | ### Toute décision est prise en réponse à un évènement et non à une date planifiée 12 | 13 | P17 : en décidant par exemple de ne pas mettre tous les risques dans le même panier (business, technique, produit, humain) 14 | 15 | P20 : l'ajout de nouvelles personnes dans une équipe a généralement un impact négatif à court terme 16 | 17 | ### Chaque équipe connaît son flux de travail 18 | 19 | P26 : Nous sommes surpris car nous ne voyons pas tout de suite les conséquences de nos actes. 20 | 21 | P26 : Nous sommes surpris par ce qui dépasse notre limite de compréhension. 22 | 23 | P26 : Nous sommes surpris quand la réalité ne correspond pas à notre schéma de pensée. 24 | 25 | ### Une livraison de logiciel est un non-évènement qui peut intervenir n'importe quand 26 | 27 | P32 : il est nécessaire qu'à tout moment il soit dans un état stable, c'est à dire, livrable. 28 | 29 | P32 : Cela suppose d'automatiser les processus de qualification de l'état et au premier chef les tests dits "de qualification". 30 | 31 | P32 : ce qui suppose d'automatiser les processus de packaging et de déploiement du logiciel. 32 | 33 | P34 : les organisations les plus rapides sont aussi les plus stables 34 | 35 | P36 : Comme chaque modification de code concerne un périmètre restreint, la localisation de la correction sera plus rapide et plus simple. 36 | 37 | P38 : (trunk based development) : Lorsque les développeurs effectuent toutes leurs opérations directement sur le trunk plusieurs fois par jour, la base de code se doit d'être livrable à tout moment. Il en résulte une responsabilisation plus forte des développeurs. 38 | 39 | P41 : (BDD) : A l'arrivée, ce qui part en production, c'est la compréhension de celui qui le code. 40 | 41 | P42 : BDD, TDD, Trunk-Based, CI-CD = facilité à répéter des étapes de production de valeur sans effort et sans risque. 42 | 43 | ### Pour résoudre un problème il faut d'abord le rendre visible 44 | 45 | P44 : il est préférable de rendre les problèmes visibles pour générer des discussions et prendre des décisions. 46 | 47 | P45 : **lorsque vous traitez des choses sans les rendre visibles vous dissimulez malgré vous le problème au reste de votre écosystème** 48 | 49 | P45 : observabilité : Livrer en continu implique d'avoir mis en place une boucle de rétroaction efficace pour savoir si les changements déployés régulièrement améliorent ou aggravent la stabilité du système dans sa globalité. Surveiller en continu son infrastructure et ses applications permet de détecter et d'être averti instantanément de tout problème survenu sur une plateforme. 50 | 51 | P46 : L'observabilité peut se définir comme "_la capacité d'un système à être appréhendé par un humain afin qu'il puisse le comprendre, le modifier et le corriger_". 52 | 53 | ### Tout le monde connaît le lien entre sa production et la stratégie de l’organisation 54 | 55 | P54 : Ce qui a une valeur économique aujourd'hui, ce n’est plus tant le savoir que la capacité à le mettre en œuvre, le contextualiser à un écosystème et se l’approprier. 56 | 57 | ## Chapitre 2 - Les principes à adapter au contexte 58 | 59 | ### Tout changement pérenne est une modification des habitudes 60 | 61 | P66 : la capacité de s'exprimer et de prendre des risques sans crainte est un élément clé. 62 | 63 | P68 : _Pair Programming_ : Le grand bénéfice n'est pas la productivité mais le partage de savoir-faire entre les développeurs.Cette pratique est très intéressante lors de l'arrivée d'une nouvelle personne dans l'équipe. 64 | 65 | P69 : la revue de code : L'efficacité de la revue de code sur le partage est cependant moindre car les développeurs relisant le code n'ont pas participé aux différentes réflexions ayant amené au résultat produit. 66 | 67 | P70 : _Mob Programming_ : Le Mob Programming est l’un des moyens les plus efficaces, sinon LE moyen le plus efficace, pour : 68 | 69 | - Faire émerger des standards dans une équipe qui vient d’être formée, 70 | - Réaligner les standards multiples et/ou implicites d’une équipe déjà formée, 71 | - Diffuser à l'équipe les connaissances acquises par un coéquipier qui reviendrait de formation 72 | - Expérimenter de nouvelles façons de travailler 73 | 74 | P70 : _Shifting Left On Security_ : Les experts sécurité, en général peu nombreux dans les organisations, sont souvent sollicités et inclus à la fin du cycle de vie du logiciel lorsqu'il est souvent pénible et coûteux d'effectuer les correctifs nécessaires. 75 | 76 | P70 : Dans cette logique de flux continu de livraison de fonctionnalités, la sécurité n'a plus sa place dans une phase aval, complètement déconnectée et réalisée par une autre équipe quand tous les développements sont finalisés 77 | 78 | P71 : **Il est plus simple de s'assurer que les personnes qui construisent le logiciel agissent et le font correctement que d'inspecter des systèmes et des fonctionnalités presque terminées.** 79 | 80 | P72 : Intégrer les nouveaux : l'importance de travailler sur la capacité d'une organisation à inclure de nouvelles personnes. 81 | 82 | P73 : Les modes colocalisé et éclaté sont ceux qui montrent les meilleurs résultats. Nous déconseillons donc tous les modes distribués. 83 | 84 | P74 : une organisation composée uniquement d’experts, c’est-à-dire de personnes qui ne maîtrisent qu’une seule activité, finira inévitablement par rencontrer des blocages forts. 85 | 86 | ### Les boucles de feedback 87 | 88 | P83 : il faut, dans le temps court comme dans le temps long, avoir toujours en ligne de mire les besoins, sans cesse renouvelés, de l’utilisateur final. 89 | 90 | P83 : un persona : une représentation symbolique de nos utilisateurs cibles. 91 | 92 | P83 : L’UX design (User Experience Design) a pour principe fondamental d’intégrer les utilisateurs le plus tôt possible dans le cycle de développement du produit, afin de concevoir le produit pour et avec eux. 93 | 94 | P84 : _Lean Startup_ : une méthodologie faite de boucles de feedback courtes pour apprendre au fur et à mesure 95 | 96 | P85 : C'est bien quand nous avons un besoin, et non juste un problème, que nous cherchons une solution que nous sommes prêts à payer. 97 | 98 | ### Les organisations techniques et humaines sont liées 99 | 100 | P91 : favoriser les couplages faibles, les modes d'interaction : 101 | 102 | - service : B réalise pour A 103 | - collaboration : A travaille avec B pour l'aider 104 | - facilitation = _inner source_ : A modifie directement dans la base de code de B, B fait la revue 105 | 106 | P92 : Le mode facilitation est celui qui permet d’aller le plus vite en diminuant les frottements et permet aussi d'abaisser la probabilité de duplication de fonctionnalités dans deux applications (nous ne pouvons pas attendre, donc nous redéveloppons chez nous). 107 | 108 | P97 : architecture applicative : Bien ranger sa chambre, c’est éviter toutes les superpositions techniques qui créent du lien 109 | 110 | P97 : **sortir des architectures à découpage technique pour s'abstraire des 111 | systèmes externes (base de données, système de fichiers, serveur de mail...) et que le code métier ne soit plus noyé au milieu du code technique (frameworks, librairies).** 112 | 113 | P97 : **La valeur d'une application réside dans ses cas d'utilisation et ses services métiers.** la logique métier ne doit pas se retrouver dispersée dans plusieurs couches. le modèle métier d'une application (les objets métiers manipulés) n'évolue pas au même rythme que le modèle de stockage ou encore le modèle de présentation. 114 | 115 | P97 : Ce type d'architecture applicative prône un couplage faible en supprimant les adhérences aux composants d'infrastructure: il en résulte 116 | une meilleure testabilité, orientée sur le comportement métier. 117 | 118 | P97 : Par ricochet, en isolant et en protégeant la valeur métier des éléments techniques connexes, il est possible de faire des mises à jour de dépendances techniques beaucoup plus régulièrement et plus facilement, sans crainte de régressions. 119 | 120 | P98 : Clean Architecture / Hexagonale Architecture : 121 | 122 | - Une isolation et une protection du code métier, 123 | - Une totale indépendance vis-à-vis des frameworks avec un métier clair et explicite, 124 | - Une séparation claire des problèmes, 125 | - Une meilleure testabilité orientée sur le comportement métier. 126 | 127 | P100 : Archi hexagonale : l'important est de co-localiser le code métier et de sortir des architectures à découpage technique. 128 | 129 | ### Les écosystèmes sont organisés en minimisant les frictions vis-à-vis de la stratégie 130 | 131 | P103 : **il n'y a rien de plus stable dans le temps que les domaines métiers.** 132 | 133 | P104 : aligner par couches techniques : elle n'est orientée ni valeur, ni client, ni métier. Il manque une vision d'ensemble. 134 | 135 | P105 : modèles : il vaut mieux les conserver sous forme d’exception plutôt que de les faire rentrer au chausse-pied. **C’est l’exemple de l’équipe appelée Transverse qui regroupe toutes les personnes que nous n’avons pas su placer.** 136 | 137 | P106 : l'architecture en continue : Les architectes se doivent donc d'être présents au moment de la mise en œuvre et aux côtés des équipes de réalisation quand les difficultés se présentent. 138 | 139 | P107 : Nous prenons les décisions d’architecture au moment où nous devons les prendre, pas après mais pas avant non plus. 140 | 141 | --- 142 | :point_left: [Retour à l'accueil](../README.md) 143 | -------------------------------------------------------------------------------- /appendices/code-review.md: -------------------------------------------------------------------------------- 1 | # Les revues de code 2 | 3 | ## A- Les avantages des revues de code 4 | 5 | :pushpin: _La pratique de la revue de code a un coût mais qui est largement amorti plus tard. C'est un investissement rentable et une pratique essentielle à la bonne qualité et à la durabilité du produit développé._ 6 | 7 | ### L'équipe : renforcer la propriété collective 8 | 9 | * Le code _n'appartient_ plus qu'à une personne et est maintenable par plusieurs développeurs. 10 | * Implication de tous les développeurs. 11 | * Partager / transmettre la connaissance du sujet. 12 | * Facilite l'apprentissage (nouveau dans l'équipe, nouveau sur la technologie, etc ...). 13 | * Renforce la cohérence et la cohésion (de l'équipe et du code). 14 | 15 | ### Le produit : assurer une meilleure qualité et moins de bugs 16 | 17 | * Détection des défauts au plus tôt (et donc à moindre coût). 18 | * Apporter un regard nouveau, critique. 19 | * Provoquer des échanges, des débats, des analyses (émulation dans l'équipe). 20 | * Éviter la dégradation progressive du code. 21 | 22 | ## B- Les types de revues 23 | 24 | :pushpin: _Différents types de revues peuvent être utilisés._ 25 | 26 | * Le binômage (_pair-programming_) : _feed-back_ immédiat. 27 | * Les _Merge Requests_ ou _Pull Requests_. 28 | * Les revues par un pair. 29 | * Les revues collectives. 30 | 31 | :bulb: Ces techniques peuvent (doivent) être complémentaires. 32 | 33 | ## C- Les clefs pour réussir les revues de code 34 | 35 | :pushpin: _Les revues de code se préparent et doivent respecter quelques pré-requis pour être réellement efficaces. De plus comme toute technique c'est en la pratiquant régulièrement qu'on l'optimise et que l'on s'améliore individuellement et collectivement._ 36 | 37 | ### Le relecteur : être bienveillant 38 | 39 | * Critiquer le code, pas le développeur (dissocier le code de la personne). 40 | * Employer "je" ou "on" et pas "tu". 41 | * Valoriser les bons points constatés (montrer les points positifs). 42 | 43 | ### Le relecteur : apporter des critiques constructives 44 | 45 | * Critiquer le fond, pas la forme (pour çà il y a des outils pour automatiser). Attention, la forme n'inclue pas le respect des normes, la lisibilité ou la maintenabilité. 46 | * Être le plus clair, précis et explicite possible (pas d'ironie, d'ambiguïté). 47 | * N'apporter que des commentaires constructifs en proposant des solutions ou des alternatives. 48 | * Ne pas aller trop vite, il faut prendre le temps d'analyser, utiliser une _checklist_ par exemple. 49 | * Ne pas penser que l'on n'est pas forcément légitime, chaque point de vue est bon à prendre et à considérer. 50 | * Favoriser également, en plus des commentaires, les échanges de vive voix. 51 | 52 | ### Le relu : préparer la revue 53 | 54 | Pour faire gagner du temps au relecteur et pour l'orienter : 55 | 56 | * Revoir son code avant de soumettre : 57 | * respect des normes internes 58 | * respect du style (indentation, nommage, ...) 59 | * respect des principes SOLID 60 | * pas de violations Sonarqube 61 | * code lisible et compréhensible 62 | * présence de tests...utiles 63 | * Commenter les choix techniques. 64 | * Pointer (et éventuellement décrire) les éléments fondamentaux devant être validés ou partagés 65 | * expliquer **quoi** et **pourquoi** 66 | * ... et pas obligatoirement le **comment** 67 | 68 | ### Le relu : être reconnaissant 69 | 70 | * Ne pas prendre les remarques pour soi. 71 | * Considérer les remarques comme des moyens d'amélioration continue, d'apprentissage. 72 | * Se rappeler que la personne qui a commenté le code a pris de son temps dans le but d'améliorer le produit développé. 73 | * Répondre à TOUS les commentaires. 74 | * Expliquer ses choix d'implémentation "à priori" pour orienter le relecteur. 75 | * Ne soumettre à la revue que du code finalisé et fonctionnel ... mais pas forcément complet (ne pas forcément attendre la fin du développement de la fonctionnalité). 76 | 77 | ### L'équipe : avoir un soutien fort de son management 78 | 79 | * Le management doit être convaincu des apports et bénéfices des revues, il doit soutenir et encourager cette pratique. 80 | * Le management ne doit pas intervenir ou participer aux revues, c'est uniquement réservé aux sachants _techniques_. 81 | * Le management ne doit pas utiliser les revues à des fins de _reporting_ ou de contrôle (rappel : on ne s'occupe que du code pas des personnes). 82 | 83 | ### L'équipe : impliquer tout le monde 84 | 85 | * Initier la pratique dès le début du projet, ne pas attendre. 86 | * Rendre les revues systématiques (présente dans les _Definition of Done_ / votre _WorkFlow_ / votre processus de développement) 87 | * Ne pas corriger / modifier à la place du développeur initial (c'est l'auteur qui corrige les défauts relevés, via _pair-programming_ si besoin, permet de le responsabiliser). 88 | * Il faut éviter que cela soit toujours les mêmes personnes qui effectuent les revues (par exemple les _tech lead_ ou les plus expérimentés). 89 | * S'alerter si régulièrement les revues débouchent sur la détection d'aucun défaut : manque d'implication ? de temps ? de confiance ? 90 | 91 | ## D- Les clefs pour optimiser les revues 92 | 93 | ### Qui 94 | 95 | Les Tech Lead mais aussi tous les développeurs. Un Tech Lead doit revoir le code d'un développeur mais l'inverse est également vrai. 96 | 97 | L'aspect partage des connaissances (appropriation collective) et des techniques (montée en compétences en maturité) est un apport majeur de la pratique des revues de code. 98 | 99 | ### Limiter le périmètre et le champ d'action 100 | 101 | * La revue ne doit pas se substituer aux contrôles outillés. On se concentre alors uniquement sur les vérifications qui nécessitent une intervention humaine que l'on pourrait difficilement automatiser. 102 | * Pour les revues collectives limiter la durée et désigner un modérateur et un gardien du temps. 103 | * Limiter la taille des _Merge Requests_ ou _Pull Requests_ ou du code à revoir : trop de code à revoir = risque de louper des choses (découragement, passer trop vite, ...). Petite revue = meilleure efficacité, plus de pertinence. 104 | * Limiter le périmètre : une _Merge Request_ ou _Pull Request_ pour une seule fonctionnalité. 105 | * Les standards / normes / ... doivent être partagés, **validés**, accessibles et connus de tous et maintenus par tous. Ce qui permet : 106 | * d'éviter de se répéter et donc gagner du temps (de revue et de développement). 107 | * d'éviter les conflits. 108 | * Consacrer les revues à la détection des défauts, pas à leur correction ni à la génération de débats, qui doivent avoir lieu séparément. 109 | 110 | ### Contrôler / outiller 111 | 112 | * Faire un suivi des défauts constatés pour éviter de les retrouver de revue en revue. 113 | * S'appuyer également sur les rapports des revues outillées (couverture, résultats des tests, ...). 114 | 115 | ### Combiner les techniques 116 | 117 | * Binômage : retour immédiat. 118 | * Tests automatisés, TDD, ... 119 | * Inspection continue avec des outils comme _Sonarqube_. 120 | * Revue collectives : partage de la connaissance. 121 | * Revue par des pairs : regard nouveau. 122 | 123 | ## E- Les pistes à explorer lors de la revue 124 | 125 | * [ ] Le bon nommage (clair, explicite, approprié, ...). 126 | * [ ] Taille des classes et méthodes et nombres de paramètres. 127 | * [ ] Respect des principes SOLID et autres principes _clean code_. 128 | * [ ] Pas d'_Over Design_, _Over Engineering_ et respect du principe YAGNI. 129 | * [ ] Pas de redondance, de copier-coller. 130 | * [ ] Code au bon endroit, où on est sensé s'attendre à le trouver. 131 | * [ ] Présence et pertinence des tests. 132 | * [ ] Présence et pertinence des commentaires et de la Javadoc. 133 | * [ ] Un niveau et des traces de log adaptés et pertinents. 134 | * [ ] Gestion des erreurs et des exceptions. 135 | * [ ] Pas de `switch` ou de blocs `if-elseif ...` abusifs (souvent signe d'un mauvais _design_ où l'héritage et le polymorphisme devraient plutôt être utilisés). 136 | * [ ] Le paramétrage (tout ce qui peut changer : soit en fonction des besoins, soit en fonction des environnements) doit être externalisé. 137 | * [ ] Adaptation au domaine métier (vocabulaire, contexte borné, ...). 138 | * [ ] Les structures de données utilisées sont adaptées au besoin (Ex : pas de `LinkedList` pour des accès direct à un indice donné). 139 | 140 | ## F- Revue de code _versus_ Audit de code 141 | 142 | L'audit de code est généralement réalisé par une personne externe à l'équipe voir parfois externe à l'entreprise. 143 | 144 | De plus généralement ce type d'audit intervient souvent trop tard dans le cycle de vie du projet/produit ne permettant pas une remontée rapide et donc une prise en compte rapide des informations par les différents acteurs. 145 | 146 | Enfin l'auditeur ne dispose bien souvent que de très peu d'éléments historiques ou de contexte ou des contraintes liés au projet/produit/entreprise pour pouvoir juger des choix techniques ou méthodologiques rencontrés. L'avis exprimé est donc subjectif et basé sur l'expérience et l'avis personnel de l'auteur de la revue. 147 | 148 | Cette méthode peut être utilisée dans des cas spécifiques ou des compétences pourraient à manquer : 149 | 150 | * audit de sécurité 151 | * tests de performance 152 | * validation d'une solution ou d'un choix technique 153 | 154 | :bulb: Le classement par efficacité pourrait ressembler à : 155 | 156 | 1. Revue collective 157 | 1. Pair-Programming 158 | 1. Revue par un pair 159 | 1. Revue externe (audit) 160 | 161 | ... d'où l'intérêt de combiner les méthodes. 162 | 163 | ## G- Annexes 164 | 165 | * :fr: Vidéos : [Playlist Youtube](https://www.youtube.com/playlist?list=PLM5oYKLr93VlE4Oq7KrZUGHObWEWV1rRX) 166 | * :gb: Article : [How to Make Your Code Reviewer Fall in Love with You par _Michael Lynch_](https://mtlynch.io/code-review-love/) 167 | * :fr: Article : [La revue de code bienveillante par _Gilles Roustan_](https://gb-prod.fr/2016/12/01/la-revue-de-code-bienveillante.html) 168 | * :fr: Article : [Comment faire une bonne revue de code ? par _Mindsers Blog_](https://mindsers.blog/fr/post/conseils-bonne-revue-code/) 169 | * :fr: Article : [Tu peux valider ma pullrequest ? par _Julien Hatzig_](https://medium.com/just-tech-it-now/tu-peux-valider-ma-pullrequest-8a11b16f20e6) 170 | 171 | --- 172 | :point_left: [Retour à l'accueil](../README.md) 173 | -------------------------------------------------------------------------------- /appendices/tests.md: -------------------------------------------------------------------------------- 1 | # Les tests 2 | 3 | ## Règles fondamentales 4 | 5 | * :warning: **Tester le plus tôt, le plus possible et le plus souvent possible.** 6 | * :warning: **Les tests sont un pré-requis obligatoire au _refactoring_ car ils permettent de savoir si l’on a cassé ou non des fonctionnalités.** 7 | * :warning: **Le moindre échec dans les tests unitaires / d'intégration doit bloquer obligatoirement la construction de l’application.** 8 | * :warning: **Ce sont les tests unitaires qui permettent d'obtenir un code flexible, maintenable et réutilisable.** 9 | * :warning: **Aucune dépendance externe ne doit être sollicitée : base de données, serveur SMTP, accès réseau (HTTP, NAS, ...) ou bien encore de la date système par exemple.** 10 | * :warning: **S'interdire tout _refactoring_ ou tout déploiement en continu s'il n'y a pas de tests pour valider.** 11 | 12 | ## Pourquoi faire des tests 13 | 14 | Seuls les tests peuvent garantir : 15 | 16 | * un bon niveau de qualité. 17 | * un résultat conforme aux attentes. 18 | * la non régression (refactoring, nouvelle fonctionnalité). 19 | 20 | Les tests offrent également : 21 | 22 | * un retour rapide en cas de problème. 23 | * un aspect documentaire (c’est une documentation vivante et toujours à jour). 24 | * un gain de temps (pas besoin de redéployer entièrement l’application). 25 | * parfois une mise en évidence d'un mauvais design ou une remise en question. 26 | 27 | Extraits de la publication d'Octo _Culture DevOps Vol. 3 :_ 28 | 29 | * Écrire un test c’est faire un investissement en temps. 30 | * Coder consistant essentiellement à prendre une succession de décisions, il est impératif de travailler à avoir une boucle de feed-back la plus rapide possible. Personne ne peut décemment penser déployer en continu du code qui ne 31 | serait pas suffisamment testé. 32 | * Vous assurez également la production d’une documentation via votre code de test. Si l’on se demande quel résultat est censée produire telle ou telle partie, les tests en utilisant des cas et des valeurs concrètes, nous apporterons une réponse plus fiable qu’un document Word ou PDF obsolète. 33 | * Un pipeline qui n’exécute (presque) aucun test perd environ 99 % de son intérêt. **Il permet juste d’envoyer plus vite des bugs en production**. Pas de tests, pas de qualité. Pas de qualité, pas de confiance. Pas de confiance, pas de prod. 34 | * Plus un test est rapide (à développer et à exécuter), plus il sera exécuté souvent, plus il aura de la valeur. 35 | 36 | ## Comment faire des tests 37 | 38 | ### Typologie des tests 39 | 40 | **Pyramide des tests** : Tests unitaires -> Tests d'intégration / tests d'API -> Tests End to End (bout en bout) -> Tests de charge, tests de sécurité. 41 | 42 | Chaque type de test apporte son niveau de protection. 43 | 44 | ### Structure d'un test : Build-Operate-Check 45 | 46 | ... ou _Given-When-Then_ ... ou _Arrange-Act-Assert_ 47 | 48 | 1. _Build_ : Construire les données du test. 49 | 1. _Operate_ : Exploiter les données du test. 50 | 1. _Check_ : Vérifier que l'opération a produit les résultats escomptés. 51 | 52 | ### Caractéristiques F.I.R.S.T. 53 | 54 | 1. **F**AST : (Rapide) : les tests doivent être rapides. Un test lent est un test qui risque de ne plus être exécuté. 55 | 1. **I**NDEPENDENT (Indépendant) : les tests ne doivent pas dépendre les uns des autres. Un test ne doit pas établir les conditions d'exécution du test suivant. Vous devez être en mesure d'exécuter chaque test indépendamment et dans l'ordre que vous voulez. 56 | 1. **R**EPEATABLE (Reproductible) : les tests doivent pouvoir être reproduits dans n'importe quel environnement. 57 | 1. **S**ELF-VALIDATING (Auto-validant) : les tests doivent avoir un résultat binaire : ils réussissent ou ils échouent. Vous ne devez pas avoir à consulter un fichier de journalisation ou comparer manuellement 2 fichiers. 58 | 1. **T**IMELY (au moment opportun) : les tests doivent être écrits au moment opportun : juste avant le code de production qui permet de les réussir (voir Test First ou TDD) ... ou **T**HOROUGH (approfondis/précis) : les tests doivent explorer l'essentiel des possibilités en utilisant des cas négatifs et positifs. 59 | 60 | ### Des tests de qualité 61 | 62 | * Le code de test est aussi important que le code de production. 63 | * La lisibilité est sans doute encore plus importante dans les tests unitaires qu'elle ne l'est dans le code de production. 64 | * Plus les tests sont négligés plus il est difficile de les modifier. 65 | * Plus le code de test est embrouillé plus le temps nécessaire à l'ajout de nouveaux tests dépassera celui nécessaire à écrire le nouveau code de production. 66 | * Le code doit être pensé et écrit de façon à ce qu’il soit naturellement et unitairement testable. 67 | * Chaque test doit se contenter de valider une et une seule fonctionnalité : un concept par test. 68 | * Chaque test doit avoir un nom clair sur le principe de `should_XXXXX_If_YYYYYYY`. 69 | 70 | ### Des tests qui testent 71 | 72 | * Un test qui ne peut pas échouer est un test qui ne sert à rien. 73 | * Sans les tests chaque modification est un bogue potentiel : les tests permettent le changement. Les systèmes non testables ne sont pas vérifiables. Un système non vérifiable ne doit jamais être déployé. 74 | * Rechercher chaque condition limite et écrivez le test correspondant. 75 | * Les tests restent insuffisants tant qu'il existe des conditions qui n'ont pas été explorées ou des calculs qui n'ont pas été validés. 76 | 77 | ## Test First & Test Driven Development 78 | 79 | Le principe du _développements pilotés par les tests est d'écrire les tests avant le code de production. Test-First est issu des pratiques de l'_eXtreme Programming_, TDD rajoute la notion d'itération et de remise en forme (_refactoring_ : Red->Green->Refactor). 80 | 81 | ### Les 3 lois du TDD 82 | 83 | 1. Vous ne devez pas écrire un code de production tant que vous n'avez pas écrit un test unitaire d'échec. 84 | 1. Vous devez uniquement écrire le test unitaire suffisant pour échouer : l'impossibilité de compiler est un échec. 85 | 1. Vous devez uniquement écrire le code de production suffisant pour réussir le test d'échec courant. 86 | 87 | ### Avantages du TDD 88 | 89 | * Réduction du nombre d'anomalies et des régressions. 90 | * Évite la sur-ingénierie. 91 | * C'est une bonne documentation associée au code et toujours à jour. 92 | * Implique de-facto une couverture du code à 100%. 93 | 94 | ## Dummy, Fake, Stub, Mock, Spy, bouchon, substitut, simulacre 95 | 96 | Dans tous les cas ce sont des objets (classes, implémentations, ...) qui ne sont jamais utilisés dans le code de production, des outils pour le code de test. Néanmoins on peut imaginer, en production, des _fallback_ (solution alternative, solution de repli) utilisant des bouchons. 97 | 98 | * **Dummy** : Variable ou méthode fantoche : 99 | * le contenu ou le comportement n'importe pas. 100 | * le contenu ou le comportement n'influe pas sur le résultat du test. 101 | * **Fake** : Faux-objets 102 | * Souvent des objets aux capacités limités. 103 | * Peut être un _stub_ ou _mock_. 104 | * **Stub** : ébauche 105 | * Permet de remplacer une dépendance existante et non primordiale pour le test. 106 | * Peut être configuré pour les besoins du test. 107 | * **_On ne fait aucune assertion sur ces objets_**. 108 | * Sont utilisés dans la partie _Given_. 109 | * **Mock** : Objet simulé (simulacre) 110 | * C'est un _stub_ sur lequel on va pouvoir faire des assertions. 111 | * Sont utilisés dans la partie _When_ et _Then_. 112 | * **Spy** : C'est également un substitut à une implémentation réelle 113 | 114 | :gb: [Martin Fowler - Mocks Aren't Stubs](https://www.martinfowler.com/articles/mocksArentStubs.html) 115 | 116 | :fr: [Benoît Sautel - Mock ou pas mock ?](https://www.fierdecoder.fr/2015/11/mock-ou-pas-mock/) 117 | 118 | :warning: Les définitions peuvent variées il est donc conseillé de définir et de s'accorder sur une définition commune au sein de l'équipe. 119 | 120 | ## Property Based Testing 121 | 122 | Contrairement aux tests basés sur les exemples, le _Property-based Testing_ a pour finalité de tester le comportement du code et non le résultat retourné par celui-ci. 123 | Un test de propriété testera une implémentation avec des valeurs constamment différentes (générées). 124 | 125 | Cette technique permet de compléter les tests unitaires, où d'en remplacer certains. 126 | 127 | Ressources vidéos : 128 | 129 | * :fr: [Devoxx 2021 - Property based testing : de la théorie à la pratique (Nicolas Dubien)](https://www.youtube.com/watch?v=oeaXWvTHyxc) - 30min 130 | * :fr: [Devoxx 2016 - Property-Based Testing, enfin pour tout le monde (Cyrille Martraire - Romeu MOURA)](https://www.youtube.com/watch?v=O-LWbSUaEQU) - 2h24 131 | * :fr: [AFUP Day 2020 - Du test à la preuve: introduction au Property Based Testing (Baptiste Langlade)](https://www.youtube.com/watch?v=uUxGngqsER0) - 22min 132 | 133 | ## La checklist de validation d'un bon test 134 | 135 | Un bon test doit se conformer aux 10 principes suivants : 136 | 137 | * [ ] Le test possède un nom évocateur (ou une description via par exemple `@DisplayName` pour JUnit). 138 | * [ ] Le test est écrit dans le format _Arange/Act/Assert_ (ou _Given/When/Then_) afin d'assurer sa lisibilité et sa maintenabilité. 139 | * [ ] Le test ne valide qu'une seule chose (mais il peut contenir plusieurs assertions). 140 | * [ ] Le test n'est pas un doublon d'un autre (teste la même chose), en d'autres termes il permet d'augmenter la couverture de code. 141 | * [ ] Le test est auto-portant, il n'a besoin d'aucune dépendance externe à son contexte (BDD, service REST, ...) et il ne valide pas inutilement de code externe supposé respecter le comportement qu'on attend de lui. 142 | * [ ] Le test respecte les **caractéristiques FIRST : FAST**, il est rapide à s'exécuter (ou à échouer). 143 | * [ ] Le test respecte les **caractéristiques FIRST : INDEPENDENT**, il ne dépend pas de l'exécution d'un autre test . 144 | * [ ] Le test respecte les **caractéristiques FIRST : REPEATABLE**, il doit pouvoir être exécuté plusieurs fois en retournant toujours le même résultat. 145 | * [ ] Le test respecte les **caractéristiques FIRST : SELF-VALIDATING**, il passe ou échoue de façon automatique, aucune action humaine ne doit être nécessaire pour le valider. 146 | * [ ] Le test respecte les **caractéristiques FIRST : THOROUGH**, il explore toutes les possibilités (ou il fait partie d'un ensemble permettant de traiter tous les cas possibles). 147 | 148 | ## Pour aller encore plus loin dans la pratique des tests 149 | 150 | * [PITest](http://pitest.org/), [Stryker Mutator](https://stryker-mutator.io/) : _Mutation Testing System._ 151 | * [Stan4j](http://stan4j.com/download/ide/) : _The dependency graph of packages or components should have no cycles._ 152 | * [ArchUnit](https://www.archunit.org/) : _Unit Test your Java Architecture._ 153 | * [jQAssistant](https://jqassistant.org/) : _Definition and validation of project specific rules on a structural level._ 154 | * [Infinitest](https://infinitest.github.io/) : _Each time you change the code Infinitest runs the relevant tests for you!_ 155 | 156 | --- 157 | :point_left: [Retour à l'accueil](../README.md) 158 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Vue d'ensemble des principes _Clean Code_ 2 | 3 | _Synthèse des notions de Clean Code de [**Robert C. MARTIN**](https://fr.slideshare.net/MarwenMhamdi/coder-proprement) et autres recommandations._ 4 | 5 | * [A- Principes S.O.L.I.D.](#a--principes-solid) 6 | * [B- Lois, règles et autres principes](#b--lois-règles-et-autres-principes) 7 | * [C- Bonnes pratiques](#c--bonnes-pratiques) 8 | * [D- Projets](#d--projets) 9 | * [E- Ressources](#e--ressources) 10 | * [F- Pour aller plus loin](#f--pour-aller-plus-loin) 11 | 12 | ## A- Principes S.O.L.I.D. 13 | 14 | ### SRP : _Single Responsibility Principle_ 15 | 16 | > Il ne doit exister qu'une et une seule raison de modifier une classe ou un module. 17 | 18 | :link: [SRP](solid/SRP.md) 19 | 20 | ### OCP : _Open-Closed Principle_ 21 | 22 | > Les classes doivent être ouvertes à l'extension mais fermées à la modification. 23 | 24 | :link: [OCP](solid/OCP.md) 25 | 26 | Dans un système idéal nous incorporons de nouvelles fonctionnalités en étendant le système, non en modifiant le code existant. 27 | 28 | ### LSP : _Liskov Substitution Principle_ 29 | 30 | > 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é. 31 | 32 | :link: [LSP](solid/LSP.md) 33 | 34 | ### ISP : _Interface Segregation Principle_ 35 | 36 | > Ne pas dépendre de fonctionnalités dont on n’a pas l’utilité. 37 | 38 | :link: [ISP](solid/ISP.md) 39 | 40 | Respecter ce principe permet de réduire efficacement le couplage des classes entre elles. 41 | 42 | ### DIP : _Dependency Inversion Principle_ 43 | 44 | > L'inversion de contrôle déplace les responsabilités secondaires depuis un objet vers d'autres objets qui sont dédiés à chaque responsabilité et respecte ainsi le principe de responsabilité unique. 45 | 46 | :link: [DIP](solid/DIP.md) 47 | 48 | ## B- Lois, règles et autres principes 49 | 50 | ### DRY : _Don't Repeat Yourself_ 51 | 52 | > Principe qui consiste à éviter la redondance de code au travers de l’ensemble d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière. 53 | 54 | :link: [DRY](rules/DRY.md) 55 | 56 | ### KISS : _Keep It Simple, Stupid_ 57 | 58 | > Principe dont la ligne directrice de conception qui préconise la simplicité dans la conception et que toute complexité non indispensable devrait être évitée dans toute la mesure du possible. 59 | 60 | :link: [KISS](rules/KISS.md) 61 | 62 | ### YAGNI : _You Ain't Gonna Need It_ 63 | 64 | > Ce principe indique de ne pas se baser sur d'hypothétiques évolutions futures pour faire les choix du présent. 65 | 66 | :link: [YAGNI](rules/YAGNI.md) 67 | 68 | ### Principe _Fail-Fast_ 69 | 70 | > Un système "Fail-Fast" a pour propriété de signaler le plus rapidement possible une erreur : s'il faut échouer, autant le faire le plus vite possible. 71 | 72 | :link: 73 | 74 | Avantages : 75 | 76 | * Erreur d'origine non masquée ou perdue au milieu d'autres et permet la mise en évidence du responsable. 77 | * Facilite l'analyse du problème. 78 | * Évite les effets de bord et les problèmes d'incohérence. 79 | 80 | ### Principe de moindre surprise 81 | 82 | > Toute fonction ou classe doit implémenter les comportements auxquels un autre programmeur peut raisonnablement s'attendre. 83 | 84 | :link: 85 | 86 | Exemples : 87 | 88 | * Le code doit être placé là où le lecteur s'attend naturellement à la trouver. 89 | * Les noms des fonctions doivent indiquer leur rôle, s'il faut examiner la documentation ou l'implémentation de la fonction pour connaître son rôle cela signifie qu'un meilleur nom doit être trouvé ou que la fonctionnalité doit être déplacée dans des fonctions ayant des noms appropriés. 90 | 91 | ### Loi de "LeBlanc" 92 | 93 | > Plus tard signifie jamais. 94 | 95 | Exemples : 96 | 97 | * Commenter ou ignorer un test qui échoue et se dire que l'on fera en sorte qu'il réussisse plus tard. 98 | * Remettre à plus tard l'écriture d'un test. 99 | * Remettre à plus tard l'écriture de la documentation. 100 | 101 | ### Loi de "Déméter" 102 | 103 | > Un module ne doit pas connaître les détails internes des objets qu'il manipule. 104 | 105 | :link: [demeter](rules/demeter.md) 106 | 107 | ### Règle du Boy-Scout 108 | 109 | > Laisser le code plus propre qu'on ne l'a trouvé. 110 | 111 | Exemples : 112 | 113 | * Refactoring complet. 114 | * Renommage simple d'une variable peu explicite. 115 | * Amélioration d'un commentaire. 116 | * Suppression d'un code mort ou commenté. 117 | * ... 118 | 119 | ### Principe du couplage faible 120 | 121 | > On parle de couplage faible, couplage léger ou couplage lâche si les composants échangent peu d'information. 122 | 123 | Lorsqu'un système est suffisamment découplé il est également plus souple et favorise la réutilisation. L'absence de couplage signifie que les éléments du système sont mieux isolés les uns des autres et du changement. 124 | 125 | En réduisant le couplage nos classes adhèrent à un autre principe de conception appelé principe d'inversion des dépendances (_Dependency Inversion Principle_). 126 | 127 | Un couplage artificiel correspond souvent à un couplage entre deux modules qui n'ont aucun rapport direct. Il résulte du placement d'une variable, d'une constante ou d'une fonction dans un endroit commode sur le moment, mais finalement inadapté. 128 | 129 | ### Principe de séparation des préoccupations (_Separation Of Concerns_) 130 | 131 | > Des éléments n'ayant aucune relation conceptuelle dans un système n'ont pas à être modifiés en même temps. 132 | 133 | > Les systèmes logiciels doivent séparer le processus de démarrage, lorsque les objets de l'application sont construits et les dépendances sont établies, de la logique d'exécution qui vient ensuite. 134 | 135 | :link: [SOC](rules/SOC.md) 136 | 137 | ### Principe de forte cohésion 138 | 139 | > Les classes doivent contenir un nombre réduit de variables d'instance. Lorsque chaque variable d'une classe est employée par chacune de ses méthodes la cohésion est maximale. 140 | 141 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Coh%C3%A9sion_(informatique)) 142 | 143 | :thumbsup: Une classe fortement cohésive a un nombre de méthodes relativement limitées, fortement liées d'un point de vue fonctionnel. 144 | 145 | :thumbsdown: Une classe faiblement cohésive a un grand nombre de responsabilités dans différents domaines fonctionnels (voir aussi SRP). 146 | 147 | ### Principe d'accès uniforme (_Uniform Access Principle_) 148 | 149 | > Tous les services offerts par un module doivent être disponibles via une notation uniforme, ce qui ne permet pas de savoir s'ils sont implémentés via le stockage ou par le calcul. 150 | 151 | Ce principe édicté par _Bertrand Meyer_ dans son livre _Object-Oriented Software Construction_ nous indique que le client ou l'utilisateur d'un service n'a pas à savoir ou à se préoccuper si un élément qu'il récupère via ce service est un élément calculé ou stocké. 152 | 153 | :bulb: Dans les cas particuliers où les calculs pourraient être coûteux il convient bien sûr d'en avertir les clients ou d'implémenter un mécanisme de cache. 154 | 155 | ### Théorie de la fenêtre cassée (_Broken Window_) 156 | 157 | :link: [Wikipédia](https://fr.wikipedia.org/wiki/Hypoth%C3%A8se_de_la_vitre_bris%C3%A9e) 158 | 159 | C'est une analogie avec les détériorations que l'on constate dans l'espace public. Il ne faut jamais laisser la moindre petite faille ou petite brèche dans le code. Il faut corriger immédiatement sous peine d'entraîner des dégradations progressives jusqu'à atteindre à terme un délabrement général. 160 | 161 | ### Principe d'orthogonalité 162 | 163 | > 2 choses sont considérées comme orthogonales si un changement réalisé dans l'une n'affecte pas l'autre. 164 | 165 | ## C- Bonnes pratiques 166 | 167 | ### Processus continu 168 | 169 | C'est un processus continu d'améliorations (aussi petites soient-elles, cf règle du Boy Scout). On procédera par petites étapes, petits-pas (_Baby Step_). 170 | 171 | ### Rangement vertical 172 | 173 | * Une fonction appelée doit se trouver en dessous d'une fonction qui l'appelle. 174 | * Les variables et les fonctions doivent être définies au plus près de leur utilisation. 175 | 176 | :link: [Step-down rule](rules/step-down.md) 177 | 178 | ### Style de formatage 179 | 180 | Les développeurs de l'équipe doivent se mettre d'accord sur un même style de formatage et le respecter. Idéalement il est documenté et cette documentation facilement accessible. Par exemple : fichier `README.md` à la racine du dépôt GIT. 181 | 182 | ### Nommage 183 | 184 | * Choisir des noms descriptifs : les noms représentent 90% de la lisibilité du code. Les noms doivent révéler les intentions. 185 | * Les noms bien choisis doivent indiquer de manière non ambiguë le rôle d'une fonction ou d'une variable. 186 | * Les noms bien choisis ont le pouvoir d'ajouter une description à la structure du code. 187 | * Les noms doivent décrire les effets secondaires. 188 | * Les noms sont plus faciles à comprendre lorsqu'ils se fondent sur une convention ou un usage établi. Par exemple un _Design Pattern_. 189 | * La longueur d'un nom doit être liée à sa portée. Les variables et les fonctions dont les noms sont courts perdent leur signification avec l'éloignement. Par conséquent plus la portée d'un nom est étendue plus ce nom doit être long et précis. 190 | * Éviter la codification ou notification hongroise (utilisation de préfixes par exemple). 191 | * Choisir un mot par concept : établir un lexique et s’y tenir pour conserver une cohérence sur l'ensemble de application. 192 | * Éviter de mélanger différentes langues dans le même nom de classe, méthode ou variable. Exemples : readFichier, countLignes. 193 | 194 | ### Commentaires 195 | 196 | _Les commentaires doivent expliquer des choses que le code est incapable d'exprimer par lui-même._ 197 | 198 | _Si vous envisagez d'ajouter un commentaire, prenez le temps de vous assurer qu'il s'agit du **meilleur** commentaire que vous pouvez écrire._ 199 | 200 | _Les commentaires mentent, vieillissent très mal, ne sont pas refactorables, ... : ce sont des aveux de faiblesses, à utiliser un bon nom correct, à faire un découpage, etc ..._ 201 | 202 | Les commentaires suivants ne devraient pas exister : 203 | 204 | * commentaire contenant des métadonnées : date dernière modification, ... 205 | * historique des modifications 206 | * ancien code 207 | * commentaire trivial ou redondant 208 | * commentaire faux ou obsolète 209 | * commentaire mal placé (déplacement avec le temps et donc n'ayant plus aucun sens la où il se trouve) 210 | 211 | ### Documentation 212 | 213 | La documentation doit vivre avec le produit. La première documentation, et de fait toujours à jour, est les tests. 214 | 215 | ### Conception 216 | 217 | * Il ne doit pas y avoir plus d'une instruction `switch` pour un type donné de sélection. Les cas de cette instruction `switch` doivent créer des objets polymorphes qui prennent la place d'autres instructions `switch` dans le reste du système. 218 | * Il est contre-indiqué d'employer directement des nombres (ou chaînes) dans le code. Ils doivent être cachés derrière des constantes aux noms parfaitement évocateurs. Voir notion de [**magic number**](https://fr.wikipedia.org/wiki/Nombre_magique_(programmation)). 219 | * Extrayez des fonctions qui expliquent les intentions d'une expression conditionnelle. 220 | * Les expressions conditionnelles doivent être données sous une forme positive (plus facile à lire). 221 | * Interdire le couplage temporel : `fonc1` doit être appelée avant `fonc2` qui elle doit être appelée avant `fonc3` : les arguments de ces fonctions doivent être structurés de manière que leur ordre dans les appels soit évident. 222 | * _Big Design Up Front_. Pratique à éviter qui consiste à tout concevoir à l'avance avant d'implémenter quoi que ce soit : empêche de s'adapter aux changements en raison d'une résistance psychologique à la mise au rebut d'un travail antérieur et de la manière dont les choix architecturaux influencent les réflexions ultérieures sur la conception. 223 | 224 | ### Classes 225 | 226 | * Les classes de base ne doivent rien connaître de leurs classes dérivées. 227 | * En déployant séparément les classes dérivées et les classes de base nous pouvons déployer nos systèmes sous forme de composants autonomes et indépendants : réduction de l'impact d'une modification et de la maintenance. 228 | * Les classes ne doivent pas hériter des constantes (Interface regroupant des constantes). 229 | 230 | ### Fonctions / Méthodes 231 | 232 | * Le nombre d'arguments d'une fonction doit être aussi réduit que possible. 233 | * Les arguments de sortie (entrée-sortie) sont tout sauf intuitifs. Si la fonction doit modifier un état ce doit être celui de l'objet sur lequel elle est invoquée. 234 | * Les arguments booléens mettent clairement en évidence que la fonction fait plusieurs choses. Ils sont déroutants et doivent être éliminés. Solution : faire plusieurs méthodes nommées correctement. 235 | * Les méthodes qui ne sont jamais appelées doivent être retirées. La conservation du code mort coûte cher. 236 | * Pour qu'une fonction soit lisible l'une des solutions les plus performantes consiste à décomposer les calculs en valeurs intermédiaires représentées par des variables aux noms significatifs. 237 | 238 | ### Exceptions 239 | 240 | * Bien sur les fonctions ne doivent pas utiliser de codes retour, mais des exceptions typées en cas d'erreur. 241 | * Les exceptions doivent être traitées au niveau de la couche la plus haute. 242 | * Éviter de retourner `null`. 243 | * Log : on ne trace pas à la création de l'exception, ni en plein milieu du code. 244 | * Sécurité : ne pas afficher de contexte ou de stacktrace à un utilisateur final. 245 | 246 | ### Envelopper les API tierces 247 | 248 | Lorsque nous enveloppons une API tierce nous minimisons nos dépendances avec cette API : nous pouvons décider de changer de bibliothèque sans avoir à payer le prix fort. Par ailleurs, il est également plus facile de simuler les invocations d'une API ou d'un logiciel tiers lorsque nous testons notre propre code. 249 | 250 | ## D- Projets 251 | 252 | Les projets doivent pouvoir : 253 | 254 | * être extraits rapidement et simplement (ex: `git clone http://....`). 255 | * être construits rapidement et simplement (ex: `mvn clean install`). 256 | * être testés rapidement et simplement. 257 | 258 | ## E- Ressources 259 | 260 | * :fr: [Vidéos : Cours en ligne de José Paumard : _Principes SOLID et Design Patterns_](https://www.youtube.com/playlist?list=PLzzeuFUy_CngSfFq9-TJ0r8NC7Y3hSNpe) 261 | 262 | ## F- Pour aller plus loin 263 | 264 | * Zooms : 265 | * [Zoom sur le _Software Craftsmanship_](appendices/software-craftsmanship.md) 266 | * [Zoom sur la maintenabilité](appendices/maintenabilite.md) 267 | * [Zoom sur les notions de complexité](appendices/complexite.md) 268 | * [Zoom sur la notion de dette technique et de pourriture](appendices/dette-technique.md) 269 | * [Zoom sur l'inspection continue](appendices/continuous-inspection.md) 270 | * [Zoom sur les mauvaises pratiques](appendices/mauvaises-pratiques.md) 271 | * [Zoom sur les revues de code](appendices/code-review.md) 272 | * [Zoom sur les tests](appendices/tests.md) 273 | * [Zoom sur les _Coding Dojos_](appendices/coding-dojos.md) 274 | * [Zoom sur les _Architectural Decision Records_](appendices/ADR.md) 275 | * Fiches synthèses : 276 | * [OCTO - Culture Code](summury/octo-culture-code.md) 277 | * [OCTO - Culture DevOps vol. 1](summury/octo-culture-devops-1.md) 278 | * [OCTO - Culture DevOps vol. 2](summury/octo-culture-devops-2.md) 279 | * [OCTO - Culture DevOps vol. 3](summury/octo-culture-devops-3.md) 280 | * [OCTO - Culture Change](summury/octo-culture-change.md) 281 | * [OCTO - Culture Flow](summury/octo-culture-flow.md) 282 | * [Software Craft : TDD, Clean Code et autres pratiques essentielles](summury/software-craft-pratiques-essentielles.md) 283 | * HS : 284 | * [HS : Énumération de différentes lois et principes](off-topic/lois-et-principes.md) 285 | * [HS : Loi de Brooks - deuxième version logicielle](off-topic/brooks.md) 286 | * [HS : Les grandes règles du développeur](off-topic/regles-developpeur.md) 287 | -------------------------------------------------------------------------------- /summury/software-craft-pratiques-essentielles.md: -------------------------------------------------------------------------------- 1 | # Fiche synthèse : Software Craft : TDD, Clean Code et autres pratiques essentielles 2 | 3 | Livre - 288 pages - DUNOD - Cyrille MARTRAIRE, Arnaud THIEFAINE, Dorra BARTAGUIZ, Fabien HIEGEL, Houssam FAKIH 4 | 5 | ![couverture](https://www.dunod.com/sites/default/files/styles/principal_desktop/public/thumbnails/image/9782100825202-001-X.jpeg) 6 | 7 | :link: 8 | 9 | - [1- Les pratiques incontournables du craft](#partie-1--les-pratiques-incontournables-du-craft) 10 | - [2- Techniques avancées et élargissements](#partie-2--techniques-avanc%C3%A9es-et-%C3%A9largissements) 11 | - [3- Craft et attitudes](partie-3--craft-et-attitudes) 12 | 13 | ## Avant-propos 14 | 15 | Le _Software Craft_ est un ensemble d'attitudes qu'on apprend à adopter pour être plus efficace sur la façon d'utiliser les technologies, quelles qu'elles soient. Ce qui est remarquable avec les attitudes c'est qu'elles sont bien plus pérennes que les technologies sur lesquelles on les applique. 16 | 17 | Le vrai enjeu du développement logiciel est de rester évolutif dans la durée. 18 | 19 | En insistant sur l'excellence technique, le risque est de dériver vers l'élitisme, mais le _Software Craft_ inclut l'antidote qui est l'importance de la transmission des savoirs-faire. 20 | 21 | ## PARTIE 1 : Les pratiques incontournables du craft 22 | 23 | ### Le Développement Dirigé par les Tests (TDD) 24 | 25 | Le TDD n'est pas une technique de test mais bien une technique de développement et de conception. 26 | 27 | Nommage du test : lorsque la règle de gestion est exprimée avec précision, on peut facilement déterminer la cause de l'échec du test. (formalisme : Should XXX When YYYY). 28 | 29 | Écriture du test : il vaut mieux commencer par la vérification. 30 | 31 | Étape verte : c'est un peu difficile de se contraindre à écrire une seule ligne de code alors qu'on voit probablement d'avance l'implémentation finale. 32 | 33 | "Kata" : _de la répétition de la pratique naît la perfection_. 34 | 35 | Les tests deviennent notre harnais de sécurité contre les régressions qui peuvent venir se glisser dans le code par inadvertance. 36 | 37 | Le respect scrupuleux du TDD garantit une couverture totale. 38 | 39 | ### Techniques et principes de propreté de code (Clean Code) 40 | 41 | #### Être exemplaire 42 | 43 | Michael FEATHERS estime que la qualité majeure du code est de donner l'impression d'être écrit par quelqu'un qui fait attention à la qualité de son travail. 44 | 45 | L'être humain a une propension au laisser-aller face à un environnement dégradé, et qu'à l'inverse il éprouve des scrupules à ne pas respecter les règles dans un environnement sain. 46 | 47 | - théorie de la vitre brisée 48 | - règle du boy-scout 49 | 50 | Il faut appliquer un principe de tolérance zéro : dès qu'on se met à s'autoriser des négligences qu'on estime acceptables, on ouvre la porte à des négligences futures plus graves. 51 | 52 | Les tests sont la vitrine du code, et leur qualité se doit d'être exemplaire. 53 | 54 | #### Design 55 | 56 | D'une manière générale : 57 | 58 | - on doit chercher à guider les développeurs qui vont reprendre notre code après nous, à réduite leur charge mentale de façon qu'ils puissent se concentrer sur l'essentiel. 59 | - le code ne devrait pas paraître plus complexe que le problème métier qu'il cherche à résoudre. 60 | 61 | Les 4 règles simples pour un design simple : 62 | 63 | - passer les tests 64 | - révéler l'intention 65 | - éviter la duplication 66 | - rester petit 67 | 68 | Selon J.B. RAINSBERGER les règles essentielles du design simple ne seraient plus que 2 : 69 | 70 | - améliorer le nommage 71 | - réduire la duplication 72 | 73 | #### Nommage 74 | 75 | Il faut faire preuve d'un lâcher-prise dans la recherche de noms parfaits, en gardant à l'esprit qu'un nom n'a rien de définitif. 76 | 77 | Les 4 étapes de renommage préconisées par Kent BECK : 78 | 79 | - Nonsense (sans signification) 80 | - Accurate but vague (ciblé mais vague) 81 | - Precise (précis) 82 | - Intention revealing (révélant l'intention) 83 | 84 | Un nommage erroné ou approximatif peut induire en erreur et engendrer la création de bugs. 85 | 86 | #### Structuration 87 | 88 | Garder les niveaux d'abstraction en tête et les matérialiser aide à raisonner sur une quantité réduite de code, donc à moindre effort. 89 | 90 | Les fonctions : 91 | 92 | - Une fonction ne doit faire qu'une seule chose. 93 | - On devrait consider que tous les paramètres d'entrée sont immuables. 94 | - Les fonctions traitant le problème principal devraient se situer en tête du fichier source. 95 | - Aucune fonction ne devrait être définie plus haut qu'une fonction qui l'appelle. 96 | 97 | L'aspect visuel du code : 98 | 99 | - il est bien formaté. 100 | - le niveau maximum d'indentation est limité. 101 | - les lignes de code ne sont pas très larges. 102 | - il est normé (encodage, retour chariot, formatage, imports) 103 | 104 | #### Commentaires ... optionnels 105 | 106 | - considérer les commentaire avec méfiance. 107 | - il existe suffisamment de moyens d'exprimer l'intention par le code pour pouvoir se passer des commentaires. 108 | - les commentaires ne sont pas du code, ils souffrent de tous les travers inhérents de la documentation (décalage avec le réel, obsolescence). 109 | - le fait de ne s'autoriser que les commentaires réellement utiles donne à chacun d'entre eux une plus grande valeur. 110 | 111 | #### DRY 112 | 113 | - Nombre de développeurs adoptent un style de programmation par mimétisme. 114 | - Le démon du copier-coller est une addiction dont vous devez absolument vous débarrasser pour produire du code de bonne qualité. 115 | - Mais ... lorsque l'on assemble plusieurs morceaux de code en apparence semblables en une unique abstraction, on crée un couplage entre eux. 116 | - Plus le périmètre est restreint, et plus il est conseillé de réduire la duplication, parce que la portée du couplage introduit reste limitée. 117 | 118 | #### Conclusion 119 | 120 | L'écriture de code de qualité ne se fait pas en un seul jet, c'est un processus itératif par la pratique du refactoring. 121 | 122 | ### Les spécifications agiles avec le développement dirigé par le comportement (BDD) 123 | 124 | #### 3 amigos 125 | 126 | Co-construction : 127 | 128 | - La présence simultanée des 3 rôles permet d'optimiser les échanges dans une posture de co-construction d'égal à égal. 129 | - Il est important de rappeler qu'aucun rôle n'est subordonné à un autre. 130 | 131 | Il vaut mieux ne pas dépasser 4 (voire 5) afin d'éviter de compliquer les échanges. 132 | 133 | #### Gherkin : Given-When-Then, exécutable sous forme de tests automatisés 134 | 135 | - sous forme de critère d'acceptation en phase de développement initial 136 | - sous forme de tests de non-régression ultérieurement 137 | - compréhension partagée par tous 138 | - c'est une documentation vivante et à jour 139 | 140 | ### BDD 141 | 142 | BDD est une pratique qui ne nécessite pour démarrer que de rassembler des personnes de bonne volonté dans un atelier de spécifications. 143 | 144 | ### Collaborer efficacement avec le pair & mob programming 145 | 146 | Adopter une attitude de partage et de don de ses connaissances est important, parce que par mimétisme, les autres personnes de l'équipe auront tendance à faire de même. 147 | 148 | Le Mob Programming reste un formidable outil pédagogique lors de formations et ateliers. Son efficacité pour apprendre ou pour aligner les pratiques de code, de conception, d'architecture, de connaissance du métier ou de documentation n'est plus à démonter. 149 | 150 | ### L’importance des techniques de refactoring 151 | 152 | Le _refactoring_ consiste à retravailler un code source sans en modifier le comportement, afin d'en améliorer la lisibilité et de le rendre beaucoup plus facile à maintenir et propice à accueillir des évolutions. 153 | 154 | La présence d'une couverture de tests suffisamment solide pour garantir que les améliorations de code se font en toute sécurité : nous sommes capables de vérifier de façon fiable si nous avons cassé quelque chose. 155 | 156 | Dette technique : plus l'équipe emprunte, plus elle réduit sa capacité à délivrer de la valeur à l'avenir. 157 | 158 | C'est certainement le soin apporté au nommage qui apporte le plus de valeur à une base de code. 159 | 160 | Il faut veiller à ne pas pousser les abstractions trop loin : trop de généricité peut, d'une part, rendre le code moins facile à comprendre, et, d'autre part, le rendre moins évolutif parce qu'il devient utilisé par beaucoup trop de monde. 161 | 162 | Le soin qui est apporté aux signatures de méthodes est déterminant pour l'évolutivité et la compréhension du code. 163 | 164 | Un code qui est écrit comme une fonction pure, c'est à dire que pour chaque ensemble de paramètres en entrée on attend une valeur en sortie bien déterminée, est beaucoup plus facile à tester et donc à réécrire. 165 | 166 | Le code de test est ce qui va servir de point d'entrée pour tout nouvel arrivant, et il peut offrir une valeur documentaire élevée. 167 | 168 | Pratiquer le _refactoring_ est une forme d'hygiène du code. 169 | 170 | ### Travailler avec du code legacy 171 | 172 | Les projets "legacy" sont la plupart du temps les plus sensibles sur le plan financier : ceux qui ont le plus de valeur pour le métier et donc ceux qui rapportent le plus d'argent. 173 | 174 | On essaye de restreindre l'effort à fournir en délimitant soigneusement notre périmètre d'intervention. 175 | 176 | Avec du _code legacy_, la sécurisation du parcours s'obtient en écrivant les tests qui manquent. 177 | 178 | Il est important de se concentrer sur les réécritures qui apportent une réelle valeur. 179 | 180 | Tout nouveau test augmentant le score de couverture se montrera pertinent mais la couverture de test comporte une faiblesse importante : elle mesure seulement les lignes de code qui sont exécutées par les tests, indépendamment du résultat. 181 | 182 | La couverture optimale de tests représente un filet de sécurité appréciable qui permet, en libérant l'esprit du risque de régression, d'expérimenter et de tenter des actions de _refactoring_ plus audacieuses. 183 | 184 | Michael FEATHERS : notion de "seam" : on cherche à identifier des _coutures_ dans le code, c'est-à-dire des points précis où on peut intervenir sans modifier significativement le code de production. 185 | 186 | Une difficulté récurrente lorsqu'on réécrit du _code legacy_ est de s'enfermer dans des optimums locaux, avec des _refactorings_ satisfaisants au premier abord mais qui empêchent de s'aventurer plus loin. 187 | 188 | L'idée essentielle est, lorsqu'on souhaite apporter une évolution, de mettre en place les conditions propices au changement, notamment grâce aux techniques de refactoring, et de pouvoir ainsi apporter facilement le changement souhaité. 189 | 190 | Une fois que la couverture du code par les tests paraît satisfaisante, nous disposons d'un filet de sécurité qui nous permet de procéder à la phase de refactoring en toute sérénité. 191 | 192 | ### Étude détaillée du kata Fraction 193 | 194 | Mise en oeuvre des 4 règles de design simple. 195 | 196 | ## PARTIE 2 : Techniques avancées et élargissements 197 | 198 | ### Principes et outils pour tester efficacement 199 | 200 | Caractéristiques F.I.R.S.T. : 201 | 202 | - F pour fast : il est important de s'assurer que chaque test est suffisamment véloce, afin de ne pas pénaliser l'ensemble de la suite de tests. 203 | - I pour isolated/independent : on doit pouvoir lancer les tests individuellement, en parallèle et dans n'importe quel ordre d'exécution, et garantir que cela n'a aucun impact sur le résultat. 204 | - R pour repeatable (reproductible) : il doit s'exécuter comme un système fermé sans accès à des ressources extérieures. 205 | - S pour self-verifying (auto-validant) : le résultat doit être outillé et sauter aux yeux, sans requérir une intervention humaine pour comprendre ou interpréter le résultat. 206 | - T pour Timely ou Thorough : opportun et/ou précis : il est préférable de les séparer en se limitant à un test par scénario. 207 | 208 | Les doublures de tests : 209 | 210 | - Dummy object : variable fantoche 211 | - Test Stub 212 | - Test Spy 213 | - Mock Object 214 | - Fake Object : composant factice, c'est une implémentation réelle mais simplifiée de la vraie classe, une sorte de simulateur. Ils demandent une logique spécifique et font partie des cas pour lesquels il est préférable d'écrire un substitut à la main que de passer par une bibliothèque. 215 | 216 | L'utilisation des bibliothèques de substitutions (ex: Mockito) est rarement simple et une utilisation efficace nécessite d'en comprendre les principes, mécanismes et limitations. 217 | 218 | Il est plus prudent de ne substituer que les objets qu'on maîtrise : "ne substituer que le code dont vous êtes propriétaire". 219 | 220 | Les niveaux de tests : 221 | 222 | - Test unitaire 223 | - Test d'intégration (tests étroits / tests de grande envergure) 224 | - Test de bout en bout (end to end = e2e) 225 | - Test exploratoire 226 | 227 | En plus des données utiles pour les tests, on pourrait choisir parfois de prévoir des données qu'on appelle des "données parasites". Les tests n'ont pas besoin de ces données pour être exécutées, mais leur présence permet de simuler au plus près la production. 228 | 229 | Chaque type de test apporte son niveau de protection. 230 | 231 | ### Outils et techniques avancées de TDD 232 | 233 | Une _User Story_ doit respecter les caractéristiques I.N.V.E.S.T. : 234 | 235 | - Independent / Indépendante 236 | - Negotiable / Négociable 237 | - Valuable / Apporte de la valeur 238 | - Estimable 239 | - Small / Petite 240 | - Testable 241 | 242 | Découpage en arbre de fonctionnalités : 243 | 244 | - TDD inside-out : approche _Bottom Up_ (Chicago School ou classic approach) 245 | - TDD outside-in : approche _Top Down_ (London School ou mockist approach) 246 | 247 | ATDD (_Acceptance Test Driven Development_) : généralement on n'utilise pas de substituts pour ce test ou on minimise leur utilisation aux frontières de notre système. 248 | 249 | ATDD = indicateur de fin de développement (quand il passe au vert). 250 | 251 | TDD "_as if you meant it_" : commencer par mettre tout le code dans le corps de la méthode de test. 252 | 253 | TPP (_Transformation Priority Premise_) : le meilleur moyen pour rester en mode _baby step_ est d'appliquer les transformations priorisées proposées par Robert MARTIN. 254 | 255 | ### Techniques de conception 256 | 257 | - Principes S.O.L.I.D. : 258 | - Single Responsibility Principle 259 | - Open-Closed Principle 260 | - Liskov Substitution Principle 261 | - Interface Segregation Principle 262 | - Dependency Inversion Principle 263 | - Composition over inheritance 264 | - Faible couplage et forte cohésion 265 | - Principe de dépendance du spécifique vers le générique : le code le plus stable ne doit pas dépendre de code moins stable (le générique ne doit jamais dépendre du spécifique). 266 | - Loi de Demeter (principe de connaissance minimale) : limiter ce qu'on expose, notamment les détails d'implémentation. 267 | - Principe du "_Tell Don't Ask_" : au lieu de demander les données à un objet pour les manipuler et les modifier, il est préférable de fournir directement les abstractions qui permettent d'effectuer des actions de plus haut niveau. (POJO ou DTO sont juste des structures clef/valeur de luxe). 268 | - Principe d'Hollywood "_Don't call us, we'll call you_" : lié au principe d'inversion de contrôle (IoC) : réaction à des évènements : callback, hook, ... Le style fonctionnel aide à renforcer ce principe. 269 | - Le jeu de contraintes "_Object Calisthenics_" : 9 règles de Jeff BRAY, un code qui applique ces règles tend naturellement à être respectueux de la plupart des autres principes théoriques : 270 | - _Only one level of indentation per method_ : permet de favoriser le découpage et de réduire l'éparpillement du contexte. 271 | - _Don't use the 'else' keyword_ : sortir plus tôt de la méthode, _fail-fast_, ... 272 | - _Wrap all primitives and strings_ : sécurise le code en masquant les détails d'implémentation. En encapsulant les données et en exposant des comportements. 273 | - _First class collections_ : permet de rapprocher le traitement des données qu'il manipule. 274 | - _One dot per line_ : on peut facilement substituer le comportement des objets amis ou voisins pour tester unitairement la fonctionnalité voulue. 275 | - _Don't abbreviate_ : favorise l'expression de l'intention en nommant explicitement les notions métier. 276 | - _Keep all entities small_ : design plus simple et meilleure lisibilité donc meilleure maintenabilité. 277 | - _No classes with more than two instance variables_ : renforce l'encapsulation. 278 | - _No getter/setters_ : on tend vers des objets immuables (simplicité, thread-safe, robustesse). 279 | - Code smells courants : 280 | - Code complexe ou omniscient 281 | - Données globales partagées 282 | - Primitive obsession 283 | - Commentaire honteux 284 | - Litanie de paramètres 285 | - Mutation des paramètres d'une méthode (effet de bord) 286 | - Données muables 287 | - Design Patterns : 288 | - Switchs multiples vers le pattern strategy. 289 | - Boucles visibles vers le pattern composite. 290 | - Vérification de nullité vers le pattern Null Object. 291 | 292 | ### Transformation de code à caractère architectural 293 | 294 | - Découpler un lien navigable (association) (DDD et notion d'agrégat). 295 | - Architecture hexagonale et inversion de dépendance. 296 | - Style réactif orienté chorégraphie (plutôt que l'orchestration) et pattern Observer. 297 | - Stateful -> stateless. 298 | - Service idempotent. 299 | 300 | ## PARTIE 3 : Craft et attitudes 301 | 302 | ### Introduire le craft dans votre contexte 303 | 304 | Code retreat : (retraites de code) : évènement sur une journée où les participants répètent six fois le même kata, en TDD et binôme, mais avec à chaque fois des contraintes différentes. C'est une expérience incontournable. 305 | 306 | Initier une dynamique consiste à lancer des actions plutôt modestes, mais régulièrement (dont l'effet cumulé suscitera l'intérêt). 307 | 308 | Il faut être centré sur la livraison de valeur : 309 | 310 | - Se rappeler les objectifs du craft pour recentrer aussi notre attention sur la livraison de valeur. 311 | - Ne pas consacrer une part excessive de temps de travail sur sur l'amélioration du code en négligeant la livraison de valeur. 312 | - Toute initiative d'amélioration doit rester subordonnée à des bénéfices attendus et avérés. 313 | 314 | Transférer les compétences fait partie intégrante du craft, mais dans une approche bienveillante avec des collègues qui en ont manifesté l'envie. 315 | 316 | ### Au-delà des pratiques, un état d’esprit 317 | 318 | Tout le monde pourrait devenir expert dans une discipline, à condition de pratiquer régulièrement et intensément. La répétition et la pratique engendre des effets positifs. 319 | 320 | Il faut être suffisamment curieux pour maintenir ses connaissances à jour. 321 | 322 | L'intérêt des katas : 323 | 324 | - réside surtout dans l'opportunité d'acquérir, par la répétition, certains réflexes qui vont s'appliquer naturellement sur un vrai projet. 325 | - réside aussi dans la capacité d'aborder le même problème de plusieurs façons. 326 | 327 | La veille : on nous demande de renforcer continuellement nos connaissances et expertises. La veille ne peut se faire qu'en sacrifiant une partie de notre temps personnel, il est donc important de bien cibler les sujets. 328 | 329 | La transmission : la majeur partie de notre savoir faire provient des autres, il apparaît juste et naturel, à notre tour, et en fonction de nos capacités, de transmettre nos compétences aux autres. Avec des bénéfices non négligeables : 330 | 331 | - amélioration progressive des conditions de travail avec des bases de code de plus en plus propres et faciles à maintenir. 332 | - construction d'une communauté de bonnes pratiques. 333 | - bénéficier du savoir-faire des autres. 334 | - amélioration personnelle, nous forçant à consolider nos connaissances. 335 | - satisfaction personnelle. 336 | 337 | L'accompagnement par l'exemple, en "pairant", en "mobbant" ou en effectuant des revues de code bienveillantes, est beaucoup mieux accepté. 338 | 339 | En se cantonnant dans notre zone de confort on perd le sel de ce qui fait notre métier : renouvellement permanent des techniques et pratiques. 340 | 341 | L'expérimentation et l'échec font partie de la réussite. 342 | 343 | Surconfiance : effet Dunning-Kruger : biais cognitif par lequel les personnes découvrant un domaine pourraient surestimer leur compétence. Corollaire : les personnes les plus expertes auraient tendance à minimiser leurs compétences, en pensant que ce qui est facile pour elles l'est forcément pour les autres. 344 | 345 | Le craft se distingue aussi bien par ses savoirs-faire que par ses valeurs éthiques telles que l'humilité, la bienveillance et le partage. 346 | 347 | Plus on gagne en expérience et en sagesse et plus on prend conscience de l'étendue de notre ignorance. 348 | 349 | L'humilité est un moteur qui va nous inciter à nous améliorer continuellement, à viser l'excellence et à faciliter nos interactions avec les autres. 350 | 351 | On peut s'autoriser à féliciter quelqu'un en public mais les _feedbacks_ négatifs ne devraient être délivrés qu'en tête à tête. 352 | 353 | Dans un contexte bienveillant, chacun va pouvoir progresser avec l'aide des autres et pouvoir se sentir mieux. 354 | 355 | Le rôle de "Tech Lead", s'il peut être attribué explicitement par un manager, s'obtient dans de nombreux cas par la reconnaissance des pairs, il donne l'exemple en aidant les autres, il préfère convaincre plutôt que d'imposer et il ne craint pas que d'autres tiennent aussi ce rôle. 356 | 357 | Être pragmatique revient à savoir faire les bons compromis pour maximiser les chances de réussite d'un projet sur le court, moyen et long terme. 358 | 359 | Être développeur, au-delà d'être bon technicien, c'est avant tout être un bon communicant (échanger et collaborer). La communication entre développeurs est essentielle (prodiguer des feedbacks). 360 | 361 | ### Craft 2.0 362 | 363 | Le craft correspond aux pratiques nécessaires pour atteindre la maturité. 364 | 365 | --- 366 | :point_left: [Retour à l'accueil](../README.md) 367 | --------------------------------------------------------------------------------