Cleancode / Tocea / Introduction

381 vues

Publié le

Formation sur les principes Cleancode / Software Quality Control

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
381
Sur SlideShare
0
Issues des intégrations
0
Intégrations
15
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

×