SlideShare une entreprise Scribd logo
1  sur  34
Télécharger pour lire hors ligne
Clean Code en pratique


   Jérôme Avoustin




       www.agiletour.com   1
Jérôme Avoustin
                            .NET, Agilité, Performance
                                                    @JeromeAvoustin




                                           Agilité, AMOA, .NET, SharePoint
http://blog.avoustin.com
                                                http://www.smartview.fr
                            www.agiletour.com                             2
Agenda
•   Pourquoi ?
•   Qu’est ce qu’un Code Clean ?
•   Les mauvaises pratiques
•   Les bonnes pratiques




                      www.agiletour.com        3
Disclaimer
• Discours essentiellement pour :
  o Langages objets
  o Langages évolués


• Je n’entre pas dans tous les détails
  o Je vais aller très vite sur certaines choses
• Je vais enfoncer quelques portes ouvertes
• Je ne veux pas essayer de vous convaincre
• Il peut y avoir un peu de frustration
                         www.agiletour.com                  4
Agile et Qualité




Continuous attention to technical excellence
     and good design enhances agility.
                         9e principe du Manifeste Agile




                   www.agiletour.com                      5
Pourquoi la Qualité ?




Responding to change over following a plan
                        3e valeur du Manifeste Agile




                  www.agiletour.com                    6
Une vue de la Qualité

        Une application informatique est de qualité lorsque
Coût    le coût d’ajout d’une fonctionnalité reste stable.
 Coût




                                                               Temps
                                                              Temps


                            www.agiletour.com                          7
Pourquoi un Code Clean ?


• Pour s’adapter au changement à moindre coût
• Pour pérenniser les produits
• Pour valoriser le travail d’un développeur
  o Vecteur de motivation intrinsèque
• Pour réconcilier progrès économique et social
                     Kent Beck, Extreme Programming Explained 2nd Ed.




                      www.agiletour.com                                 8
Qu’est-ce qu’un Code Clean ?
• Bjarne Stroustrup, Grady Booch, Ron Jeffries, Kent
  Beck, Michael Feathers, Ward Cunningham…
  o Testé !
  o Elégant et facile à lire
  o Montre clairement l’intention de son auteur
    • Ecrit à destination des prochains développeurs
    • Il est difficile pour les bugs de se cacher
  o Simple
    • Non dupliqué
    • Contient un minimum d’artefacts (classes, méthodes, etc.)
  o Les dépendances sont minimales et explicites

                           www.agiletour.com                      9
A propos des tests…

             Quand j’entends que les tests
      « c’est pour ceux qui savent pas coder » …




Source : http://lesjoiesducode.tumblr.com/post/31452862688/quand-le-stagiaire-me-dit-que-les-tests-cest-pour



                                            www.agiletour.com                                                  10
Quelles horreurs dans le code ?

    Code Smells
                                   Large class
            Data class
                           Duplicated code                 Refused bequest
Uncommunicative name             Lazy class                Type embedded in name
Message chain      Conditional complexity                   Inappropriate intimacy
                                                   Data clumps
  Speculative generality     Comments                                 Dead code
                                Primitive obsession Shotgun Surgery
   Inconsistent names                                      Middle man
                         Divergent change     Feature envy
    Temporary field       Long parameter list    Long method
    Wrong level of abstraction                   Alternative classes with different interfaces
                        Parallel inheritance hierarchies


                                   www.agiletour.com                                       11
Quelles horreurs dans le code ?


Singleton
Tight coupling
Untestable
Premature optimization
I ndescriptive naming
Duplication
          www.agiletour.com         12
Quelles bonnes pratiques ?



      SOLID                       YAGNI

DRY           SoC
                                     GRASP
  KISS         Loi de Demeter
              www.agiletour.com              13
Quelles bonnes pratiques ?


Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
I nterface Segregation Principle
Dependency Inversion Principle

            www.agiletour.com         14
Nommage
• Les noms doivent révéler l’intention
• Ne tronquez pas les mots !
    o Le coût du
•   Utilisez des mots qui ont du sens
•   Pas d’encodage
•   Ne surchargez pas les noms d’infos inutiles
•   N’hésitez pas à changer un nom



                      www.agiletour.com           15
Duplication de code


• Règle n°2, selon Kent Beck
• DRY : Don’t Repeat Yourself !




                                         Extraction de méthode

                     www.agiletour.com                           16
