agiletour toulouse 2012 : clean code en pratique

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 3

Agenda

• Pourquoi ?

• Qu’est ce qu’un Code Clean ?

• Les mauvaises pratiques

• Les bonnes pratiques

www.agiletour.com 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

Agile et Qualité

www.agiletour.com 6

Continuous attention to technical excellence

and good design enhances agility.

9e principe du Manifeste Agile

Pourquoi la Qualité ?

www.agiletour.com 7

Responding to change over following a plan

3e valeur du Manifeste Agile

Une vue de la Qualité

www.agiletour.com 8

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 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

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

Quelles horreurs dans le code ?


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 ?


S T U P I

D

ingleton ight coupling ntestable remature optimization ndescriptive naming uplication

Quelles bonnes pratiques ?


SOLID

DRY

YAGNI

KISS

GRASP SoC

Loi de Demeter

Quelles bonnes pratiques ?


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


Duplication de code

• Règle n°2, selon Kent Beck

• DRY : Don’t Repeat Yourself !


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 »


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


Couplage fort

Tests

Intégration

Réutilisation

Correction de bugs

Ajout de fonctions

Etc.


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


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 !


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.


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


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 !


Tests


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


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 !


Aller plus loin


Pour finir…


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 !


@JeromeAvoustin

http://blog.avoustin.com

agiletour toulouse 2012 : clean code en pratique

Documents