1. Qualité de code et Sonar
MUG Lyon – 24 octobre 2013 – Hébergé par Sciences-U
Clément Bouillier - @clem_bouillier

2. Le MUG Lyon
Une session tous les derniers jeudis du mois à Sciences-U (merci !)
•
Petite question : préférez-vous 19h ou 19h30 ?  vote à main levée ?
Prochaines sessions
•
•
Plateforme TFS online et Azure + afterwork le 28/11
Afterwork seulement probablement en décembre (date à fixer)
Suivez toutes les communautés lyonnaises sur le calendrier Lyon Tech
Hub !
•
Coding Dojo DDD le jeudi 7 novembre à l’INSA

3. Qui suis-je ?
Architecte/chef de projet/consultant mais avant tout
ARTISAN DEVELOPPEUR
> Twitter : @clem_bouillier
Membre actif des groupes suivants
> DevLyon : groupe de développeurs indépendants partageant une
vision de l’informatique créant de la valeur  http://devlyon.fr
> MUG Lyon : groupe de passionnés de technologies en
environnement Microsoft sur Lyon
> Fier d’être développeur : groupe visant à promouvoir le métier
de développeur en France  http://fierdetredeveloppeur.org/

4. Tour d’horizon

5. La qualité de code, c’est-à-dire ?
Pourquoi ?
Différents aspects
•
•
•
Règles de code  pour assurer l’homogénéité du code d’une équipe
Métriques  pour comprendre la structure/le design du code
Tests  pour se couvrir de régressions potentielles
Une problématique de fond : maîtriser la dette technique
•
•
•
C’est quoi ?
Pourquoi ?
Laquelle ?

6. La dette technique

7. Et Sonar ?
Un outil parmi d’autres (Cast, NDepend…)…
…mais un outil qui est facile à mettre en œuvre…
…et qui est gratuit (sauf quelques plugins)
Mais avant de passer à l’outillage, revenons aux fondamentaux !

8. Quelques fondamentaux
De la programmation orientée objet du moins…

9. Quelques références
Clean Code – Robert C. Martin (Uncle Bob)
Agile Principles, Patterns, and Practices in C# - Uncle Bob
Code Complete – Steve McConnell
Vidéos d’Uncle Bob : https://www.cleancoders.com/

10. Principes de programmation
DRY = Don’t Repeat Yourself
•
•
Copier/coller du code est à banir
Factoriser
YAGNI = Your Aren’t Gonna Need It
•
Ne faites pas une usine à gaz pour écraser une mouche
KISS = Keep It Simple Stupid
•
/! “Everything should be made as simple as possible,
but not simpler.” Einstein

11. Principes de conception orientée objet
Utiliser un langage orienté objet ne suffit pas pour faire de la POO
Des pratiques ayant bientôt 20 ans sont encore très mal connues
•
•
•
Class cohesion
SOLID
Law of Demeter
Objectif : rendre le logiciel plus facile à modifier (évolutif et maintenable)
Un point commun : la gestion des dépendances
•
•
•
•
Réduire leur nombre
Organiser de manière cohérente
Coupler faiblement
/! au classique « plat de spaghettis »

12. Quelques détails rapides…
SOLID
•
•
•
•
•
SRP = Single Responsability Principle
Open/closed principle = ouvert à l’extensibilité mais fermé à la modification
Liskov substitution = tout objet doit pouvoir être substitué par un objet d’une
classe dérivée
Interface segregation = créer de petites interfaces
Dependency Inversion = fournissez les dépendances à vos objets  IOC/DI
Law of Demeter = éviter monObjet.MaRelation.MaPropriété
Class Cohesion = éviter de mettre dans une même classe des membres qui
n’ont pas de cohésion entre eux  métrique LCOM = 4
Dépendances = toutes les classes dont dépend une classe  métrique RFC =
nombre de méthode + nombre d’appels de méthodes externes

13. Homogénéité du code
« ce n’est que de la cosmétique… »
Et bien non pas tout à fait
•
•
•
La non homogénéité détourne l’attention de chacun => attention aux guerres de
cloché
Ca crée du bruit dans le gestionnaire de code source => historique moins lisible
C’est particulièrement compliqué à gérer lors de fusion de branches
Le plus simple reste d’utiliser des standards de fait commun à toute l’équipe
=> StyleCop
•
Avec quelques ajustements/personnalisation éventuels => StyleCop+ (plus long)

