David Beaumier

• Pourquoi parler de pratiques

• Les pratiques

• Cas vécu: résultats

• Répondre à vos questions

• Dans le domaine des TI depuis 1994

• Pratique le développement Agile depuis 2003

• Conseiller chez Elapse Technologies

• MCAD + Certified ScrumMaster

• Accompagne les équipes dans la mise en place des bonnes pratiques de développement durant les projets

• L’état actuel de notre industrie• Malheureusement encore « artisanal »• Niveau de maturité inégal

• Qualité logicielle encore déficiente• Selon le Standish Group:

• Ratio de 3:1 des bogues logiciels vs matériel• Cause de 55% des pannes de systèmes• 300 milliards de pertes annuellement

• Échecs de projets Agile• Scrum en particulier

• Avoir des normes et conventions communes

• Pourquoi c’est important• Assurer une uniformité dans le code

• Permettre à tous de le lire et le comprendre

• Faciliter l’arrivée de nouvelles personnes

• Comment s’y prendre• Choisir et respecter une convention

• S’assurer du respect de cette convention

« Paul est absent, on devra attendre son retour pour finir le correctif »

• Permettre à tous de modifier le code• Répartir la connaissances dans toute l’équipe• Moyens

• Effectuer une rotation des les assignations• Revue de code et discussions• Travailler en équipe à la résolution des problèmes

• 2 personnes 1 ordi (1 clavier, 1 souris)• Alternance entre rôle stratégique et tactique• Pourquoi faire?

• 2 têtes valent mieux qu’une: conception améliorée• Revue instantanée de tout le code écrit

• Ça demeure un pratique controversée• Payer deux personnes pour le même travail?

• “Ce qui est complexe en programmation ce n’est pas de taper le code”

• Changement des habitudes de travail

• Suggestion: appliquer l’esprit et non la lettre

• Aussi souvent que possible• Lors de la conception, de refactorisation

• Lorsque vous êtes bloqué -> immédiatement!

• Mais laissez-vous souffler un peu!

• Essentiel: franchise et respect

• État de la situation• Une bonne pratique de génie logiciel• Encore peu systématisé dans les équipes• Souvent escamoté

• Qu’est-ce qu’un test unitaire?• Tester une petite partie de code

indépendamment des autres• S’assurer de la conformité des résultats en toutes

circonstances

1. Valeurs positives -> vérifier résultat = largeur x longueur2. Valeurs de 0 -> résultat = 03. Valeurs négatives -> retourne erreur4. Combinaisons des conditions précédentes

Supposons la fonction (simple)CalculerAire(largeur, longueur) As Double

larg

eu

r

longueur

Combien de tests sont nécessaires?

• « Ça marche seulement pour les cas simples! »

• « C’est vrai… »

• Justement… On recherche des implémentations simples!!!

Solution = ensemble de simplicités

• TDD: « Test-Driven Development »• En français: Développement piloté par les tests

• TDD est un cadre de travail• Emphase sur la conception• Comprendre ce qu’on doit faire avant de coder• Valorise le travail de qualité

• Conception pilotée par les tests

Réflexion

Programmer

le testProgrammer

l’implémentation

• Meilleure conception• Couplage faible

• Cohésion élevée

• Documentation toujours à jour

• Patrimoine de cas d’essais important• Maintenance et évolution facilitées

• Filet de sureté essentiel pour l’équipe

• Réduit les anomalies de régression

• Qu’est-ce que l’intégration?• C’est le processus par lequel un ensemble de

modifications au code est mise en commun

• Pourquoi continuellement?• Vérifier l’impact de chaque modification au code

source

• S’assurer de ne pas produire de régression

• Feedback immédiat en cas de problème

• Facilité d’identifier ce qui cause le problème

Compilation

Exécution des tests

Référentiel de sources

OUPS ! On corrige

Logiciel fonctionnel

La chose la plus simple qui marche!

• Objectifs• Une solution simple qui répond au besoin

• Code facile à comprendre et à maintenir

• Moyens• Éliminer le réflexe du BDUF

• Faire ce qui est nécessaire maintenant

• Réfléchir, consulter, discuter

C’est beaucoup plus difficile qu’il n’y paraît!

• Éviter les « tant qu’à y être » (YAGNI)

• S’en tenir aux choses simples (KISS)

• Éviter la duplication (DRY)

• Code doit être explicite et clair• Oublions les commentaires

• Le code lui-même doit être clair

• Vous appliquez toutes ces pratiques

• Que va-t-il arriver au code?

• Quelle sera la productivité de l’équipe?

• Constat: le code a besoin de soins

• Sinon: dette technique

Temps

Co

ût

de

dév

elo

pp

eme

nt

Hors contrôle

Mis

e a

u r

anca

rt

Du

rée

de

vie

pré

vue

Perte $$$Élevés

Bas

Gain de productivité

• Aussi appelé «Refactoring »

• Qu’est-ce que c’est?• Modifier la structure du code (conception) sans

altérer le fonctionnement du système

• Pourquoi?• Ne pas sacrifier l’excellence technique à

l’évolution

• Parfaire constamment le code

Recette1. Identifier le(s) changement(s) à réaliser

2. Faire une modification ciblée

3. Rouler les tests unitaires• Identifier et corriger les problèmes

4. Appliquer la modification, si elle fonctionne

5. Recommencer

En faire souvent pour devenir à l’aise

• Changement ≠ amelioration• Comment s’assurer que l’on s’en va à la

bonne place?• Mesurer, mais quoi?• Exemples

• Évaluer le respect des standards et conventions• Analyser la complexité du code• Résultats des essais (unitaires, acceptation)

• Intégrer au processus de build

Contexte de l’intervention• Difficulté à livrer de la valeur d’affaires

• Produit livrée de faible qualité

Situation• Code patrimonial hérité de projets antérieurs

• Effort d’architecture plus récent, mais sans modifier les pratiques

• Initiative de revoir les pratiques et mesurer l’impact

Concepts simples, mais rigueur requise!

Plan de match

• Identifiez vos leaders positifs (champions)

• Introduisez les pratiques successivement

• Allouez du temps à l’équipe pour apprendre

• Mesurez les impacts des changements

Défi: compétences en conception OO

N’hésitez pas à aller chercher de l’aide

Scrum Developer Training (Scrum.org)