SlideShare une entreprise Scribd logo
1  sur  43
Télécharger pour lire hors ligne
5 façons exemplaires
d’améliorer votre code
Éric De Carufel
Coach Agile

http://blog.decarufel.net
http://pyxis-tech.com
Introduction
• Le code patrimonial est un
  code sans test.
   • Michael Feather dans Working
     effectively with legacy code
• Sans maintenance
  continue, le code se dégrade
  rapidement.
• Il faut savoir détecter et
  enlever le code mort.
Mes 5 meilleures améliorations
     1. Améliorer le code conditionnel
         2. Améliorer la documentation de code
              3. Améliorer les appels de méthode
                   4. Gérer la portée
                        5. Supprimer le code mort
Améliorer le code conditionnel – Pourquoi?
•   Complexité réduite
•   Meilleure lisibilité
•   Meilleure maintenabilité
•   Meilleure réutilisabilité
Améliorer le code conditionnel – Quand?
•   Il y a plus d’une condition (et/ou)
•   Il y a trop de code dans le corps
•   La condition est basée sur le type
•   Il y a des instructions if imbriquées
•   Plusieurs décisions sont basées sur la même info
    (if else if chain / switch case)
Améliorer le code conditionnel – Comment?
• Réusiner les instructions conditionnelles
   •   Décomposer le code conditionnel
   •   Consolider les expressions conditionnelles
   •   Consolider les fragments conditionnels en double
   •   Introduire des objets null
   •   Aplanir les if imbriqués
   •   Ne pas utiliser de conditions négatives
   •   Opter pour de légères instructions conditionnelles
• Éviter les instructions conditionnelles
   • Remplacer le code conditionnel par le polymorphisme
   • Remplacer une logique conditionnelle par une stratégie
   • Remplacer les répartiteurs conditionnels par des commandes
Décomposer le code conditionnel
Consolider les expressions conditionnelles
Consolider les fragments conditionnels en double
Introduire des objets null
Aplanir les if imbriqués
Ne pas utiliser de conditions négatives
Opter pour de légères instructions conditionnelles
• Autant que possible, utiliser une seule condition
   • Utiliser des méthodes pour combiner les conditions
     multiples
• Inverser vos conditions si la plupart (ou la totalité)
  du code de votre méthode est dans le bloc « vrai »
   • Éviter la double négation
Remplacer le conditionnel par le polymorphisme
Remplacer une logique conditionnelle par une stratégie
Remplacer le répartiteur conditionnel par une commande
Améliorer la documentation – Pourquoi?
• Meilleure lisibilité
• Meilleure maintenabilité
• Moins de commentaires obsolètes
Améliorer la documentation – Quand?
• Chaque fois qu’un commentaire ne constitue pas une
  information, une intention, une clarification, un
  avertissement, un TODO ou une amplification (utile)
• Une section de code ne contient que des commentaires
   • Instructions catch vides
• Vos commentaires décrivent ligne par ligne ce que vous
  tentez de faire
   • Exemple :
      // Obtenir la chaîne de connexion de la configuration
      // Ouvrir la connexion
      // Extraire les données
Améliorer la documentation – Comment?
• Remplacer les commentaires par une appellation
  adéquate
  • Extraire les méthodes
  • Utiliser des noms significatifs
• Écrire des commentaires utiles
• Conventions d’appellation (MSDN : Instructions
  relatives aux noms)
  •   Propriétés
  •   Enums (énumérations)
  •   Événements
  •   Méthodes
Extraire les méthodes
Utiliser des noms significatifs
•   Utiliser des noms porteurs d’intention
•   Éviter la désinformation
•   Faire des distinctions significatives
•   Utiliser des noms faciles à prononcer
•   Éviter l’encodage
•   Éviter le mappage mental
•   Nom de classe-> nom plutôt que verbe
•   Nom de méthode -> verbe
•   Éviter l’originalité. Utiliser des noms standards
•   Nom de domaine solution vs nom de domaine problème
Propriétés
• Utiliser le nommage PascalCase
• Identifier les propriétés par un nom, une phrase nominale
  ou un adjectif
• Ne pas utiliser de noms correspondant à la méthode Get
• Identifier les booléens par des préfixes Can, Is ou Has
Enums
• Considérer le premier élément
  comme la valeur par défaut
