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

Agilité, AMOA, .NET, SharePoint
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é

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

www.agiletour.com 6

Pourquoi la Qualité ?

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

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

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


Quelles horreurs dans le code ?

Singleton
Tight coupling
Untestable
Premature optimization
I ndescriptive naming
Duplication

Quelles bonnes pratiques ?

SOLID YAGNI

DRY SoC
GRASP
KISS Loi de Demeter

Quelles bonnes pratiques ?

Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
I nterface Segregation Principle
Dependency 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

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


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

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

Fast
I ndependant
Repeatable
Self-Validating
Timely

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


MERCI !
@JeromeAvoustin

http://blog.avoustin.com


AgileTour Toulouse 2012 : clean code en pratique

Contenu connexe

En vedette (20)

Similaire à AgileTour Toulouse 2012 : clean code en pratique (20)

Plus de Agile Toulouse (20)

AgileTour Toulouse 2012 : clean code en pratique