20131024 qualité de code et sonar - mug lyon

2 559 vues

Publié le

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 559
Sur SlideShare
0
Issues des intégrations
0
Intégrations
72
Actions
Partages
0
Téléchargements
62
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

20131024 qualité de code et sonar - mug lyon

  1. 1. Qualité de code et Sonar MUG Lyon – 24 octobre 2013 – Hébergé par Sciences-U Clément Bouillier - @clem_bouillier
  2. 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. 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. 4. Tour d’horizon
  5. 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. 6. La dette technique
  7. 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. 8. Quelques fondamentaux De la programmation orientée objet du moins…
  9. 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. 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. 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. 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. 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. 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. 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. 16. Un outillage avec SonarQube Un parmi d’autres possibles…
  17. 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. 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. 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. 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. 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. 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. 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. 24. Alors on fait quoi demain ?
  25. 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. 26. Feedback MERCI !

×