5 façons exemplaires d’améliorer votre codeÉric De CarufelCoach Agile

http://blog.decarufel.nethttp://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.

Réduire la hiérarchie de classe

s

Augmenter la collaboration des classes

Réduire le couplage

Augmenter la cohésion

Utiliser un niveau d’abstraction par méthode

Recourir à l’architecture en couches

Extraire les enjeux transversaux

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

Mes 5 meilleures améliorations

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// Fermer la connexion

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 para

mè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 : Adison Wesley• ISBN : 978-0-321-21335-1

• Clean code – a handbook of agile software craftsmanship• Auteur : Robert C. Martin• Édition : Prentice Hall• ISBN : 978-0-132-35088-4

• Working effectively with legacy code• Auteur : Michael C. Feather• Édition : Prentice Hall• 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

© 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in 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 not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this

presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

© 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 du marché, le contenu ne doit aucunement être interprété comme un engagement quelconque de la part de Microsoft. Par

ailleurs, Microsoft ne peut garantir l’exactitude de quelque renseignement présenté après la date de cette présentation. MICROSOFT N’ÉMET AUCUNE GARANTIE, EXPRESSE, IMPLICITE OU RÉGLEMENTAIRE, QUANT À L’INFORMATION QUE CONTIENT CETTE PRÉSENTATION.