Formation
Clean Code
Session 1
sylvain.leroy@tocea.com 17-jan-2014
2
Présentation des intervenants
Sylvain Leroy
C'est moi 
Directeur technique et co-
fondateur de la société
Tocea
Conseil ...
3
Présentation des intervenants
Jérémie Guidoux
Architecte, formateur et
cofondateur de la société
Tocea
Architecte Java/J...
4
Présentation de la formation
Formation Clean Code :
« Comment écrire un code propre »
Principes
+ Bonnes pratiques
+ Exe...
5
Organisation de la formation
5 Séances
Toutes les 3 semaines
2 équipes
6
Contenu de la formation
5 Séances
Toutes les 3 semaines
2 équipes
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 ...
8
Modules de la formation
Journée 1 : CleanCode
Qu'est ce qu'un code propre
Module 1 / Nommage des identifiants
Module 2 /...
9
Modules de la formation
Journée 3 : Construire une
application propre
Module 8 / Design d'une fonctionnalité
Module 9 / ...
10
Quelques mots sur la formation
Les exemples sont basés sur le langage Java et la
programmation Objet
Je vais enfoncer p...
Réponses
Au
QCM
sylvain.leroy@tocea.com 17-jan-2014
Pourquoi
Avoir un code propre ?
sylvain.leroy@tocea.com 17-jan-2014
13
Avant-propos : Clean code
14
Motivations
Vous êtes un développeur
Vous voulez être un meilleur
développeur (et reconnu)
(Acquérir des XP)
15
Objectifs
Connaître et partager des bonnes pratiques simples à
mettre en oeuvre
Offrir un point de vue critique et argu...
16
Game of books
17
Qu'est ce qu'un bon code ?
Apportez vos définitions !
18
Qu'est ce qu'un mauvais code ?
Apportez vos définitions !
19
La méthode empirique pour détecter du
mauvais code :
20
La méthode des chefs pour mesurer un
mauvais code
21
La dette technique, qu'est ce que c'est ?
Métaphore qui a été créée pour illustrer les potentiels
impacts d'une mauvais...
22
La dette technique, qu'est ce que c'est ?
Comment la mesurer ?
Nombre de violations * Temps de correction pour chaque 
...
23
Code propre, dette technique, qui est
responsable ?
Pressions du business
Manque de process ou de compréhension
Dévelop...
24
Prenons nos responsabilités et évitons de créer
par nos actions, de la dette technique !
25
Qu'est ce les développeurs y gagnent ?
Valorisez votre travail
Valorisez vos compétences
Travaillez dans un environneme...
Avant-propos
La déclaration des
droits de codage des
développeurs
sylvain.leroy@tocea.com 17-jan-2014
27
Déclaration des droits des développeurs
Suivez les conventions et normes de
programmation
Gardez votre code simple, stu...
28
Prochain SlideShare
Chargement dans…5
×

Cleancode / Tocea / Introduction

595 vues

Publié le

Formation sur les principes Cleancode / Software Quality Control

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Cleancode / Tocea / Introduction

  1. 1. Formation Clean Code Session 1 sylvain.leroy@tocea.com 17-jan-2014
  2. 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. 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. 4 Présentation de la formation Formation Clean Code : « Comment écrire un code propre » Principes + Bonnes pratiques + Exercices
  5. 5. 5 Organisation de la formation 5 Séances Toutes les 3 semaines 2 équipes
  6. 6. 6 Contenu de la formation 5 Séances Toutes les 3 semaines 2 équipes
  7. 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. 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. 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. 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. 11. Réponses Au QCM sylvain.leroy@tocea.com 17-jan-2014
  12. 12. Pourquoi Avoir un code propre ? sylvain.leroy@tocea.com 17-jan-2014
  13. 13. 13 Avant-propos : Clean code
  14. 14. 14 Motivations Vous êtes un développeur Vous voulez être un meilleur développeur (et reconnu) (Acquérir des XP)
  15. 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. 16 Game of books
  17. 17. 17 Qu'est ce qu'un bon code ? Apportez vos définitions !
  18. 18. 18 Qu'est ce qu'un mauvais code ? Apportez vos définitions !
  19. 19. 19 La méthode empirique pour détecter du mauvais code :
  20. 20. 20 La méthode des chefs pour mesurer un mauvais code
  21. 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. 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. 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. 24 Prenons nos responsabilités et évitons de créer par nos actions, de la dette technique !
  25. 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. 26. Avant-propos La déclaration des droits de codage des développeurs sylvain.leroy@tocea.com 17-jan-2014
  27. 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. 28

×