14. Tests automatisés
Le plus important est d’avoir des tests automatisés
•
•
•
Attention au coût  « test first »
Aide à produire un meilleur design technique
Voire aide à déceler des incohérences/problématiques
Regardez le TDD et le BDD pour en savoir plus…
Attention, à ne pas trop se concentrer sur la couverture
•
•
100% ne signifie pas un code parfait => combinatoire
La couverture par rapport à la complexité peut être plus
intéressante

15. Synthétisé en 7 « péchés capitaux » du
dev
Dans la documentation Sonar, on trouve les 7 péchés capitaux du dev
suivants :
•
•
•
•
•
•
•
Mauvaise distribution de la complexité  KISS, SRP (le S de SOLID)
Duplication de code  DRY
Manque de tests automatisés  TDD/BDD
Pas de norme de codage  homogénéité du code
Pas assez ou trop de commentaires  KISS, SRP
Bugs potentiels  violations de l’ensemble des règles
Design Spaghetti  gestion des dépendances en POO

16. Un outillage avec SonarQube
Un parmi d’autres possibles…

17. Pour commencer : quelques pièges à
éviter !
L’outil ne remplace pas les revues de code
L’outil doit être apprivoisé par toute l’équipe,
ainsi que des pratiques autour de la
réduction/maîtrise de la dette technique
L’outil reste un outil, attention aux dérives du
contrôle et de l’objectivation sur des mesures
•
Toute mesure objectivée est artificiellement
optimisée

18. Lancer une analyse Sonar pour C#
Installation d’un JDK (et oui Sonar est issu de la communauté
Java…encore )
Serveur (dans mon cas une VM Ubuntu)
•
•
•
Dé-zipper la distribution de SonarQube
Configurer une base de données pour Sonar (créer une base vide + login)
Installer le plugin Sonar via l’interface d’admin (un clic + redémarrage)
Client (dans mon cas une VM Windows 2008 R2)
•
•
•
•
Dé-zipper la distribution de SonarRunner
Configurer l’accès au serveur (une ligne de config)
Installer FxCop (si besoin)
Créer un fichier de config pour le projet (10 lignes)
* ATTENTION : quelques cas particuliers non gérés comme pas de solution, projet WebSite…
Bien exercé c’est
30 minutes !!
Sinon comptez 2h*

19. Comment ça marche ?
Un plugin C# installé sur le serveur récupéré par SonarRunner, basé sur
•
•
Un analyseur de code propre à Sonar
Des outils de l’environnement .NET : StyleCop, FxCop, Gendarme, Gallio
Un profil de qualité pour configurer les règles sur le serveur
SonarRunner lance l’analyse en récupérant ces informations et en
lançant chacun de ces outils

20. Démo
Un premier coup d’œil : le dashboard
Zoom sur quelques métriques/règles
Configuration des règles de codage
On relance et on observe l’évolution
Suivi de plans d’action
Avec le code des projets suivants:
• CodeStory du MugLyon
• SDK AR Drone

21. R# et SonarQube
SonarQube peut paraître fastidieux et le feedback n’est pas immédiat…
Pour la partie homogénéité du code, couplez-le à R# et StyleCop (plugin
R# par défaut)
• Erreurs en temps réel (soulignées)
• Propositions de correction automatique !
 Plus d’excuses…
=> rapide démo

22. Autres fonctionnalités…
Analyser des projets basés sur d’autres langages : Java, PHP, Javascript, Web
(HTML, CSS), VB.Net, COBOL, ABAP…(/! certains plugins sont payants)
•
•
En PHP, couplez-le à PHPStorm (encore JetBrains, l’éditeur de R#...)
En Java, couplez-le à Eclipse ou IntelliJ (toujours JetBrains…)
Analyser des projets multi-langages : Java/Javascript/Web
•
Ca ne marche pas avec le plugin C# couplé à d’autres langages   projets
séparés
Plus d’outils en Java : Dependency Structure Matrix, FindBugs…
Beaucoup de plugins

23. Retour d’expérience sur des audits
L’outil n’est pas la première étape d’analyse
•
•
Faites-vous expliquer la solution et l’architecture
Regardez la structure du code
L’outil va uniquement permettre de zoomer sur certains points,
d’identifier des problèmes
L’interprétation des résultats constitue le réel apport d’un audit, avec
un plan d’action défini

24. Alors on fait quoi demain ?

25. On maîtrise sa dette technique !
Comprendre ce qu’est la qualité de code  Documentez-vous !
Définir votre cible  Think Big
Commencez par ce qui est le plus important  Act Small
Outiller votre démarche, ça sera moins douloureux…
Et le code existant n’est pas une excuse ! Ca ne fera qu’empirer !

26. Feedback
MERCI !