• Utiliser le nommage PascalCasing
• Les énumérations à choix unique
  devraient être au singulier
• Les énumérations de champs de
  bits devraient être au pluriel et
  avoir un attribut Flags
• La valeur d’une énumération de
  champ de bits doit être cohérente
  (Read & Write == ReadWrite)
Événements
• Utiliser le nommage PascalCase
• Identifier les événements par des verbes − présent (progressif) pour un pré-événement
  et passé pour un post-événement


• Fournir une version virtuelle de l’événement à annuler


• Fournir une façon d’annuler le pré-événement
Méthodes
• Identifier les méthodes par un verbe ou une phrase
  verbale
   • ProcessPayment / TraiterPaiement
• Exprimer la valeur de retour par le nom de la méthode
   • CreateCustomer / CréerClient
   • GetInvoice / ObtenirFacture
• Utiliser une appellation cohérente
  (Get/obtenir, Fetch/extraire et Retrieve/retracer/, mais
  pas tous dans le même contexte)
Améliorer les appels de méthode – Pourquoi?
• Meilleure performance
• Meilleure lisibilité
• Meilleure réutilisabilité
Améliorer les appels de méthode – Quand?
•   Il y a trop de paramètres (définir « trop »)
•   Une méthode fait plus d’une chose
•   Une méthode exploite des paramètres out
•   Vous avez besoin de valeurs par défaut
Améliorer les appels de méthode – Comment?
• Réduire le nombre de paramètres
  • Introduire un objet paramètre
  • Créer des surcharges contenant moins de paramètres
  • Utiliser des valeurs par défaut
• Sortie de fonction
  • Type de valeur de retour
  • Utiliser des paramètres out
• Méthodes de surcharge dans le bon ordre
Introduire un objet paramètre
Créer des surcharges contenant moins de paramètres
Utiliser des valeurs par défaut
Gérer la portée – Pourquoi?
• Éviter les effets secondaires
• Meilleure réutilisabilité
• Meilleure maintenabilité
Gérer la portée – Quand?
• Un champ est utilisé dans quelques méthodes
  seulement
• Les membres publics exposent le comportement
  de la classe
Gérer la portée – Comment?
• Réduire la visibilité
   • Utiliser protected
   • Utiliser private
   • Utiliser Internal
• Réduire la portée
   • Déplacer les champs vers la méthode
   • Fractionner la classe
   • Déplacer la variable locale près de son utilisation
• Réduire la durée de vie
   • Initialiser plus tard
   • Réduire les références
   • Libérer plus tôt
Éliminer le code mort – Pourquoi?
•   Parce que c’est essentiel
•   Meilleure maintenabilité
•   Meilleure performance
•   Meilleure lisibilité
•   Couverture des tests de 100 %
Éliminer le code mort – Quand?
• Vous savez que le code est mort
• Vous croyez que le code est mort
• Vous voulez que le code soit mort
Éliminer le code mort – Comment?
• Identifier et supprimer le code mort
   • Supprimer le code
   • Compiler
   • Effectuer les tests
• Qu’est-ce que le code mort?
   • Code commenté
   • Toute ligne de code non couverte par des tests unitaires
• Outils
   • Certains outils suppriment tout code non couvert par des
     tests unitaires.
Prochaines étapes
• Améliorer votre code conditionnel
• Améliorer votre documentation
• Améliorer vos appels de méthode
Ressources
    •   Refactoring – Improving the design of existing code
         •   Auteur: Martin Fowler
         •   Édition:Addison Wesley
         •   ISBN: 978-0-201-48567-7
    •   Refactoring to patterns (Signature Martin Fowler)
         •   Auteur: Joshua Kerievsky
         •   Édition:AdisonWesley
         •   ISBN: 978-0-321-21335-1
    •   Clean code – a handbook of agile software craftsmanship
         •   Auteur: Robert C. Martin
         •   Édition: PrenticeHall
         •   ISBN: 978-0-132-35088-4
    •   Working effectively with legacy code
         •   Auteur: Michael C. Feather
         •   Édition: PrenticeHall
         •   ISBN: 978-0-13-117705-5
