Lors du dernier Meetup Cocoaheads à Montpellier, qui a réunit une trentaine des développeurs iOS, Gilles Grousset, Development Team Manager chez Backelite, a présenté comment les équipes techniques font l'analyse de code statique avec Objective-C et SWIFT.
How to design forms that deliver a great user experience
Cocoaheads Montpellier Meetup : L'analyse de Code Statique avec Objective-C / SWIFT
1. ANALYSE DE CODE STATIQUE OBJECTIVE-C / SWIFT
COCOAHEADS MONTPELLIER - 14 AVRIL 2016
2. BACKELITE
SOMMAIRE
9 ans de dé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
4. BACKELITE14 AVRIL 2016
DES APPLICATIONS 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
DES TEMPS 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
8. BACKELITE14 AVRIL 2016
LA DETTE 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
LA DETTE 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
12. BACKELITE14 AVRIL 2016
MESURER LA 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 LA DETTE 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
LA MÉ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
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
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
28. BACKELITE14 AVRIL 2016
QUAND CONTRÔ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
COMMENT TRAITER 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
ET SURTOUT NE PAS OUBLIER…
30
…que tous les outils du monde ne remplacent pas une bonne revue de code de temps en temps !
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.
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
La partie visible : ce que le client et l’utilisateur voient
La partie immergée : ce que le développeur voit dans le code
Similaire également à l’empreinte carbone : les déchets que nous laissons derrière nous en codant, et qui auront un cout de recyclage
Tous des pollueurs de code : plus on écrit de code, plus nous avons des chances de polluer.
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
Mathématicien / physicien, président de la Royal Society
Requirement : chacun a un cout / un poids (linéaire ou non)
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 !
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
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
Dispo depuis les version 4.5+
La note : elle se configure dans les paramètres et se base sur le ratio
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…)
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’
Un plan d’action est composé d’issues et peu avoir une échéance
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 !
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 »
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)
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 !