Android et qualité logicielle

Lightning Talk

Découvrons en 5 minutes les pistes principales à suivre pour estimer la qualité d'une application mobile Android.

Michaël Ohayon, Développeur Android

Transcript

1. Android et qualité logicielle
2. Qui suis-je ? OHAYON MICHAËL Consultant Android @mikkL Xebian depuis 3 ans
3. Application Mobile • Utile • Fiable • Simple • Rapide • Esthétique Votre marque, au quotidien chez vos utilisateurs
4. Qualité logicielle • Bugs / Failles • Volumétrie • Poids • Performance • Complexité de développement • Complexité de livraison L'indicateur de performance, stabilité et maintenabilité de votre code
5. Pourquoi est-ce important ? • Régressions • Bugs • Identification des problèmes • Ajout de nouvelles fonctionnalités • Gagner du temps La qualité permet de réduire le doute, gagner en temps et en confiance
6. Une fois en production le code reste actif, les bugs aussi.
7. Il faut donc anticiper et identifier ce qui est bien et ce qu'il faut changer.
8. Par où commencer ? Comment analyser en interne ? • Demander à l'équipe • Métriques • Retours utilisateurs • Identifier les tâches qui n’avancent pas
9. Par où commencer ? Faire appel à un regard extérieur • Retour factuel • Regard neuf • Force de proposition • Document d'analyse complet • Restitution auprès de l'équipe Objectif
10. Biais et postures à éviter • Lire seulement le code que l'on veut lire • Ne pas prendre en compte l'avis de tous • Accuser et blâmer Il faut rester constructif et factuel
11. Métriques de code Analyser pour mieux anticiper • Couverture des tests • Nombres de lignes • Nombre de contributeurs • Nombre de bugs
12. Métriques de performance • Poids de l'application • Consommation mémoire • Consommation batterie • Fuites mémoires • Rafraîchissement de l'écran • Consommation réseau Analyser pour mieux anticiper
13. Le projet • Intégration continue • Complexité de livraison • Patrons de conception • Langage • Plateformes ciblées • Bibliothèques utilisées Analyser pour mieux anticiper
14. Signaux à identifier • Taux de crash élevé • Une volumétrie de code incohérente • Un manque de conception • Absence de tests • Déclarations en dur dans le code • Des avertissements de code ignorés • Un manque de documentation • Des commentaires manquants / non pertinents • Des tests inutiles ou désactivés • Des patrons de conception dépassés • Utilisations de composants anciens, non mis à jour ou dépréciés. Les pistes à suivre
15. Récapitulatif • Négliger la qualité c’est faire un pari. • Il faut créer un cadre propice à l’analyse en interne et/ou avec des intervenants extérieurs. • Garder une optique constructive et factuelle pour travailler ensemble aux suites à apporter à l’analyse. • Ne pas négliger la qualité dans les prochaines évolutions pour ne pas avoir à recommencer ce schéma.
16. Feedbacks @Xebiconfr - #Xebicon19