2. • Pourquoi parler de pratiques
• Les pratiques
• Cas vécu: résultats
• Répondre à vos questions
3. • 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
4.
5. • 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
6.
7. • 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
8. « 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
9. • 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
10. • 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
11. • É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
12. longueur
largeur
Supposons la fonction (simple)
CalculerAire(largeur, longueur) As Double
Combien de tests sont nécessaires?
1. Valeurs positives -> vérifier résultat = largeur x longueur
2. Valeurs de 0 -> résultat = 0
3. Valeurs négatives -> retourne erreur
4. Combinaisons des conditions précédentes
13. • « Ça marche seulement pour les cas
simples! »
• « C’est vrai… »
• Justement… On recherche des
implémentations simples!!!
Solution = ensemble de simplicités
14. • 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
15. Réflexion
Programmer Programmer
le test l’implémentation
16. • 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
17. • 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
18. Référentiel
de sources
Compilation
OUPS ! Exécution
des tests Logiciel
On corrige fonctionnel
19. 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!
20. • É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
21. • 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
22. Coût de développement
Bas
Élevés
Temps
Hors contrôle
Mise au rancart
Perte $$$
Durée de vie prévue
24. • 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
25. Recette
1. 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
26. • 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
27.
28. 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
29.
30. 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
