Clean Code en pratique   Jérôme Avoustin       www.agiletour.com   1
Jérôme Avoustin                            .NET, Agilité, Performance                                                    @...
Agenda•   Pourquoi ?•   Qu’est ce qu’un Code Clean ?•   Les mauvaises pratiques•   Les bonnes pratiques                   ...
Disclaimer• Discours essentiellement pour :  o Langages objets  o Langages évolués• Je n’entre pas dans tous les détails  ...
Agile et QualitéContinuous attention to technical excellence     and good design enhances agility.                        ...
Pourquoi la Qualité ?Responding to change over following a plan                        3e valeur du Manifeste Agile       ...
Une vue de la Qualité        Une application informatique est de qualité lorsqueCoût    le coût d’ajout d’une fonctionnali...
Pourquoi un Code Clean ?• Pour s’adapter au changement à moindre coût• Pour pérenniser les produits• Pour valoriser le tra...
Qu’est-ce qu’un Code Clean ?• Bjarne Stroustrup, Grady Booch, Ron Jeffries, Kent  Beck, Michael Feathers, Ward Cunningham…...
A propos des tests…             Quand j’entends que les tests      « c’est pour ceux qui savent pas coder » …Source : http...
Quelles horreurs dans le code ?    Code Smells                                   Large class            Data class        ...
Quelles horreurs dans le code ?SingletonTight couplingUntestablePremature optimizationI ndescriptive namingDuplication    ...
Quelles bonnes pratiques ?      SOLID                       YAGNIDRY           SoC                                     GRA...
Quelles bonnes pratiques ?Single Responsibility PrincipleOpen-Closed PrincipleLiskov Substitution PrincipleI nterface Segr...
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 ...
Duplication de code• Règle n°2, selon Kent Beck• DRY : Don’t Repeat Yourself !                                         Ext...
Abstraction• 1 niveau d’abstraction par méthode   o Extraction de méthode   o Polymorphisme   o Descendre/Monter/Déplacer ...
Abstraction• Préoccupations transverses  o A ne pas mélanger avec le code métier    • Securité, logs, cache, transaction, ...
Couplage fort               ATestsIntégrationRéutilisationCorrection de bugsAjout de fonctionsEtc.                     www...
Couplage fort• Qu’est-ce qui crée un couplage fort ?  o new MaDependance();  o Les appels statiques  o Les dépendances sur...
Injection de dépendancespublic class A                            On va injecter B et C !{  private B b;    public void Ex...
Injection de dépendances   • Comment injecter B et C ?                               public class A {                     ...
Méthodes longues•   Qui a des normes de code à respecter ?•   Qui les respecte ?•   Quelle est la taille maximale pour une...
Commentaires• Uncle Bob : « Comments are always failures »  o Ils mentent, vieillissent très mal, ne sont pas    refactora...
Gestion d’exceptions• Principe n°1 : Fail Fast  o Programmation défensive, par assertions  o Lever des exceptions dès que ...
Tests• Indispensables pour modifier le code• Le code des tests est au moins aussi important que  le code de production  o ...
TestsFastI ndependantRepeatableSelf-ValidatingTimely       www.agiletour.com      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...
Autres conseils• Du code non testé n’est pas maintenable• Ne pensez pas "réutilisabilité", pensez  abstraction  o La réuti...
Aller plus loinwww.agiletour.com                32
Pour finir…Any fool can write code that a computer can understand.Good programmers write code that humans can understand.M...
MERCI !                                     @JeromeAvoustinhttp://blog.avoustin.com                            www.agileto...
AgileTour Toulouse 2012 : clean code en pratique
Upcoming SlideShare
Loading in...5
×

AgileTour Toulouse 2012 : clean code en pratique

362

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
362
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

AgileTour Toulouse 2012 : clean code en pratique

  1. 1. Clean Code en pratique Jérôme Avoustin www.agiletour.com 1
  2. 2. Jérôme Avoustin .NET, Agilité, Performance @JeromeAvoustin Agilité, AMOA, .NET, SharePointhttp://blog.avoustin.com http://www.smartview.fr www.agiletour.com 3
  3. 3. Agenda• Pourquoi ?• Qu’est ce qu’un Code Clean ?• Les mauvaises pratiques• Les bonnes pratiques www.agiletour.com 4
  4. 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 5
  5. 5. Agile et QualitéContinuous attention to technical excellence and good design enhances agility. 9e principe du Manifeste Agile www.agiletour.com 6
  6. 6. Pourquoi la Qualité ?Responding to change over following a plan 3e valeur du Manifeste Agile www.agiletour.com 7
  7. 7. Une vue de la Qualité Une application informatique est de qualité lorsqueCoût le coût d’ajout d’une fonctionnalité reste stable. Coût Temps Temps www.agiletour.com 8
  8. 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 9
  9. 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 10
  10. 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 11
  11. 11. Quelles horreurs dans le code ? Code Smells Large class Data class Duplicated code Refused bequestUncommunicative name Lazy class Type embedded in nameMessage 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 12
  12. 12. Quelles horreurs dans le code ?SingletonTight couplingUntestablePremature optimizationI ndescriptive namingDuplication www.agiletour.com 13
  13. 13. Quelles bonnes pratiques ? SOLID YAGNIDRY SoC GRASP KISS Loi de Demeter www.agiletour.com 14
  14. 14. Quelles bonnes pratiques ?Single Responsibility PrincipleOpen-Closed PrincipleLiskov Substitution PrincipleI nterface Segregation PrincipleDependency Inversion Principle www.agiletour.com 15
  15. 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 16
  16. 16. Duplication de code• Règle n°2, selon Kent Beck• DRY : Don’t Repeat Yourself ! Extraction de méthode www.agiletour.com 17
  17. 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 18
  18. 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 19
  19. 19. Couplage fort ATestsIntégrationRéutilisationCorrection de bugsAjout de fonctionsEtc. www.agiletour.com 20
  20. 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 21
  21. 21. Injection de dépendancespublic 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. 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. 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 24
  24. 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 25
  25. 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 26
  26. 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 28
  27. 27. TestsFastI ndependantRepeatableSelf-ValidatingTimely www.agiletour.com 29
  28. 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 30
  29. 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 31
  30. 30. Aller plus loinwww.agiletour.com 32
  31. 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 GoldingPenser que les tests [et le refactoring] ralentissent le développementc’est comme penser que prendre des voyageurs ralentit le busDavid Evans www.agiletour.com 33
  32. 32. MERCI ! @JeromeAvoustinhttp://blog.avoustin.com www.agiletour.com 34
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×