Séances connexes
N’oubliez pas le questionnaire d’évaluation!
Gagnez un appareil Windows Phone 7 Samsung
Focus!
Dites-nous ce que vous avez apprécié et ce qui
laisse à désirer!
1=Médiocre, 5=Excellent 
Exprimez-vous! Faites part de vos commentaires!
Aucun achat requis. Le concours s’adresse à tous les résidents du Canada (à l’exception des employés du gouvernement). Le concours pour l'événement Tech•Days de Toronto débute le
25 octobre 2011 et se termine le 26 octobre 2011; le concours pour l'événement Tech•Days de Vancouver débute le 15 novembre 2011 et se termine le 16 novembre 2011; le concours
pour l'événement Tech•Days de Montréal débute le 29 novembre 2011 et se termine le 30 novembre 2011. Les participants peuvent s’inscrire de deux façons : (1) en remplissant et
soumettant l’évaluation avant la date de clôture du concours; ou (2) en fournissant leurs coordonnées avant la date de clôture du concours. Le tirage de Toronto aura lieu le 31 octobre
2011; le tirage de Vancouver aura lieu le 21 novembre 2011; le tirage de Montréal aura lieu le 5 décembre 2011. Les chances de gagner dépendent du nombre d’inscriptions admissibles.
Les participants sélectionnés seront joints par téléphone ou par courriel et devront répondre correctement dans un délai limité à une question d’habileté. Au total, trois (3) prix seront
attribués pour les trois événements Tech•Days, soit ceux de Toronto (25-26 octobre 2011), Vancouver (15-16 novembre 2011) et Montréal (29-30 novembre 2011). Il y a un (1) prix à
gagner par événement, à savoir un appareil Windows Phone 7 Samsung Focus (téléphone seulement; forfait données et/ou voix non inclus) [valeur au détail approximative de 499 $ CA].
Le prix sera expédié à l'adresse de la personne gagnante dans un délai de 6 à 8 semaines. Le gagnant pourrait devoir signer un formulaire de déclaration et exonération. Pour obtenir le
règlement officiel, adressez-vous à un représentant Microsoft Tech•Days.


            Soumettez vos commentaires directement à
                     td_can@microsoft.com
Questions et réponses
© Microsoft Corporation, 2011. Tous droits réservés. Microsoft, Windows, Windows Vista et d’autres noms de produits sont, ou pourraient être, des marques déposées ou des marques de commerce aux États-Unis et dans d’autres
pays. Les renseignements présentés ici le sont à des fins informatives uniquement, et reposent sur la perspective actuelle de Microsoft Corporation au moment de cette présentation. Parce que Microsoft doit réagir aux conditions
changeantes © 2011 Microsoft Corporation. aucunement être interprété comme un engagement quelconque de la part names are or may ailleurs, Microsoft ne peutand/or trademarks in de quelque renseignement présenté après la
             du marché, le contenu ne doit All rights reserved. Microsoft, Windows, Windows Vista and other product de Microsoft. Par be registered trademarks garantir l’exactitude the U.S. and/or other countries.
 The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should
                                                                                                      date de cette présentation.
                           not be interpreted to beN’ÉMET AUCUNE GARANTIE, EXPRESSE, IMPLICITE OU RÉGLEMENTAIRE, QUANT À L’INFORMATION QUE CONTIENT after the date of this presentation.
                                      MICROSOFT a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided CETTE PRÉSENTATION.
                                                   MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Contenu connexe

Similaire à Top 5 des meilleures façon d'améliorer ton code

[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)Cellenza
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testablemartinsson
 
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?Christophe HERAL
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsThierry Gayet
 
C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?Rémi Lesieur
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1Christophe Rochefolle
 
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
 
Diginova - Session sur le machine learning avec ML.NET
Diginova - Session sur le machine learning avec ML.NETDiginova - Session sur le machine learning avec ML.NET
Diginova - Session sur le machine learning avec ML.NETJulien Chable
 
7 Suivre Les Developpements Et Recetter
7 Suivre Les Developpements Et Recetter7 Suivre Les Developpements Et Recetter
7 Suivre Les Developpements Et RecetterStéphane Bordage
 
20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_allCARA_Lyon
 
