Le document présente des principes et pratiques de codage propre, soulignant l'importance de la qualité du code pour s'adapter aux changements tout en maintenant des coûts raisonnables. Il aborde les mauvaises pratiques (code smells) et les bonnes pratiques (SOLID, DRY, KISS) indispensables pour écrire un code lisible et maintenable. Enfin, il insiste sur l'importance des tests, du polymorphisme et de l'injection de dépendances pour améliorer la structure et la clarté du code.

1. Clean Code en pratique
Jérôme Avoustin
www.agiletour.com 1

3. Jérôme Avoustin
.NET, Agilité, Performance
@JeromeAvoustin
Agilité, AMOA, .NET, SharePoint
http://blog.avoustin.com
http://www.smartview.fr
www.agiletour.com 3

4. Agenda
• Pourquoi ?
• Qu’est ce qu’un Code Clean ?
• Les mauvaises pratiques
• Les bonnes pratiques
www.agiletour.com 4

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

6. Agile et Qualité
Continuous attention to technical excellence
and good design enhances agility.
9e principe du Manifeste Agile
www.agiletour.com 6

7. Pourquoi la Qualité ?
Responding to change over following a plan
3e valeur du Manifeste Agile
www.agiletour.com 7

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

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

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

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

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

13. Quelles horreurs dans le code ?
Singleton
Tight coupling
Untestable
Premature optimization
I ndescriptive naming
Duplication
www.agiletour.com 13

14. Quelles bonnes pratiques ?
SOLID YAGNI
DRY SoC
GRASP
KISS Loi de Demeter
www.agiletour.com 14

15. Quelles bonnes pratiques ?
Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
I nterface Segregation Principle
Dependency Inversion Principle
www.agiletour.com 15

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

17. Duplication de code
• Règle n°2, selon Kent Beck
• DRY : Don’t Repeat Yourself !
Extraction de méthode
www.agiletour.com 17

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

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

20. Couplage fort
A
Tests
Intégration
Réutilisation
Correction de bugs
Ajout de fonctions
Etc.
www.agiletour.com 20

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

22. 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();
}
}

23. 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();
}
}

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

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

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

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 28

28. Tests
Fast
I ndependant
Repeatable
Self-Validating
Timely
www.agiletour.com 29

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 30

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 31

31. Aller plus loin
www.agiletour.com 32

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

33. MERCI !
@JeromeAvoustin
http://blog.avoustin.com
www.agiletour.com 34