Abstraction
• 1 niveau d’abstraction par méthode
   o Extraction de méthode
   o Polymorphisme
   o Descendre/Monter/Déplacer une méthode
   o Et même le renommage !
• Loi de Demeter
   o « Don’t talk to strangers »


a.getB().getC().doSomething()                a.doSomething()


                         www.agiletour.com                     17
Abstraction


• Préoccupations transverses
  o A ne pas mélanger avec le code métier
    • Securité, logs, cache, transaction, etc.
  o Introduire l’AOP




                         www.agiletour.com                 18
Couplage fort


               A
Tests
Intégration
Réutilisation
Correction de bugs
Ajout de fonctions
Etc.

                     www.agiletour.com               19
Couplage fort
• Qu’est-ce qui crée un couplage fort ?
  o new MaDependance();
  o Les appels statiques
  o Les dépendances sur des classes concrètes
• Que faut-il faire ?
  o Méthodes d’instance
  o Injection de dépendances : pattern n°1
  o Utilisation de types abstraits ou d’interfaces



                        www.agiletour.com              20
Injection de dépendances

public class A                            On va injecter B et C !
{
  private B b;

    public void ExecuteA(int a)
    {                                On crée un couplage
      b = new B();                   fort entre A et B/C !!
      C c = new C();

        if (a != 3)                 A collabore avec B et C
           b.ExecuteB();
        else
           c.ExecuteC();
    }
}
Injection de dépendances
   • Comment injecter B et C ?                               public class A {
                                                               private B b;
       o Par constructeur                                      private C c;

       o Par setter                                            public A(B b) { this.b = b; }
         • Late binding                                        public void setC(C c) {
       o Reflection                                              this.c = c;
                               static Main (string[] args)
                                                               }
                               {
                                 B b = new B();
                                                               public void ExecuteA() {
                                 A a = new A(b);
En bleu, peut être délégué à                                     int a = 1;
   une Factory : ce sont                                         b = new B();
                                   a.setC(new C1());
                                                                 C c = new C();
                                   a.ExecuteA();
les Conteneurs d’IoC                                             if (a != 3)
                                                                    b.ExecuteB();
                                   a.setC(new C1());
                                                                 else
                                   a.ExecuteA();
                                                                    C.ExecuteC();
                               }
                                                               }
Méthodes longues
•   Qui a des normes de code à respecter ?
•   Qui les respecte ?
•   Quelle est la taille maximale pour une méthode ?
•   Petite astuce (d’un certain J.A.) :
    o Commentez votre méthode sans modération
    o Renommez les variables, champs, constantes, etc.
      avec les concepts utilisés dans les commentaires
    o Faites des extractions de méthode en utilisant les
      commentaires pour nommer les méthodes
    o Eliminez la duplication
    o Virez les commentaires !
                         www.agiletour.com                  23
Commentaires
• Uncle Bob : « Comments are always failures »
  o Ils mentent, vieillissent très mal, ne sont pas
    refactorables, etc.
  o « Aveu de faiblesse » à…
    • Utiliser un bon nom
    • Découper une méthode
    • Monter en abstraction
  o Avant d’écrire un commentaire, faites 7 fois le tour de
    votre chaise 
  o Sauf pour : explication (pourquoi ?), javadoc,
    copyright.

                        www.agiletour.com                24
Gestion d’exceptions
• Principe n°1 : Fail Fast
  o Programmation défensive, par assertions
  o Lever des exceptions dès que nécessaire
    • i.e. : pour des cas non métiers
  o Ne pas masquer systématiquement les autres
    exceptions
    • Type NullPointerException




                       www.agiletour.com               25
Gestion d’exceptions
• Plus de code retour !
• Règle n°1 : ne pas gérer les exceptions !
  o Java : « Use unchecked exceptions » (M. Feathers)
• Règle n°2 : Traiter les exceptions au niveau le + haut
  o IHM, Services, etc.
• Règle n°3 : Traiter les exceptions dans les niveaux
  intermédiaires uniquement si nécessaire
• Règle n°4 : Ne pas retourner null
  o Ou même return;


                          www.agiletour.com               26
Tests
• Indispensables pour modifier le code
• Le code des tests est au moins aussi important que
  le code de production
  o Les tests doivent être clean
  o Un concept par test
  o Utilisez des noms et une structure qui documentent
    • ShouldDoThisWhenThat()
    • Given / When / Then
• Qualité essentielle : lisibilité
  o Un test doit pouvoir se lire comme une histoire
  o Créez votre propre DSL de test !

                         www.agiletour.com                27
Tests


Fast
I ndependant
Repeatable
Self-Validating
Timely
       www.agiletour.com      28
Autres conseils
• N’écrivez pas de Singleton !
  o Mettez en place l’injection de dépendances
  o Et gérez la durée de vie de vos objets


• Ne pensez pas héritage, pensez polymorphisme
  o Sinon : "a un" au lieu de "est un“


• Ne pensez pas "switch/if", pensez polymorphisme
  o Pattern strategy

                        www.agiletour.com                29
Autres conseils
• Du code non testé n’est pas maintenable
• Ne pensez pas "réutilisabilité", pensez
  abstraction
  o La réutilisabilité est une conséquence de la montée
    en abstraction et de l’élimination de la duplication
• Pas d’optimisation prématurée !
  o YAGNI ! KISS !
  o « First make it work, then make it right »


• Tout ça, ça commence DEMAIN !
                        www.agiletour.com                  30
Aller plus loin




www.agiletour.com                31
Pour finir…
Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.
Martin Fowler

       Codez toujours en pensant que celui qui maintiendra
   votre code est un psychopathe qui connait votre adresse.
                                            Martin Golding




                         www.agiletour.com                32
Pour finir…
Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.
Martin Fowler

       Codez toujours en pensant que celui qui maintiendra
   votre code est un psychopathe qui connait votre adresse.
                                            Martin Golding


Penser que les tests [et le refactoring] ralentissent le développement
c’est comme penser que prendre des voyageurs ralentit le bus
David Evans

                              www.agiletour.com                    33
MERCI !
                                     @JeromeAvoustin



http://blog.avoustin.com


                            www.agiletour.com      34

Contenu connexe

Tendances

Organiser son CI/CD - présentation
Organiser son CI/CD - présentation Organiser son CI/CD - présentation
Organiser son CI/CD - présentation Julien Garderon
 
Branching and Merging Practices
Branching and Merging Practices Branching and Merging Practices
Branching and Merging Practices Rajesh Kumar
 
[devops REX 2016] DevOps at Scale : ce qu’on fait, ce que l’on a appris chez ...
[devops REX 2016] DevOps at Scale : ce qu’on fait, ce que l’on a appris chez ...[devops REX 2016] DevOps at Scale : ce qu’on fait, ce que l’on a appris chez ...
[devops REX 2016] DevOps at Scale : ce qu’on fait, ce que l’on a appris chez ...devops REX
 
Docker and the Linux Kernel
Docker and the Linux KernelDocker and the Linux Kernel
Docker and the Linux KernelDocker, Inc.
 
Why Docker
Why DockerWhy Docker
Why DockerdotCloud
 
Hexagonal architecture with Spring Boot
Hexagonal architecture with Spring BootHexagonal architecture with Spring Boot
Hexagonal architecture with Spring BootMikalai Alimenkou
 
React js入門教學
React js入門教學React js入門教學
React js入門教學TaiShunHuang
 
Docker introduction
Docker introductionDocker introduction
Docker introductiondotCloud
 
Applications Android - cours 11 : Boites de dialogue
Applications Android - cours 11 : Boites de dialogueApplications Android - cours 11 : Boites de dialogue
Applications Android - cours 11 : Boites de dialogueAhmed-Chawki Chaouche
 
Présentation de Django @ Orange Labs (FR)
Présentation de Django @ Orange Labs (FR)Présentation de Django @ Orange Labs (FR)
Présentation de Django @ Orange Labs (FR)Martin Latrille
 
Pros & cons of svelte
Pros & cons of sveltePros & cons of svelte
Pros & cons of svelteElenorWisozk
 
Git flow Introduction
Git flow IntroductionGit flow Introduction
Git flow IntroductionDavid Paluy
 
Introduction to Rust language programming
Introduction to Rust language programmingIntroduction to Rust language programming
Introduction to Rust language programmingRodolfo Finochietti
 
Intégration de SonarQube dans GitLab ci
Intégration de SonarQube dans GitLab ciIntégration de SonarQube dans GitLab ci
Intégration de SonarQube dans GitLab ciwiemfourati
 
SOLID Principles and The Clean Architecture
SOLID Principles and The Clean ArchitectureSOLID Principles and The Clean Architecture
SOLID Principles and The Clean ArchitectureMohamed Galal
 
Afterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiquesAfterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiquesOCTO Technology Suisse
 
Cours c#
Cours c#Cours c#
Cours c#zan
 
Gitflow - Branching and Merging Flow for Git
Gitflow - Branching and Merging Flow for GitGitflow - Branching and Merging Flow for Git
Gitflow - Branching and Merging Flow for GitMaulik Shah
 

Tendances (20)

Organiser son CI/CD - présentation
Organiser son CI/CD - présentation Organiser son CI/CD - présentation
Organiser son CI/CD - présentation
 
Branching and Merging Practices
Branching and Merging Practices Branching and Merging Practices
Branching and Merging Practices
 
[devops REX 2016] DevOps at Scale : ce qu’on fait, ce que l’on a appris chez ...
[devops REX 2016] DevOps at Scale : ce qu’on fait, ce que l’on a appris chez ...[devops REX 2016] DevOps at Scale : ce qu’on fait, ce que l’on a appris chez ...
[devops REX 2016] DevOps at Scale : ce qu’on fait, ce que l’on a appris chez ...
 
Docker and the Linux Kernel
Docker and the Linux KernelDocker and the Linux Kernel
Docker and the Linux Kernel
 
Why Docker
Why DockerWhy Docker
Why Docker
 
Hexagonal architecture with Spring Boot
Hexagonal architecture with Spring BootHexagonal architecture with Spring Boot
Hexagonal architecture with Spring Boot
 
React js入門教學
React js入門教學React js入門教學
React js入門教學
 
Docker introduction
Docker introductionDocker introduction
Docker introduction
 
Applications Android - cours 11 : Boites de dialogue
Applications Android - cours 11 : Boites de dialogueApplications Android - cours 11 : Boites de dialogue
Applications Android - cours 11 : Boites de dialogue
 
Présentation de Django @ Orange Labs (FR)
Présentation de Django @ Orange Labs (FR)Présentation de Django @ Orange Labs (FR)
Présentation de Django @ Orange Labs (FR)
 
Architecting iOS Project
Architecting iOS ProjectArchitecting iOS Project
Architecting iOS Project
 
Pros & cons of svelte
Pros & cons of sveltePros & cons of svelte
Pros & cons of svelte
 
Git flow Introduction
Git flow IntroductionGit flow Introduction
Git flow Introduction
 
Introduction to Rust language programming
Introduction to Rust language programmingIntroduction to Rust language programming
Introduction to Rust language programming
 
Intégration de SonarQube dans GitLab ci
Intégration de SonarQube dans GitLab ciIntégration de SonarQube dans GitLab ci
Intégration de SonarQube dans GitLab ci
 
SOLID Principles and The Clean Architecture
SOLID Principles and The Clean ArchitectureSOLID Principles and The Clean Architecture
SOLID Principles and The Clean Architecture
 
Kubernetes
KubernetesKubernetes
Kubernetes
 
Afterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiquesAfterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiques
 
Cours c#
Cours c#Cours c#
Cours c#
 
Gitflow - Branching and Merging Flow for Git
Gitflow - Branching and Merging Flow for GitGitflow - Branching and Merging Flow for Git
Gitflow - Branching and Merging Flow for Git
 

En vedette

Clean Code I - Best Practices
Clean Code I - Best PracticesClean Code I - Best Practices
Clean Code I - Best PracticesTheo Jungeblut
 
training and sharing about clean code
training and sharing about clean codetraining and sharing about clean code
training and sharing about clean codeChonpin HSU
 
Effective Software Development in the 21st Century
Effective Software Development in the 21st CenturyEffective Software Development in the 21st Century
Effective Software Development in the 21st CenturyAgileee
 
Lightening Talk: Software craftsmanship
Lightening Talk: Software craftsmanshipLightening Talk: Software craftsmanship
Lightening Talk: Software craftsmanshipAgileee
 
Clean code and Code Smells
Clean code and Code SmellsClean code and Code Smells
Clean code and Code SmellsMario Sangiorgio
 
Software Craftsmanship
Software CraftsmanshipSoftware Craftsmanship
Software CraftsmanshipSandro Mancuso
 
рентабельный код
рентабельный кодрентабельный код
рентабельный кодMax Arshinov
 
Clean Code summary
Clean Code summaryClean Code summary
Clean Code summaryJan de Vries
 
Thiga - Notre retour d'expérience sur le Design sprint
Thiga - Notre retour d'expérience sur le Design sprintThiga - Notre retour d'expérience sur le Design sprint
Thiga - Notre retour d'expérience sur le Design sprintThiga
 
XebiConFr 15 - Ingenico Group : Microservices et architecture réactive pour u...
XebiConFr 15 - Ingenico Group : Microservices et architecture réactive pour u...XebiConFr 15 - Ingenico Group : Microservices et architecture réactive pour u...
XebiConFr 15 - Ingenico Group : Microservices et architecture réactive pour u...Publicis Sapient Engineering
 
Angle de tir pour toucher un animal posté au somment d'un arbre ?
Angle de tir pour toucher un animal posté au somment d'un arbre ?Angle de tir pour toucher un animal posté au somment d'un arbre ?
Angle de tir pour toucher un animal posté au somment d'un arbre ?Philippe Mongodin
 

En vedette (20)

Clean Code I - Best Practices
Clean Code I - Best PracticesClean Code I - Best Practices
Clean Code I - Best Practices
 
Clean code
Clean codeClean code
Clean code
 
training and sharing about clean code
training and sharing about clean codetraining and sharing about clean code
training and sharing about clean code
 
Effective Software Development in the 21st Century
Effective Software Development in the 21st CenturyEffective Software Development in the 21st Century
Effective Software Development in the 21st Century
 
Lightening Talk: Software craftsmanship
Lightening Talk: Software craftsmanshipLightening Talk: Software craftsmanship
Lightening Talk: Software craftsmanship
 
Clean code
Clean codeClean code
Clean code
 
Agile WTF
Agile WTFAgile WTF
Agile WTF
 
Clean code and Code Smells
Clean code and Code SmellsClean code and Code Smells
Clean code and Code Smells
 
Software Craftsmanship
Software CraftsmanshipSoftware Craftsmanship
Software Craftsmanship
 
рентабельный код
рентабельный кодрентабельный код
рентабельный код
 
Clean Code summary
Clean Code summaryClean Code summary
Clean Code summary
 
Thiga - Notre retour d'expérience sur le Design sprint
Thiga - Notre retour d'expérience sur le Design sprintThiga - Notre retour d'expérience sur le Design sprint
Thiga - Notre retour d'expérience sur le Design sprint
 
XebiConFr 15 - Ingenico Group : Microservices et architecture réactive pour u...
XebiConFr 15 - Ingenico Group : Microservices et architecture réactive pour u...XebiConFr 15 - Ingenico Group : Microservices et architecture réactive pour u...
XebiConFr 15 - Ingenico Group : Microservices et architecture réactive pour u...
 
Hybris @ Neev
Hybris @ NeevHybris @ Neev
Hybris @ Neev
 
Clean coding-practices
Clean coding-practicesClean coding-practices
Clean coding-practices
 
Angle de tir pour toucher un animal posté au somment d'un arbre ?
Angle de tir pour toucher un animal posté au somment d'un arbre ?Angle de tir pour toucher un animal posté au somment d'un arbre ?
Angle de tir pour toucher un animal posté au somment d'un arbre ?
 
Libro2
Libro2Libro2
Libro2
 
Capitulo i enviar a justino
Capitulo i  enviar a justinoCapitulo i  enviar a justino
Capitulo i enviar a justino
 
Autos híbridos
Autos híbridosAutos híbridos
Autos híbridos
 
Power point
Power pointPower point
Power point
 

Similaire à Clean code en pratique

C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?Rémi Lesieur
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsThierry Gayet
 
20081023 - Paris Vi Master STL TA - Initiation Maven
20081023 - Paris Vi Master STL TA - Initiation Maven20081023 - Paris Vi Master STL TA - Initiation Maven
20081023 - Paris Vi Master STL TA - Initiation MavenArnaud Héritier
 
Design poo togo_jug_final
Design poo togo_jug_finalDesign poo togo_jug_final
Design poo togo_jug_finalagnes_crepet
 
Design poo togo_jug_final
Design poo togo_jug_finalDesign poo togo_jug_final
Design poo togo_jug_finalDuchess France
 
Paris Web 2015 - Atelier desendettement javascript
Paris Web 2015 - Atelier desendettement javascriptParis Web 2015 - Atelier desendettement javascript
Paris Web 2015 - Atelier desendettement javascriptMichael Akbaraly
 
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?Christophe HERAL
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défautsJulien Jakubowski
 
Agile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAgile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAntoine Blk
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?CGI Québec Formation
 
Cocoaheads Paris Nombembre Test unitaires
Cocoaheads Paris Nombembre Test unitairesCocoaheads Paris Nombembre Test unitaires
Cocoaheads Paris Nombembre Test unitairesCocoaHeads France
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...Cyrille Grandval
 
Paris Web 2015 - Atelier désendettement Javascript legacy
Paris Web 2015 - Atelier désendettement Javascript legacyParis Web 2015 - Atelier désendettement Javascript legacy
Paris Web 2015 - Atelier désendettement Javascript legacyFrançois Petitit
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logiciellecyrilgandon
 
Tdd en action - refactoring
Tdd en action - refactoringTdd en action - refactoring
Tdd en action - refactoringEric Mignot
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésDjamel Zouaoui
 
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.Comment récupérer un projet Web pourri ... et réussir à travailler dessus.
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.Guillaume RICHARD
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)French Scrum User Group
 
CocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - EpitezCocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - EpitezCocoaHeads France
 

Similaire à Clean code en pratique (20)

C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
 
20081023 - Paris Vi Master STL TA - Initiation Maven
20081023 - Paris Vi Master STL TA - Initiation Maven20081023 - Paris Vi Master STL TA - Initiation Maven
20081023 - Paris Vi Master STL TA - Initiation Maven
 
Design poo togo_jug_final
Design poo togo_jug_finalDesign poo togo_jug_final
Design poo togo_jug_final
 
Design poo togo_jug_final
Design poo togo_jug_finalDesign poo togo_jug_final
Design poo togo_jug_final
 
Paris Web 2015 - Atelier desendettement javascript
Paris Web 2015 - Atelier desendettement javascriptParis Web 2015 - Atelier desendettement javascript
Paris Web 2015 - Atelier desendettement javascript
 
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défauts
 
Agile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAgile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defauts
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
 
Cocoaheads Paris Nombembre Test unitaires
Cocoaheads Paris Nombembre Test unitairesCocoaheads Paris Nombembre Test unitaires
Cocoaheads Paris Nombembre Test unitaires
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
 
Paris Web 2015 - Atelier désendettement Javascript legacy
Paris Web 2015 - Atelier désendettement Javascript legacyParis Web 2015 - Atelier désendettement Javascript legacy
Paris Web 2015 - Atelier désendettement Javascript legacy
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
 
