Studio-Dev.fr - Julien Lafont

“Think once read many.” Arrêtez de redécouvrir ce que vous avez déjà trouvé. Vous devez prendre le temps de rendre votre code lisible une seule fois pour éviter que les autres y consacre du temps à nouveau.

Résumé de la conférence donnée par Eric de Carufel (Pyxis) à l'Agile Tour Québec.

1. Simplifier les conditionnelles

Pourquoi ?

• Réduire la complexité du code
• Améliorer la lisibilité : "Etre capable de lire un code comme une phrase".
• Améliorer la maintenabilité
• Améliorer la ré-utilisabilité : Les conditions métiers se retrouvent souvent dans plusieurs parties du code.

Quand le faire ?

• Lorsque l'on s'approche d'un "code smell" avec plusieurs conditions and/or
• Quand il y a trop de code dans le corps de la condition (quand on ne sait plus où elle commence/finit)
• La condition est basée sur le type (typeof, instance of)
• Plusieurs/Trop de "if" imbriqués
• Plusieurs décisions basées sur la même information

Comment ?

Decomposate conditional

Lorsque la même instruction est effectuée dans chaque branche de la conditionnelle, il faut la sortir.

Introduce Null object

Flatten nested if

Replace conditional with polylmorphism

Autres stratégies :

• Autant que possible, avoir une seule condition
• Inverser le IF si la plupart du code se trouve dans la branche false
• Replace conditional logic with Strategy Pattern

2. Supprimer la documentation

Pourquoi ?

• Améliorer la lisibilité
• Améliorer la maintenabilité
• Eviter les commentaires désuet

	/**
	* Obtenir le client à partir à partir de son id
	*/
	public Client getClientById(Long id) { ... }

Aucune valeur. Avec des gros risques d'avoir des paramètres dans la doc qui n'existent plus.

Quand ?

Chaque fois qu'un commentaire est inutile, qu'il ne décrit pas une intention/un objectif, qu'il ne clarifie rien.

Eviter à tout prix les try/catch avec seulement un commentaire dans le catch.
Eviter également le commentaire décrit ligne par ligne

	// Récupérer la connexion à partir du pool
	// Ouvrir la transaction
	// Insérer les données
	// Comiter et fermer la transaction
	// Gestion de la wtf error
	=> Découper le code !!

Comment ?

Extract method

Découper le code en plusieurs fonctions.

Utiliser des noms significatifs

Eviter les noms généralistes tels que "processCheckout" ou "passerCommande".
Cela signifie validerCommande, calculerCommande ou enregistrerCommande ?

Conseils :

• Nommer une fonction selon son intention
• Eviter la désinformation (ne pas nommer une classe ClientList si elle n'est pas une implémentation de : ArrayList, SortedList ...)
• S'assurer d'avoir une distinction significative entre les noms des différentes méthodes d'une classe
• Utiliser un nom prononçable, éviter les abréviations
• Utiliser un verbe pour décrire une méthode
• Ne soyez pas créatif, utilisez les nom standard (et évitez de mélanger plusieurs langues)

3. Clarifier les contrats

Pourquoi ?

• Améliorer la performance (dans le sens : capacité de développement)
• Améliorer la lisibilité
• Améliorer la réutilisabilité

Qu'est ce qu'un contrat ? Ce qui est visible de l'extérieur (API, Méthode, WebService)

Quand ?

• Il y a trop de paramètres (>2 ? >3 ?)
• Une méthode fait plus d'un chose (un boolean pour changer son comportement par exemple)
• Une méthode utilise des paramètres OUT
• Vous avez besoin de valeurs par défaut

Comment ?

Introduce parameter objects

Create overload with fewer parameters

Créer des implémentations par défaut plus simples avec moins de paramètres.

Use default value

Utiliser des valeurs par défaut sur les arguments.
Impossible en Java... Mais très pratique en C#, PHP ...

4. Réduire le scope

Pourquoi ?

• Réduire les effets de bords
• Améliorer la ré-utilisabilité
• Améliorer la maintenabilité

Quand ?

• Un membre publique expose un comportement interne
• Une classe gère plusieurs responsabilités
• Une classe brise la loi de Déméter : "Ne parlez qu'à vos amis immédiats"

Comment ?

Réfléchir à la visibilité, à la durée de vie ainsi qu'aux responsabilités de vos objets.

5. Réduire le code mort

Pourquoi ? Il n'y a pas à se poser la question !

• Parce qu'il le faut
• Pour améliorer la maintenabilité
• Pour améliorer la performance
• Pour améliorer la lisibilité
• 100% de couverture de test

Quand ?

• Vous savez que le code est mort
• Vous pensez que le code est mort
• Vous voulez que le code soit mort !

Comment ?

• Identifiez et retirez le code mort
  - Effacer le code
  - Compilez
  - Déroulez les tests
• Qu'est ce que du code mort ?
  - Du code en commentaire
  ou
  - Toutes lignes de code non couverte par un test unitaire
• Utiliser des outils adaptés (Cobertura pour Hudson)