Approches autour de l'analyse de code pour améliorer la qualité des projets
Sont abordés :
- Le pair programming
- L'analyse statique
- L'audit de code
La session passe en revue les avantages et points d'attention de chaque approche, ainsi que les outils couramment utilisés. Le tout se basera également sur un retour d'expérience (équipe de 15 devs Java) avec un focus sur la piste que nous avons privilégiée : Phabricator (audit de code)
28. 2828
• Excellente réception générale
• Bugs sur développements en cours en baisse
• Introduction de regressions en baisse
• Dette technique en baisse
Les débuts
29. 2929
• Excellente réception générale
• Bugs sur développements en cours en baisse
• Introduction de regressions en baisse
• Dette technique en baisse
• Qualité des livraisons en hausse
Les débuts
30. 3030
• Excellente réception générale
• Bugs sur développements en cours en baisse
• Introduction de regressions en baisse
• Dette technique en baisse
• Qualité des livraisons en hausse
• Plus de partage de la connaissance
• Montée en expertise et compétence plus rapide
Les débuts
31. 3131
• Excellente réception générale
• Bugs sur développements en cours en baisse
• Introduction de regressions en baisse
• Dette technique en baisse
• Qualité des livraisons en hausse
• Plus de partage de la connaissance
• Montée en expertise et compétence plus rapide
• Meilleure maitrise du changement
Les débuts
Sondage sur qui fait de l’analyse, de la programmation en binome, de l’audit de code
Comment livrer à temps sans compromettre la qualité ?
Il manque un truc
La vitesse et les changements de priorités font faire des erreurs supplémentaires (pas de recul)
Il n’y a plus assez de pair programming pour voir tous les soucis
L’analyse statique ne détecte pas tout
Il manque un truc
La vitesse et les changements de priorités font faire des erreurs supplémentaires (pas de recul)
Il n’y a plus assez de pair programming pour voir tous les soucis
L’analyse statique ne détecte pas tout
Il manque un truc
La vitesse et les changements de priorités font faire des erreurs supplémentaires (pas de recul)
Il n’y a plus assez de pair programming pour voir tous les soucis
L’analyse statique ne détecte pas tout
Il manque un truc
La vitesse et les changements de priorités font faire des erreurs supplémentaires (pas de recul)
Il n’y a plus assez de pair programming pour voir tous les soucis
L’analyse statique ne détecte pas tout
Rien ne remplace les yeux des développeurs !
On a décidé de faire de l’audit de code
Permet de voir et valider (ou commenter) les changements commit par commit
Bloquant (Gerrit, pull request) ou non bloquant (Phabricator)
Rien ne remplace les yeux des développeurs !
On a décidé de faire de l’audit de code
Permet de voir et valider (ou commenter) les changements commit par commit
Bloquant (Gerrit, pull request) ou non bloquant (Phabricator)
Rien ne remplace les yeux des développeurs !
On a décidé de faire de l’audit de code
Permet de voir et valider (ou commenter) les changements commit par commit
Bloquant (pull request, Gerrit) ou non bloquant (Phabricator)
Mise en place immédiate pour avoir un retour d’experience rapide et ajuster
Petite équipe (8 personnes)
Tout le monde peut auditer tout le monde
Un ou deux garants
Mise en place immédiate pour avoir un retour d’experience rapide et ajuster
Petite équipe (8 personnes)
Tout le monde peut auditer tout le monde
Un ou deux garants
Mise en place immédiate pour avoir un retour d’experience rapide et ajuster
Petite équipe (8 personnes)
Tout le monde peut auditer tout le monde
Un ou deux garants
Mise en place immédiate pour avoir un retour d’experience rapide et ajuster
Petite équipe (8 personnes)
Tout le monde peut auditer tout le monde
Un ou deux garants
Peut devenir chronophage
Gérer la perception de l’outil hors équipe
Eviter les conflits et débats sur l’utilité
Rendre l’outil moins intrusif
Peut devenir chronophage
Gérer la perception de l’outil hors équipe
Eviter les conflits et débats sur l’utilité
Rendre l’outil moins intrusif
Peut devenir chronophage
Gérer la perception de l’outil hors équipe
Eviter les conflits et débats sur l’utilité
Rendre l’outil moins intrusif
Petite équipe (8 personnes)
Tout le monde peut auditer tout le monde
Un ou deux garants
Petite équipe (8 personnes)
Tout le monde peut auditer tout le monde
Un ou deux garants
Petite équipe (8 personnes)
Tout le monde peut auditer tout le monde
Un ou deux garants
Petite équipe (8 personnes)
Tout le monde peut auditer tout le monde
Un ou deux garants
Nécessité de “règles de développement”
Sensibilisation sur les objectifs de l’audit
Ordre / Suggestion ou discussion
Développeur / Développement
Nécessité de “règles de développement”
Sensibilisation sur les objectifs de l’audit
Ordre / Suggestion ou discussion
Développeur / Développement
Nécessité de “règles de développement”
Sensibilisation sur les objectifs de l’audit
Ordre / Suggestion ou discussion
Développeur / Développement
Attention à la noyade
Équipes plus grandes
Organisation par sous équipes (5 personnes max)
Un garant pour 3 – 4 sous équipes
Surveillance du clanisme
Attention à la noyade
Équipes plus grandes
Organisation par sous équipes (5 personnes max)
Un garant pour 3 – 4 sous équipes
Surveillance du clanisme
Attention à la noyade
Équipes plus grandes
Organisation par sous équipes (5 personnes max)
Un garant pour 3 – 4 sous équipes
Surveillance du clanisme
Attention à la noyade
Équipes plus grandes
Organisation par sous équipes (5 personnes max)
Un garant pour 3 – 4 sous équipes
Surveillance du clanisme