Tdd en action - refactoring
Tdd en action - refactoringTdd en action - refactoring
Tdd en action - refactoring
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisés
 
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.Comment récupérer un projet Web pourri ... et réussir à travailler dessus.
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
 
CocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - EpitezCocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - Epitez
 

Plus de Jérôme Avoustin

Le courage de vivre consciemment
Le courage de vivre consciemmentLe courage de vivre consciemment
Le courage de vivre consciemmentJérôme Avoustin
 
AT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesAT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesJérôme Avoustin
 

Plus de Jérôme Avoustin (6)

DDD implementation in Node
DDD implementation in NodeDDD implementation in Node
DDD implementation in Node
 
Refactoring Legacy Code
Refactoring Legacy CodeRefactoring Legacy Code
Refactoring Legacy Code
 
Le courage de vivre consciemment
Le courage de vivre consciemmentLe courage de vivre consciemment
Le courage de vivre consciemment
 
Le pic saint-loup
Le pic saint-loupLe pic saint-loup
Le pic saint-loup
 
Le pilotage par les tests
Le pilotage par les testsLe pilotage par les tests
Le pilotage par les tests
 
AT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesAT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillages
 

Clean code en pratique

  • 1. Clean Code en pratique Jérôme Avoustin www.agiletour.com 1
  • 2. Jérôme Avoustin .NET, Agilité, Performance @JeromeAvoustin Agilité, AMOA, .NET, SharePoint http://blog.avoustin.com http://www.smartview.fr www.agiletour.com 2
  • 3. Agenda • Pourquoi ? • Qu’est ce qu’un Code Clean ? • Les mauvaises pratiques • Les bonnes pratiques www.agiletour.com 3
  • 4. Disclaimer • Discours essentiellement pour : o Langages objets o Langages évolués • Je n’entre pas dans tous les détails o Je vais aller très vite sur certaines choses • Je vais enfoncer quelques portes ouvertes • Je ne veux pas essayer de vous convaincre • Il peut y avoir un peu de frustration www.agiletour.com 4
  • 5. Agile et Qualité Continuous attention to technical excellence and good design enhances agility. 9e principe du Manifeste Agile www.agiletour.com 5
  • 6. Pourquoi la Qualité ? Responding to change over following a plan 3e valeur du Manifeste Agile www.agiletour.com 6
  • 7. Une vue de la Qualité Une application informatique est de qualité lorsque Coût le coût d’ajout d’une fonctionnalité reste stable. Coût Temps Temps www.agiletour.com 7
  • 8. Pourquoi un Code Clean ? • Pour s’adapter au changement à moindre coût • Pour pérenniser les produits • Pour valoriser le travail d’un développeur o Vecteur de motivation intrinsèque • Pour réconcilier progrès économique et social Kent Beck, Extreme Programming Explained 2nd Ed. www.agiletour.com 8
  • 9. Qu’est-ce qu’un Code Clean ? • Bjarne Stroustrup, Grady Booch, Ron Jeffries, Kent Beck, Michael Feathers, Ward Cunningham… o Testé ! o Elégant et facile à lire o Montre clairement l’intention de son auteur • Ecrit à destination des prochains développeurs • Il est difficile pour les bugs de se cacher o Simple • Non dupliqué • Contient un minimum d’artefacts (classes, méthodes, etc.) o Les dépendances sont minimales et explicites www.agiletour.com 9
  • 10. A propos des tests… Quand j’entends que les tests « c’est pour ceux qui savent pas coder » … Source : http://lesjoiesducode.tumblr.com/post/31452862688/quand-le-stagiaire-me-dit-que-les-tests-cest-pour www.agiletour.com 10
  • 11. Quelles horreurs dans le code ? Code Smells Large class Data class Duplicated code Refused bequest Uncommunicative name Lazy class Type embedded in name Message chain Conditional complexity Inappropriate intimacy Data clumps Speculative generality Comments Dead code Primitive obsession Shotgun Surgery Inconsistent names Middle man Divergent change Feature envy Temporary field Long parameter list Long method Wrong level of abstraction Alternative classes with different interfaces Parallel inheritance hierarchies www.agiletour.com 11
  • 12. Quelles horreurs dans le code ? Singleton Tight coupling Untestable Premature optimization I ndescriptive naming Duplication www.agiletour.com 12
  • 13. Quelles bonnes pratiques ? SOLID YAGNI DRY SoC GRASP KISS Loi de Demeter www.agiletour.com 13
  • 14. Quelles bonnes pratiques ? Single Responsibility Principle Open-Closed Principle Liskov Substitution Principle I nterface Segregation Principle Dependency Inversion Principle www.agiletour.com 14
  • 15. Nommage • Les noms doivent révéler l’intention • Ne tronquez pas les mots ! o Le coût du • Utilisez des mots qui ont du sens • Pas d’encodage • Ne surchargez pas les noms d’infos inutiles • N’hésitez pas à changer un nom www.agiletour.com 15
  • 16. Duplication de code • Règle n°2, selon Kent Beck • DRY : Don’t Repeat Yourself ! Extraction de méthode www.agiletour.com 16
  • 17. Abstraction • 1 niveau d’abstraction par méthode o Extraction de méthode o Polymorphisme o Descendre/Monter/Déplacer une méthode o Et même le renommage ! • Loi de Demeter o « Don’t talk to strangers » a.getB().getC().doSomething() a.doSomething() www.agiletour.com 17
  • 18. Abstraction • Préoccupations transverses o A ne pas mélanger avec le code métier • Securité, logs, cache, transaction, etc. o Introduire l’AOP www.agiletour.com 18
  • 19. Couplage fort A Tests Intégration Réutilisation Correction de bugs Ajout de fonctions Etc. www.agiletour.com 19
  • 20. Couplage fort • Qu’est-ce qui crée un couplage fort ? o new MaDependance(); o Les appels statiques o Les dépendances sur des classes concrètes • Que faut-il faire ? o Méthodes d’instance o Injection de dépendances : pattern n°1 o Utilisation de types abstraits ou d’interfaces www.agiletour.com 20
  • 21. Injection de dépendances public class A On va injecter B et C ! { private B b; public void ExecuteA(int a) { On crée un couplage b = new B(); fort entre A et B/C !! C c = new C(); if (a != 3) A collabore avec B et C b.ExecuteB(); else c.ExecuteC(); } }
  • 22. Injection de dépendances • Comment injecter B et C ? public class A { private B b; o Par constructeur private C c; o Par setter public A(B b) { this.b = b; } • Late binding public void setC(C c) { o Reflection this.c = c; static Main (string[] args) } { B b = new B(); public void ExecuteA() { A a = new A(b); En bleu, peut être délégué à int a = 1; une Factory : ce sont b = new B(); a.setC(new C1()); C c = new C(); a.ExecuteA(); les Conteneurs d’IoC if (a != 3) b.ExecuteB(); a.setC(new C1()); else a.ExecuteA(); C.ExecuteC(); } }
  • 23. Méthodes longues • Qui a des normes de code à respecter ? • Qui les respecte ? • Quelle est la taille maximale pour une méthode ? • Petite astuce (d’un certain J.A.) : o Commentez votre méthode sans modération o Renommez les variables, champs, constantes, etc. avec les concepts utilisés dans les commentaires o Faites des extractions de méthode en utilisant les commentaires pour nommer les méthodes o Eliminez la duplication o Virez les commentaires ! www.agiletour.com 23
  • 24. Commentaires • Uncle Bob : « Comments are always failures » o Ils mentent, vieillissent très mal, ne sont pas refactorables, etc. o « Aveu de faiblesse » à… • Utiliser un bon nom • Découper une méthode • Monter en abstraction o Avant d’écrire un commentaire, faites 7 fois le tour de votre chaise  o Sauf pour : explication (pourquoi ?), javadoc, copyright. www.agiletour.com 24
  • 25. Gestion d’exceptions • Principe n°1 : Fail Fast o Programmation défensive, par assertions o Lever des exceptions dès que nécessaire • i.e. : pour des cas non métiers o Ne pas masquer systématiquement les autres exceptions • Type NullPointerException www.agiletour.com 25
  • 26. Gestion d’exceptions • Plus de code retour ! • Règle n°1 : ne pas gérer les exceptions ! o Java : « Use unchecked exceptions » (M. Feathers) • Règle n°2 : Traiter les exceptions au niveau le + haut o IHM, Services, etc. • Règle n°3 : Traiter les exceptions dans les niveaux intermédiaires uniquement si nécessaire • Règle n°4 : Ne pas retourner null o Ou même return; www.agiletour.com 26
  • 27. Tests • Indispensables pour modifier le code • Le code des tests est au moins aussi important que le code de production o Les tests doivent être clean o Un concept par test o Utilisez des noms et une structure qui documentent • ShouldDoThisWhenThat() • Given / When / Then • Qualité essentielle : lisibilité o Un test doit pouvoir se lire comme une histoire o Créez votre propre DSL de test ! www.agiletour.com 27
  • 29. Autres conseils • N’écrivez pas de Singleton ! o Mettez en place l’injection de dépendances o Et gérez la durée de vie de vos objets • Ne pensez pas héritage, pensez polymorphisme o Sinon : "a un" au lieu de "est un“ • Ne pensez pas "switch/if", pensez polymorphisme o Pattern strategy www.agiletour.com 29
  • 30. Autres conseils • Du code non testé n’est pas maintenable • Ne pensez pas "réutilisabilité", pensez abstraction o La réutilisabilité est une conséquence de la montée en abstraction et de l’élimination de la duplication • Pas d’optimisation prématurée ! o YAGNI ! KISS ! o « First make it work, then make it right » • Tout ça, ça commence DEMAIN ! www.agiletour.com 30
  • 32. Pour finir… Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler Codez toujours en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse. Martin Golding www.agiletour.com 32
  • 33. Pour finir… Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler Codez toujours en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse. Martin Golding Penser que les tests [et le refactoring] ralentissent le développement c’est comme penser que prendre des voyageurs ralentit le bus David Evans www.agiletour.com 33
  • 34. MERCI ! @JeromeAvoustin http://blog.avoustin.com www.agiletour.com 34