Formation sur les principes Cleancode / Software Quality Control

1. Formation
Clean Code
Session 1
sylvain.leroy@tocea.com 17-jan-2014

2. 2
Présentation des intervenants
Sylvain Leroy
C'est moi
Directeur technique et co-
fondateur de la société
Tocea
Conseil en
industrialisation des
développements et
accompagnent les
entreprises dans les
chantiers de migration
automatisés
7 ans dans le domaine
sylvain.leroy@tocea.com

3. 3
Présentation des intervenants
Jérémie Guidoux
Architecte, formateur et
cofondateur de la société
Tocea
Architecte Java/JEE,
middleware, SOA
Féru des technologies
autour de la qualité de
code et des tests
A travaillé chez un éditeur
et dans un laboratoire de
recherche
Diplôme d'Ingénieur
Jeremie.guidoux@tocea.com

4. 4
Présentation de la formation
Formation Clean Code :
« Comment écrire un code propre »
Principes
+ Bonnes pratiques
+ Exercices

5. 5
Organisation de la formation
5 Séances
Toutes les 3 semaines
2 équipes

6. 6
Contenu de la formation
5 Séances
Toutes les 3 semaines
2 équipes

7. 7
Organisation de la journée
Matin Après midi
Réponse au QCM Module 2 / Les méthodes
Qu'est ce qu'un code propre ? Module 3 / Les commentaires

8. 8
Modules de la formation
Journée 1 : CleanCode
Qu'est ce qu'un code propre
Module 1 / Nommage des identifiants
Module 2 / Les méthodes et le code
Module 3 / Les commentaires
Journée 2 : Programmation objet propre
Module 4 / Le formattage
Module 5 / Objets et structures de données
Module 6 / Métriques orientées objets
Module 7 / Gestion des erreurs et des
exceptions

9. 9
Modules de la formation
Journée 3 : Construire une
application propre
Module 8 / Design d'une fonctionnalité
Module 9 / Analyse de l'architecture
d'une application Java
Module 10 / Technologies externes et
licences
Journée 5 : Reprendre un code existant
(legacy)
Module 13 / Faire un plan d'actions
d'amélioration d'une application
Module 14 / Se préparer à reprendre une
nouvelle application / audit
Journée 4 : Industrialiser le
développement d'une application
Module 11 / Tester son code
Module 12 / Build / Test / Run /
Qualimetry / Deploy

10. 10
Quelques mots sur la formation
Les exemples sont basés sur le langage Java et la
programmation Objet
Je vais enfoncer parfois quelques portes ouvertes
Il peut avoir un peu de frustration
Plusieurs fois, je proposerai de vous mettre à la place du
reviewer
Certains exercices ne pourront être terminés dans la session
Pas de panique ! Je répondrai aux questions hors-séance

11. Réponses
Au
QCM
sylvain.leroy@tocea.com 17-jan-2014

12. Pourquoi
Avoir un code propre ?
sylvain.leroy@tocea.com 17-jan-2014

13. 13
Avant-propos : Clean code

14. 14
Motivations
Vous êtes un développeur
Vous voulez être un meilleur
développeur (et reconnu)
(Acquérir des XP)

15. 15
Objectifs
Connaître et partager des bonnes pratiques simples à
mettre en oeuvre
Offrir un point de vue critique et argumenté
Utile dans le cadre de pair-programming et de reviews
Ne pas être effrayé des outils destinés à vous aider
Ils ne peuvent pas vous remplacer, Skynet n'est pas encore en place
Avoir du recul sur un système legacy et prioritiser les
travaux d'amélioration
●

16. 16
Game of books

17. 17
Qu'est ce qu'un bon code ?
Apportez vos définitions !

18. 18
Qu'est ce qu'un mauvais code ?
Apportez vos définitions !

19. 19
La méthode empirique pour détecter du
mauvais code :

20. 20
La méthode des chefs pour mesurer un
mauvais code

21. 21
La dette technique, qu'est ce que c'est ?
Métaphore qui a été créée pour illustrer les potentiels
impacts d'une mauvaise architecture, un mauvais
développement
La dette technique peut être vu comme le travail
initial, obligatoire nécessaire pour réaliser le
développement fonctionnel (= valeur ajoutée)
1. D'après Wikipedia, plus de détails sur techdebt.org

22. 22
La dette technique, qu'est ce que c'est ?
Comment la mesurer ?
Nombre de violations * Temps de correction pour chaque
type de correction = temps de correction
Temps dépendant de l'effort nécessaire à remettre les
métriques en « vert »

23. 23
Code propre, dette technique, qui est
responsable ?
Pressions du business
Manque de process ou de compréhension
Développement en parallèle / isolation
Manque de flexibilité et d'agilité dans le produit
Manque de jeux de tests
Manque de documentation
Manque de collaboration
Refactoring retardé
Manque de connaissances en développement
Quand le développeur ne sait tout simplement pas comment
écrire un code élégant

24. 24
Prenons nos responsabilités et évitons de créer
par nos actions, de la dette technique !

25. 25
Qu'est ce les développeurs y gagnent ?
Valorisez votre travail
Valorisez vos compétences
Travaillez dans un environnement
(l'application) non stressant
Conservez une application moderne
Participez à des développements
intéressants et challengings
Attirez et formez les nouveaux talents
Développez et corrigez moins votre code par la
suite
Valorisez votre expérience,
améliorez le travail d'équipe

26. Avant-propos
La déclaration des
droits de codage des
développeurs
sylvain.leroy@tocea.com 17-jan-2014

27. 27
Déclaration des droits des développeurs
Suivez les conventions et normes de
programmation
Gardez votre code simple, stupide
Keep it simple, stupid (KISS)
La règle du boy-scout
Laissez le campement toujours
plus propre que vous ne l'avez
trouvé
Ne vous répétez pas vous même
(DRY)
Vous êtes un humain, pas une
machine, ne vous abaissez pas
Corrigez toujours les racines du
mal pas les symptômes (Root cause
analysis)
Parce que l'application s'approche
plus vite de sa fin de vie. (vit sous
perfusion)

28. 28