Télécharger pour lire hors ligne
Téléchargé parIdean France
Cocoaheads Montpellier Meetup : L'analyse de Code Statique avec Objective-C / SWIFT
La présentation traite de la dette technique dans le développement iOS chez Backelite, soulignant son impact sur le temps de développement. Elle propose des solutions pour mesurer et maîtriser cette dette à travers des outils comme SonarQube et la méthode SQALE. Enfin, un workflow est suggéré pour intégrer efficacement SonarQube dans le processus de développement afin de contrôler la qualité du code.
Contenu connexe
![[Atelier des experts] Design d'expérience utilisateur : adopter une approche ...](https://cdn.slidesharecdn.com/ss_thumbnails/atelierdesexperts-160114104903-thumbnail.jpg?width=640&height=640&fit=bounds)
Similaire à Cocoaheads Montpellier Meetup : L'analyse de Code Statique avec Objective-C / SWIFT
Cocoaheads Montpellier Meetup : L'analyse de Code Statique avec Objective-C / SWIFT
- 1. ANALYSE DE CODESTATIQUE OBJECTIVE-C / SWIFT COCOAHEADS MONTPELLIER - 14 AVRIL 2016
- 2. BACKELITE SOMMAIRE 9 ans dedéveloppement iOS chez Backelite Le fléau de la dette technique Mesurer la dette pour la maitriser SonarQube avec Objective-C et Swift Travailler avec SonarQube Un workflow approprié pour garder le contrôle 14 AVRIL 2016 2
- 3. 9 ANS DEDÉVELOPPEMENT IOS CHEZ BACKELITE
- 4. BACKELITE14 AVRIL 2016 DESAPPLICATIONS MOBILES DE PLUS EN PLUS COMPLEXES 4 0 75 150 225 300 375 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 Jours de développement
- 5. BACKELITE14 AVRIL 2016 DESTEMPS DE DÉVELOPPEMENT DE PLUS EN PLUS LONG AU FIL DES VERSIONS 5 40 50 60 70 80 90 V1 V2 V3 V4 JH Théoriques JH Constatés
- 6. CET ÉCART S’APPELLE: LA DETTE TECHNIQUE ! 6
- 7. LE FLÉAU DELA DETTE TECHNIQUE
- 8. BACKELITE14 AVRIL 2016 LADETTE TECHNIQUE Wikipédia : La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham. Il s'inspire du concept existant de dette dans le contexte du financement des entreprises et l'applique au domaine du développement logiciel. 8
- 9. BACKELITE14 AVRIL 2016 D’OÙPROVIENT LA DETTE TECHNIQUE ? Causes non intentionnelles Mauvaise conception d’une application Non respect des bonnes pratiques de codage 9 Causes Intentionnelles « Quick wins » pour livrer un projet dans les temps Cela vous parle ? Logique : nous sommes tous des pollueurs de code !
- 10. BACKELITE14 AVRIL 2016 LADETTE TECHNIQUE : UN PHÉNOMÈNE PLANÉTAIRE ! La dette technique mondiale était estimée à 1 trillion de dollars en 2015 par Gartner 10 source : http://www.gartner.com/newsroom/id/1439513
- 11. MESURER LA DETTEPOUR LA MAITRISER
- 12. BACKELITE14 AVRIL 2016 MESURERLA DETTE TECHNIQUE Si vous ne pouvez pas le mesurer, vous ne pouvez pas l'améliorer 12 William Thomson (Lord Kelvin) 1824–1907
- 13. BACKELITE COMMENT MESURER LADETTE TECHNIQUE ? 14 AVRIL 2016 Il est possible d’inventer sa propre méthode de mesure… 13 Ou mieux : en utiliser une qui existe déjà !
- 14. BACKELITE14 AVRIL 2016 LAMÉTHODE SQALE (SOFTWARE QUALITY ASSESSMENT BASED ON LIFECYCLE EXPECTATIONS) 14 Mesure l’écart entre le standard (la qualité attendue) et la réalité à l’aide de règles. Le modèle d’analyse permet d’obtenir le cout des mesures correctives pour les index suivants : Testability Reliability Changeability Efficiency Security Maintainability Portability Reusability
- 15. BACKELITE14 AVRIL 2016 LAMÉTHODE SQALE 15
- 16. SONARQUBE AVEC OBJECTIVE-CET SWIFT
- 17. BACKELITE14 AVRIL 2016 SONARQUBE(ANCIENNEMENT SONAR) 17 Plateforme open source d’inspection de qualité de code en continue. • La référence ! • Composé d’un module serveur et d’un « runner » • Extensible par mécanisme de plugin (ajout de languages, de sensors, de widgets graphiques…)
- 18. BACKELITE14 AVRIL 2016 SONARQUBE: SUPPORT D’OBJECTIVE-C ET SWIFT 18 2014 Support Objective-C commercial (5000$) Support Objective-C open source cassé Pas de support de Swift Contributions au plugin open source pour le mettre à niveau Création d’un fork pour ajouter de nouvelles fonctionnalités Sortie d’un plugin Swift commercial 2016 Fork indépendant du plugin Objective-C Réalisation d’un plugin pour le support de Swift
- 19. BACKELITE14 AVRIL 2016 SONARQUBE: FONCTIONNALITÉS DES PLUGINS BACKELITE Objective-C https://github.com/Backelite/sonar-objective-c Analyse des défauts (OCLint et Faux Pas, 170 règles) Données de test Couverture de code (y compris Xcode 7+) Complexité SQALE 19 Swift https://github.com/Backelite/sonar-swift Analyse des défauts (SwiftLint, 32 règles) Données de test Couverture de code Complexité SQALE
- 20.
- 21. BACKELITE14 AVRIL 2016 SONARQUBE: PROFILS DE QUALITÉ 21 Les profils de qualité permettent d’activer /désactiver ou changer la sévérité des règles par language.
- 22. BACKELITE14 AVRIL 2016 SONARQUBE: NOTATION SQALE Objective-C https://github.com/Backelite/sonar-objective-c Analyse des défauts (OCLint et Faux Pas, 170 règles) Données de test Couverture de code (y compris Xcode 7+) Complexité SQALE 22 La méthode SQALE est utilisée pour calculer la dette technique. Des widgets permettent de visualiser la dette et la pyramide de la dette
- 23. BACKELITE14 AVRIL 2016 SONARQUBE: QUALITY GATES 23 Les quality gates permettent de définir des seuils de tolérances (warning, error) sur les différentes métriques d’un projet
- 24. BACKELITE14 AVRIL 2016 SONARQUBE: NOTIFICATIONS 24 Les notifications permettent de vous informer des nouveaux défauts que vous avez engendré en vous envoyant un mail à la fin d’une analyse
- 25. BACKELITE14 AVRIL 2016 SONARQUBE: PLANS D’ACTION 25 Les plans d’actions permettent de structurer les phases de nettoyage du code
- 26. UN WORKFLOW APPROPRIÉPOUR GARDER LE CONTRÔLE
- 27. BACKELITE14 AVRIL 2016 SONARQUBE: INTÉGRATION CONTINUE 27 + =
- 28. BACKELITE14 AVRIL 2016 QUANDCONTRÔLER LES DÉFAUTS DE SON CODE ? 28 git push de fin de journée analyse nocturne notification des défauts par mail correction des défauts implémentation de nouvelles fonctionnalités
- 29. BACKELITE14 AVRIL 2016 COMMENTTRAITER LES DÉFAUTS DANS SONARQUBE ? 29 Le navigateur de code de SonarQube permet de facilement repérer ses défauts et les marquer en résolus ou faux positifs
- 30. BACKELITE14 AVRIL 2016 ETSURTOUT NE PAS OUBLIER… 30 …que tous les outils du monde ne remplacent pas une bonne revue de code de temps en temps !
- 31.
- 32. Gilles Grousset @zippy1978 DES QUESTIONS? BACKELITE14 AVRIL 2016 32
Notes de l'éditeur
- #5 Au début : comme le web, des applications « vitrines », avec peu de fonctionnalités Au fil du temps : plus de budget, plus de fonctions (transformation digitale des clients) Aujourd’hui : des applications plus riches, très souvent développées en continue (agile) Cycle de mise à jour : passé de 1 à 2 versions par an, à 4 à 5.
- #6 Entre chaque version d’une application : les temps de développements n’évolue pas de façon linéaire, alors que la charge estimée est la même pour chacune des versions A chaque nouvelle version : l’écart augmente Sur des applications avec peu de fonctionnalités : l’écart n’est pas flagrant, mais plus l’application se complexifie, plus l’écart est visible
- #7 La partie visible : ce que le client et l’utilisateur voient La partie immergée : ce que le développeur voit dans le code
- #9 Similaire également à l’empreinte carbone : les déchets que nous laissons derrière nous en codant, et qui auront un cout de recyclage
- #10 Tous des pollueurs de code : plus on écrit de code, plus nous avons des chances de polluer.
- #11 De quoi occuper des générations de développeurs ! Le problème s’accentue et le phénomène s’accélère : il commence à y avoir une prise de conscience sur le sujet
- #13 Mathématicien / physicien, président de la Royal Society
- #16 Requirement : chacun a un cout / un poids (linéaire ou non)
- #18 Projet OSS porté par la société SonarSource A l’origine : orienté Java, puis s’étend à d’autres languages web Version actuelle : 5.4 Plugins gratuits et payants !
- #19 En 2014 : pas grand chose, plugin open source cassé à causes d’vols majeures de l’API de Sonar (passage du 3.6 au 4.x) Reprise en main du plugin open source via des contribs Initialisation d’un fork pour rajouter des nouvelles fonctionnalisés : nouvelles règles, calcul de la complexité cyclomatique
- #22 Chez BK : la maintenance du profil par défaut est assurée par les lead tech (référents techno) Des profils spécifiques peuvent être attribués sur des projets
- #23 Dispo depuis les version 4.5+ La note : elle se configure dans les paramètres et se base sur le ratio
- #24 Permet de définir les seuils d’acceptabilité d’un code Peut être utilisé pour mettre ne erreur un job Jenkins (ex: livraison impossible tant que tous les tests ne sont pas ok…)
- #25 On voit souvent SonarQube comme un gros Dashboard : mais il permet aussi d’effectuer des « actions » Les notifications permettent la notification par projet ou tous projets confondus Pour l’assignation automatique des défauts, il faut les plugins ‘SCM stats’ et ‘Issue assign’
- #26 Un plan d’action est composé d’issues et peu avoir une échéance
- #28 Les développeurs ne doivent pas être perturbés par SonarQube, il ne doivent donc pas s’en occuper Les analyses sur des bases de code importantes peuvent être longues = la nuit c’est mieux 1 fois par jour, ca suffit !
- #29 SonarQube n’est qu’un outil = sans intégration a son process de travail, il ne sert pas a grand chose Suggestion : traiter ses défauts de la veille le matin = ce n’est pas long et ça permet de maintenir le code « en bon état »
- #30 Un clic sur le défaut permet d’avoir l’explication du défaut Quand un défaut est marqué comme résolu : il est revivifié à l’analyse suivante et peut être réouvert Seuls les admin de défauts (issue admins) peuvent passer un défaut en faux positif (chez BK : ce sont les lead dev)
- #31 Les développeurs ne doivent pas être perturbés par SonarQube, il ne doivent donc pas s’en occuper Les analyses sur des bases de code importantes peuvent être longues = la nuit c’est mieux 1 fois par jour, ca suffit !