Qualité de code et Sonar

MUG Lyon – 24 octobre 2013 – Hébergé par Sciences-UClément Bouillier - @clem_bouillier

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

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/

Tour d’horizon

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 ?

La dette technique

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 !

Quelques fondamentauxDe la programmation orientée objet du moins…

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/

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

Principes de conception orientée objetUtiliser 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 »

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 = 4Dépendances = toutes les classes dont dépend une classe métrique RFC = nombre de méthode + nombre d’appels de méthodes externes

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)

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

Synthétisé en 7 « péchés capitaux » du devDans 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

Un outillage avec SonarQubeUn parmi d’autres possibles…

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

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)

Bien exercé c’est 30 minutes !! Sinon comptez 2h*

* ATTENTION : quelques cas particuliers non gérés comme pas de solution, projet WebSite…

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

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

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

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

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

Alors on fait quoi demain ?

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 !

Feedback

MERCI !