clean code en pratique
DESCRIPTION
Slides de la conférence du même nom donnée aux Agile Tour Marseille et BordeauxTRANSCRIPT
Clean Code en pratique
Jérôme Avoustin
www.agiletour.com 1
Jérôme Avoustin .NET, Agilité, Performance
Agilité, AMOA, .NET, SharePoint
@JeromeAvoustin
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é
www.agiletour.com 5
Continuous attention to technical excellence
and good design enhances agility.
9e principe du Manifeste Agile
Pourquoi la Qualité ?
www.agiletour.com 6
Responding to change over following a plan
3e valeur du Manifeste Agile
Une vue de la Qualité
www.agiletour.com 7
Coût
Temps
Coût
Temps
Une application informatique est de qualité lorsque le coût d’ajout d’une fonctionnalité reste stable.
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…
www.agiletour.com 10
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
Quelles horreurs dans le code ?
www.agiletour.com 11
Code Smells
Comments
Long method
Duplicated code
Conditional complexity
Large class
Type embedded in name Uncommunicative name
Inconsistent names
Dead code Primitive obsession
Data clumps
Long parameter list Temporary field
Alternative classes with different interfaces
Feature envy
Message chain
Shotgun Surgery
Divergent change
Parallel inheritance hierarchies
Lazy class
Speculative generality
Middle man
Inappropriate intimacy
Data class Refused bequest
Wrong level of abstraction
Quelles horreurs dans le code ?
www.agiletour.com 12
S T U P I
D
ingleton ight coupling ntestable remature optimization ndescriptive naming uplication
Quelles bonnes pratiques ?
www.agiletour.com 13
SOLID
DRY
YAGNI
KISS
GRASP SoC
Loi de Demeter
Quelles bonnes pratiques ?
www.agiletour.com 14
S O L I
D
ingle Responsibility Principle pen-Closed Principle iskov Substitution Principle nterface Segregation Principle ependency Inversion Principle
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 !
www.agiletour.com 16
Extraction de méthode
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 »
www.agiletour.com 17
a.getB().getC().doSomething() a.doSomething()
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
Tests
Intégration
Réutilisation
Correction de bugs
Ajout de fonctions
Etc.
www.agiletour.com 19
A
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 { private B b; public void ExecuteA(int a) { b = new B(); C c = new C(); if (a != 3) b.ExecuteB(); else c.ExecuteC(); } }
A collabore avec B et C
On crée un couplage fort entre A et B/C !!
On va injecter B et C !
Injection de dépendances
• Comment injecter B et C ?
o Par constructeur
o Par setter
• Late binding
o Reflection
public class A { private B b; private C c; public A(B b) { this.b = b; } public void setC(C c) { this.c = c; } public void ExecuteA() { int a = 1; b = new B(); C c = new C(); if (a != 3) b.ExecuteB(); else C.ExecuteC(); }
static Main (string[] args) { B b = new B(); A a = new A(b); a.setC(new C1()); a.ExecuteA(); a.setC(new C1()); a.ExecuteA(); }
En bleu, peut être délégué à une Factory : ce sont
les Conteneurs d’IoC
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
www.agiletour.com 28
F I R S T
ast ndependant epeatable elf-Validating imely
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…
www.agiletour.com 32
Codez toujours en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse.
Martin Golding
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler
Pour finir…
www.agiletour.com 33
Codez toujours en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse.
Martin Golding
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler
Penser que les tests [et le refactoring] ralentissent le développement c’est comme penser que prendre des voyageurs ralentit le bus David Evans
MERCI !
www.agiletour.com 34
@JeromeAvoustin
http://blog.avoustin.com