Top 5 des meilleures façons d'améliorer votre code
Top 5 des meilleures façons d'améliorer votre codeTop 5 des meilleures façons d'améliorer votre code
Top 5 des meilleures façons d'améliorer votre codeEric De Carufel
 
Wordcamp paris 2015 dev-pragmatique-bonnes-pratiques
Wordcamp paris 2015  dev-pragmatique-bonnes-pratiquesWordcamp paris 2015  dev-pragmatique-bonnes-pratiques
Wordcamp paris 2015 dev-pragmatique-bonnes-pratiquesSylvie Clément
 
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...DC CONSULTANTS
 
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...Normandy JUG
 
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDDWebinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDDDC CONSULTANTS
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)French Scrum User Group
 
M10266 formation-programmation-csharp-avec-microsoft-net-framework-4
M10266 formation-programmation-csharp-avec-microsoft-net-framework-4M10266 formation-programmation-csharp-avec-microsoft-net-framework-4
M10266 formation-programmation-csharp-avec-microsoft-net-framework-4CERTyou Formation
 
Toutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBToutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBContent Square
 

Similaire à Top 5 des meilleures façon d'améliorer ton code (20)

[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
 
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
 
C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
 
Diginova - Session sur le machine learning avec ML.NET
Diginova - Session sur le machine learning avec ML.NETDiginova - Session sur le machine learning avec ML.NET
Diginova - Session sur le machine learning avec ML.NET
 
7 Suivre Les Developpements Et Recetter
7 Suivre Les Developpements Et Recetter7 Suivre Les Developpements Et Recetter
7 Suivre Les Developpements Et Recetter
 
20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all
 
Top 5 des meilleures façons d'améliorer votre code
Top 5 des meilleures façons d'améliorer votre codeTop 5 des meilleures façons d'améliorer votre code
Top 5 des meilleures façons d'améliorer votre code
 
Wordcamp paris 2015 dev-pragmatique-bonnes-pratiques
Wordcamp paris 2015  dev-pragmatique-bonnes-pratiquesWordcamp paris 2015  dev-pragmatique-bonnes-pratiques
Wordcamp paris 2015 dev-pragmatique-bonnes-pratiques
 
Rails 3 au Djangocong
Rails 3 au DjangocongRails 3 au Djangocong
Rails 3 au Djangocong
 
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
 
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
 
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDDWebinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
 
M10266 formation-programmation-csharp-avec-microsoft-net-framework-4
M10266 formation-programmation-csharp-avec-microsoft-net-framework-4M10266 formation-programmation-csharp-avec-microsoft-net-framework-4
M10266 formation-programmation-csharp-avec-microsoft-net-framework-4
 
Toutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBToutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDB
 
Université du soir - TDD
Université du soir - TDDUniversité du soir - TDD
Université du soir - TDD
 

Plus de Eric De Carufel

Bracket Show Episode 35 - histoire de c# de 2002 à 2019
Bracket Show Episode 35 - histoire de c# de 2002 à 2019Bracket Show Episode 35 - histoire de c# de 2002 à 2019
Bracket Show Episode 35 - histoire de c# de 2002 à 2019Eric De Carufel
 
Architecture azure performante
Architecture azure performanteArchitecture azure performante
Architecture azure performanteEric De Carufel
 
Refactoring vers les design patterns pyxis v2
Refactoring vers les design patterns   pyxis v2Refactoring vers les design patterns   pyxis v2
Refactoring vers les design patterns pyxis v2Eric De Carufel
 
Refactoring to Design Patterns
Refactoring to Design PatternsRefactoring to Design Patterns
Refactoring to Design PatternsEric De Carufel
 
Cqrs + event sourcing pyxis v2 - en
Cqrs + event sourcing   pyxis v2 - enCqrs + event sourcing   pyxis v2 - en
Cqrs + event sourcing pyxis v2 - enEric De Carufel
 
Dvcs mercurial - pyxis - eric de carufel
Dvcs   mercurial - pyxis - eric de carufelDvcs   mercurial - pyxis - eric de carufel
Dvcs mercurial - pyxis - eric de carufelEric De Carufel
 

Plus de Eric De Carufel (8)

Bracket Show Episode 35 - histoire de c# de 2002 à 2019
Bracket Show Episode 35 - histoire de c# de 2002 à 2019Bracket Show Episode 35 - histoire de c# de 2002 à 2019
Bracket Show Episode 35 - histoire de c# de 2002 à 2019
 
Gadgteteer clean code
Gadgteteer   clean codeGadgteteer   clean code
Gadgteteer clean code
 
Architecture azure performante
Architecture azure performanteArchitecture azure performante
Architecture azure performante
 
Refactoring vers les design patterns pyxis v2
Refactoring vers les design patterns   pyxis v2Refactoring vers les design patterns   pyxis v2
Refactoring vers les design patterns pyxis v2
 
Refactoring to Design Patterns
Refactoring to Design PatternsRefactoring to Design Patterns
Refactoring to Design Patterns
 
Cqrs + event sourcing pyxis v2 - en
Cqrs + event sourcing   pyxis v2 - enCqrs + event sourcing   pyxis v2 - en
Cqrs + event sourcing pyxis v2 - en
 
CQRS + Event Sourcing
CQRS + Event SourcingCQRS + Event Sourcing
CQRS + Event Sourcing
 
Dvcs mercurial - pyxis - eric de carufel
Dvcs   mercurial - pyxis - eric de carufelDvcs   mercurial - pyxis - eric de carufel
Dvcs mercurial - pyxis - eric de carufel
 

Top 5 des meilleures façon d'améliorer ton code

  • 1. 5 façons exemplaires d’améliorer votre code Éric De Carufel Coach Agile http://blog.decarufel.net http://pyxis-tech.com
  • 2. Introduction • Le code patrimonial est un code sans test. • Michael Feather dans Working effectively with legacy code • Sans maintenance continue, le code se dégrade rapidement. • Il faut savoir détecter et enlever le code mort.
  • 3. Mes 5 meilleures améliorations 1. Améliorer le code conditionnel 2. Améliorer la documentation de code 3. Améliorer les appels de méthode 4. Gérer la portée 5. Supprimer le code mort
  • 4. Améliorer le code conditionnel – Pourquoi? • Complexité réduite • Meilleure lisibilité • Meilleure maintenabilité • Meilleure réutilisabilité
  • 5. Améliorer le code conditionnel – Quand? • Il y a plus d’une condition (et/ou) • Il y a trop de code dans le corps • La condition est basée sur le type • Il y a des instructions if imbriquées • Plusieurs décisions sont basées sur la même info (if else if chain / switch case)
  • 6. Améliorer le code conditionnel – Comment? • Réusiner les instructions conditionnelles • Décomposer le code conditionnel • Consolider les expressions conditionnelles • Consolider les fragments conditionnels en double • Introduire des objets null • Aplanir les if imbriqués • Ne pas utiliser de conditions négatives • Opter pour de légères instructions conditionnelles • Éviter les instructions conditionnelles • Remplacer le code conditionnel par le polymorphisme • Remplacer une logique conditionnelle par une stratégie • Remplacer les répartiteurs conditionnels par des commandes
  • 7. Décomposer le code conditionnel
  • 8. Consolider les expressions conditionnelles
  • 9. Consolider les fragments conditionnels en double
  • 11. Aplanir les if imbriqués
  • 12. Ne pas utiliser de conditions négatives
  • 13. Opter pour de légères instructions conditionnelles • Autant que possible, utiliser une seule condition • Utiliser des méthodes pour combiner les conditions multiples • Inverser vos conditions si la plupart (ou la totalité) du code de votre méthode est dans le bloc « vrai » • Éviter la double négation
  • 14. Remplacer le conditionnel par le polymorphisme
  • 15. Remplacer une logique conditionnelle par une stratégie
  • 16. Remplacer le répartiteur conditionnel par une commande
  • 17. Améliorer la documentation – Pourquoi? • Meilleure lisibilité • Meilleure maintenabilité • Moins de commentaires obsolètes
  • 18. Améliorer la documentation – Quand? • Chaque fois qu’un commentaire ne constitue pas une information, une intention, une clarification, un avertissement, un TODO ou une amplification (utile) • Une section de code ne contient que des commentaires • Instructions catch vides • Vos commentaires décrivent ligne par ligne ce que vous tentez de faire • Exemple : // Obtenir la chaîne de connexion de la configuration // Ouvrir la connexion // Extraire les données
  • 19. Améliorer la documentation – Comment? • Remplacer les commentaires par une appellation adéquate • Extraire les méthodes • Utiliser des noms significatifs • Écrire des commentaires utiles • Conventions d’appellation (MSDN : Instructions relatives aux noms) • Propriétés • Enums (énumérations) • Événements • Méthodes
  • 21. Utiliser des noms significatifs • Utiliser des noms porteurs d’intention • Éviter la désinformation • Faire des distinctions significatives • Utiliser des noms faciles à prononcer • Éviter l’encodage • Éviter le mappage mental • Nom de classe-> nom plutôt que verbe • Nom de méthode -> verbe • Éviter l’originalité. Utiliser des noms standards • Nom de domaine solution vs nom de domaine problème
  • 22. Propriétés • Utiliser le nommage PascalCase • Identifier les propriétés par un nom, une phrase nominale ou un adjectif • Ne pas utiliser de noms correspondant à la méthode Get • Identifier les booléens par des préfixes Can, Is ou Has
  • 23. Enums • Considérer le premier élément comme la valeur par défaut • Utiliser le nommage PascalCasing • Les énumérations à choix unique devraient être au singulier • Les énumérations de champs de bits devraient être au pluriel et avoir un attribut Flags • La valeur d’une énumération de champ de bits doit être cohérente (Read & Write == ReadWrite)
  • 24. Événements • Utiliser le nommage PascalCase • Identifier les événements par des verbes − présent (progressif) pour un pré-événement et passé pour un post-événement • Fournir une version virtuelle de l’événement à annuler • Fournir une façon d’annuler le pré-événement
  • 25. Méthodes • Identifier les méthodes par un verbe ou une phrase verbale • ProcessPayment / TraiterPaiement • Exprimer la valeur de retour par le nom de la méthode • CreateCustomer / CréerClient • GetInvoice / ObtenirFacture • Utiliser une appellation cohérente (Get/obtenir, Fetch/extraire et Retrieve/retracer/, mais pas tous dans le même contexte)
  • 26. Améliorer les appels de méthode – Pourquoi? • Meilleure performance • Meilleure lisibilité • Meilleure réutilisabilité
  • 27. Améliorer les appels de méthode – Quand? • Il y a trop de paramètres (définir « trop ») • Une méthode fait plus d’une chose • Une méthode exploite des paramètres out • Vous avez besoin de valeurs par défaut
  • 28. Améliorer les appels de méthode – Comment? • Réduire le nombre de paramètres • Introduire un objet paramètre • Créer des surcharges contenant moins de paramètres • Utiliser des valeurs par défaut • Sortie de fonction • Type de valeur de retour • Utiliser des paramètres out • Méthodes de surcharge dans le bon ordre
  • 29. Introduire un objet paramètre
  • 30. Créer des surcharges contenant moins de paramètres
  • 31. Utiliser des valeurs par défaut
  • 32. Gérer la portée – Pourquoi? • Éviter les effets secondaires • Meilleure réutilisabilité • Meilleure maintenabilité
  • 33. Gérer la portée – Quand? • Un champ est utilisé dans quelques méthodes seulement • Les membres publics exposent le comportement de la classe
  • 34. Gérer la portée – Comment? • Réduire la visibilité • Utiliser protected • Utiliser private • Utiliser Internal • Réduire la portée • Déplacer les champs vers la méthode • Fractionner la classe • Déplacer la variable locale près de son utilisation • Réduire la durée de vie • Initialiser plus tard • Réduire les références • Libérer plus tôt
  • 35. Éliminer le code mort – Pourquoi? • Parce que c’est essentiel • Meilleure maintenabilité • Meilleure performance • Meilleure lisibilité • Couverture des tests de 100 %
  • 36. Éliminer le code mort – Quand? • Vous savez que le code est mort • Vous croyez que le code est mort • Vous voulez que le code soit mort
  • 37. Éliminer le code mort – Comment? • Identifier et supprimer le code mort • Supprimer le code • Compiler • Effectuer les tests • Qu’est-ce que le code mort? • Code commenté • Toute ligne de code non couverte par des tests unitaires • Outils • Certains outils suppriment tout code non couvert par des tests unitaires.
  • 38. Prochaines étapes • Améliorer votre code conditionnel • Améliorer votre documentation • Améliorer vos appels de méthode
  • 39. Ressources • Refactoring – Improving the design of existing code • Auteur: Martin Fowler • Édition:Addison Wesley • ISBN: 978-0-201-48567-7 • Refactoring to patterns (Signature Martin Fowler) • Auteur: Joshua Kerievsky • Édition:AdisonWesley • ISBN: 978-0-321-21335-1 • Clean code – a handbook of agile software craftsmanship • Auteur: Robert C. Martin • Édition: PrenticeHall • ISBN: 978-0-132-35088-4 • Working effectively with legacy code • Auteur: Michael C. Feather • Édition: PrenticeHall • ISBN: 978-0-13-117705-5
  • 41. N’oubliez pas le questionnaire d’évaluation! Gagnez un appareil Windows Phone 7 Samsung Focus! Dites-nous ce que vous avez apprécié et ce qui laisse à désirer! 1=Médiocre, 5=Excellent  Exprimez-vous! Faites part de vos commentaires! Aucun achat requis. Le concours s’adresse à tous les résidents du Canada (à l’exception des employés du gouvernement). Le concours pour l'événement Tech•Days de Toronto débute le 25 octobre 2011 et se termine le 26 octobre 2011; le concours pour l'événement Tech•Days de Vancouver débute le 15 novembre 2011 et se termine le 16 novembre 2011; le concours pour l'événement Tech•Days de Montréal débute le 29 novembre 2011 et se termine le 30 novembre 2011. Les participants peuvent s’inscrire de deux façons : (1) en remplissant et soumettant l’évaluation avant la date de clôture du concours; ou (2) en fournissant leurs coordonnées avant la date de clôture du concours. Le tirage de Toronto aura lieu le 31 octobre 2011; le tirage de Vancouver aura lieu le 21 novembre 2011; le tirage de Montréal aura lieu le 5 décembre 2011. Les chances de gagner dépendent du nombre d’inscriptions admissibles. Les participants sélectionnés seront joints par téléphone ou par courriel et devront répondre correctement dans un délai limité à une question d’habileté. Au total, trois (3) prix seront attribués pour les trois événements Tech•Days, soit ceux de Toronto (25-26 octobre 2011), Vancouver (15-16 novembre 2011) et Montréal (29-30 novembre 2011). Il y a un (1) prix à gagner par événement, à savoir un appareil Windows Phone 7 Samsung Focus (téléphone seulement; forfait données et/ou voix non inclus) [valeur au détail approximative de 499 $ CA]. Le prix sera expédié à l'adresse de la personne gagnante dans un délai de 6 à 8 semaines. Le gagnant pourrait devoir signer un formulaire de déclaration et exonération. Pour obtenir le règlement officiel, adressez-vous à un représentant Microsoft Tech•Days. Soumettez vos commentaires directement à td_can@microsoft.com
  • 43. © Microsoft Corporation, 2011. Tous droits réservés. Microsoft, Windows, Windows Vista et d’autres noms de produits sont, ou pourraient être, des marques déposées ou des marques de commerce aux États-Unis et dans d’autres pays. Les renseignements présentés ici le sont à des fins informatives uniquement, et reposent sur la perspective actuelle de Microsoft Corporation au moment de cette présentation. Parce que Microsoft doit réagir aux conditions changeantes © 2011 Microsoft Corporation. aucunement être interprété comme un engagement quelconque de la part names are or may ailleurs, Microsoft ne peutand/or trademarks in de quelque renseignement présenté après la du marché, le contenu ne doit All rights reserved. Microsoft, Windows, Windows Vista and other product de Microsoft. Par be registered trademarks garantir l’exactitude the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should date de cette présentation. not be interpreted to beN’ÉMET AUCUNE GARANTIE, EXPRESSE, IMPLICITE OU RÉGLEMENTAIRE, QUANT À L’INFORMATION QUE CONTIENT after the date of this presentation. MICROSOFT a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided CETTE PRÉSENTATION. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.