ENVOL 2023

marc.dexet@ias.u-psud.fr

by nc

Licence CC by-nc 4.0

1. Plan

  • Introduction au refactoring

  • Bref rappel sur le test

  • Voyage à l’intérieur du cerveau

  • Améliorer la compréhension

  • Améliorer la conception

  • Améliorer la testabilité

2. Introduction au refactoring

  • ⇒ Introduction au refactoring

  • Bref rappel sur le test

  • Voyage à l’intérieur du cerveau

  • Améliorer la compréhension

  • Améliorer la conception

  • Améliorer la testabilité

2.1. Introduction

Refactoring et Agilité

Pas de fête sans gâteaux !

2.2. Que faisons nous quand nous développons ?

  • Réponse à un besoin humain

    • Pas de besoin, pas de projet !

  • Traduction

    • Des concepts humains ⇒ code exécutable par un ordinateur

    • Du code exécuté ⇒ concepts manipulables par des humains

  • Plusieurs traductions, plusieurs univers

    • Client(e), Architecte, Développeuse et Développeur, Fonctionnel, Technique, Management

  • Traduire, c’est trahir

    • Des univers aux fondamentaux différents

2.2.1. Comment s’assurer que nous développons bien ?

  • Notion de Qualité Logicielle

  • Capacité fonctionnelle

    • Est-ce que le logiciel répond aux besoins fonctionnels exprimés ?

  • Maintenabilité

    • Est-ce que le logiciel requiert peu d’effort à son évolution par rapport aux nouveaux besoins ?

ISO 9126 quality (en)

https://commons.wikimedia.org/wiki/File:ISO_9126_quality_(en).svg

2.2.2. Maîtriser la complexité

complexity

  • Complexité vs Complication ?

    • Complexe s’oppose à simple ⇒ indirecte,

    • Compliqué s’oppose à facile ⇒ difficile.

  • Complexité du projet

    • Besoins humains, Outils techniques

  • La complexité engendre la complexité

    • Problème humain complexe ⇒ code complexe

  • Développement ⇒ activité complexe peut devenir vite très compliquée

    • Beaucoup d’éléments & d’aspects à prendre en compte

Un logiciel est une solution en réponse à un besoin humain. Si ce besoin est simple, simple à exprimer, à formaliser, à traduire en code, que la traduction est assez directe, la solution sera simple également. Mais de tels besoins, à part des scripts très modestes, ne nécessitent pas de méthodologie.

Dès que le besoin devient plus conséquent, qu’il est nécessaire de passer par plusieurs étapes de traductions, les choses deviennent beaucoup moins facile. Il s’agit de prendre en compte la notion de complexité

Dans la construction d’une solution logicielle, de nombreux éléments sont souvent en interaction et s’influencent mutuellement. Plusieurs aspects à prendre en compte: la sécurité, la cohérence de l’application, les domaines métiers, les tests, etc. L’un des risques principaux est de perdre de vue ce que l’on souhaite faire, de s’éparpiller, d’être un peu en état de stupeur devant l’ensemble des connaissances à mobiliser.

Développer un logiciel, c’est aussi garder la complexité sous contrôle

2.3. Agilité

  • Réponse à la complexité

    • Expériences passées submergées par la complexité

    • Nouvelle façon de définir et atteindre la capacité fonctionnelle

  • Adopter une démarche itérative et incrémentale

    • Ajouts de fonctionnalité successifs

    • Feedback rapide du client

    • Ne pas prétendre à l’exhaustivité

    • Se donner le droit de découvrir et changer

iterative incremental mona lisa b8d2b

  • Sur le plan purement technique

    • Conception (Software Design) toujours en évolution

    • Une recherche de l’excellence technique

  • Sur le plan management

    • Avoir confiance dans les personnes en charge du développement.

    • Une remise en cause et une adaptation permanente

    • Un rythme de travail soutenable

2.4. Maintenabilité

Mesure de la facilité

  • Faciliter la compréhension

  • Faciliter l'analyse

  • Faciliter la modification

  • Faciliter les tests

  • Faciliter l'assemblage des composants

Faire évoluer un logiciel à un rythme soutenable ⇒ garantir maintenabilité

... à condition de ne pas être trop endetté.

  • Faciliter la compréhension

    • Que font les composants ?

    • Comment le font-il ?

  • Faciliter l’analyse

    • Trouver qui est responsable de quoi,

    • Évaluer l'impact d’une modification,

    • Diagnostiquer rapidement les erreurs en cours d’exécution.

  • Faciliter la modification

    • Corriger des bugs,

    • Améliorer des parties de code,

      • Meilleures performances

      • Économiser des ressources

    • Le tout sans redouter que cela ne vous éclate à la figure.

  • Faciliter les tests

    • Concevoir des tests,

    • Écrire des tests,

    • Les exécuter le plus fréquemment possible.

2.5. Dette technique

  • Choisir, c’est regretter

    • Développer ⇒ choix à court termes

      • Contraintes de temps et de budget

      • Personnes/compétences/expertises disponibles

  • Choix à court terme ⇒ entropie naturelle

    • ⇒ Compromis, maladresses, manques de clairvoyances, renoncements

    • ⇒ Compréhension ou conception obsolète ou incomplète

dette technique

Au cours d’un développement, il est naturel que des compromis, des maladresses ou des raccourcis soient commis. Cela fait parfois gagner du temps ou des ressources, parfois cela est du à un manque de clairvoyance ou plus simplement à une vision de la conception qui n’était pas la plus pertinente mais qui pénalisent la maintenabilité de l’application et sa faculté à évoluer.

  • Dette technique

    • Dette : Renoncement accélérant le développement

    • Remboursement : Réécriture du code

  • Endettement

    • Dette remboursée plus tard ⇒ Dette plus coûteuse à rembourser

alt alt

2.5.1. Dette technique > Appréciation

  • Toutes les dettes ne se valent pas

    • Choix assumé pour se développer

    • Descente aux enfer par méconnaissance

    • ⇒ Deux axes d’évaluation

  • Réfléchie

    • Limitation

      • A une partie isolée du code ou généralisée

    • Prudence

      • Aspect marginal ou au coeur de l’application

  • Volontaire

    • En connaissance de cause

      • Conscience et compétence

      • …​ ou absence des deux

    • Recul

      • Réflexion sur ce qu’il aurait possible de mieux faire

2.5.2. Dette technique > Appréciation

dette technique quadrant

Ne pas en faire un sujet de honte

Nécessité d’en avoir conscience et de la résorber

Recommandations de lecture

https://www.lemondeinformatique.fr/actualites/lire-la-dette-technique-reste-mal-comprise-86974.html

https://wikiagile.fr/index.php?title=Quadrant_de_la_Dette_Technique

2.5.3. Dette technique > Mesure

  • Écart aux bonnes pratiques

  • Bonnes pratiques

    • Heuristiques propres à chaque écosystème

    • Principes reconnus (Code Clean)

    • Design Patterns (GoF, GRASP, …​)

  • Référentiel de mauvaises pratiques

    • Anti patterns

    • Bad smells

  • Systèmes d’analyse qualité

    • Sonarqube, qodana, …​

Les moteurs d’analyse qualité sont des outils très puissants, le plus connu étant sonarqube. Mais il n’est pas forcément nécessaire d’utiliser, encore moins de mettre en oeuvre, un tel système pour avoir une idée des écarts manifestes et corrigeables. Des linters suffisent.

2.5.4. Ultra rapide présentation de Sonarqube

  • Analyseur statique open source

    • Evaluation de la dette suivant plusieurs aspects

    • Détail des point litigieux

    • Une forme d’objectivation

  • Rapide présentation

    • Je vous en met plein les mirettes

    • Nous jouerons plus tard si nous en avons le temps

    • Vous aurez le temps à la maison de jouer avec :)

2023 11 12T18 33 06 601Z
Lancement de l’image sonarqube
docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 sonarqube

  • Se loguer avec admin/admin

  • Changer en admin/refact

Repérer l’adresse IP

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' sonarqube
Créer le projet dans Sonarqube

Sélectionner "Create project Manually"

12 13 31 How do you want to create your project

Associer un id et un nom

12 35 21 Create a project

Utiliser la configuration globale

12 35 38 Create a project

Sélectionner l’analyse locale

12 35 55 SonarQube

Créer un token d’authentification

12 37 13 SonarQube

Continue

12 37 27 SonarQube

Vous avez un exemple des paramètres pour lancer l’analyse

12 38 22 SonarQube
Projet python

Include un fichier sonar-properties ultra-simpliste

sonar.projectKey=tm2raw
sonar.organization=ias
sonar.python.version=3
sonar.sources=src
sonar.dynamicAnalysis=reuseReports
sonar.python.coverage.reportPaths=*coverage*.xml
Préparer les tests

Installer des libraries propres à Python pour l’analyse

pip install pylint pytest pytest-cov
Lancer les tests
pytest -v  tests/unit/ --cov --cov-report=xml --cov-report=html
Lancer l’analyse
./sonnar-scanner/bin/sonar-scanner  -Dsonar.host.url=http://172.17.0.2:9000   -Dsonar.token=sqp_5e14217deb6e23ad8c728041f41bd736fb478b3c
INFO: Scanner configuration file: /home/mdexet/Workdirs/MAJIS/SGS/majis-tm2raw-pipeline/sonnar-scanner/conf/sonar-scanner.properties
INFO: Project root configuration file: /home/mdexet/Workdirs/MAJIS/SGS/majis-tm2raw-pipeline/sonar-project.properties
INFO: SonarScanner 5.0.1.3006
INFO: Java 17.0.7 Eclipse Adoptium (64-bit)
...
INFO: Analysis report compressed in 101ms, zip size=150.6 kB
INFO: Analysis report uploaded in 14ms
INFO: ANALYSIS SUCCESSFUL, you can find the results at: http://172.17.0.2:9000/dashboard?id=tm2raw
INFO: Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
INFO: More about the report processing at http://172.17.0.2:9000/api/ce/task?id=AYvEwhGUMb_Dhw3teUnJ
INFO: Analysis total time: 7.482 s
INFO: ------------------------------------------------------------------------
INFO: EXECUTION SUCCESS
INFO: ------------------------------------------------------------------------
INFO: Total time: 8.465s
INFO: Final Memory: 40M/188M
INFO: ------------------------------------------------------------------------
Voir l’analyse

Aller sur l’URL fournie http://172.17.0.2:9000/dashboard?id=tm2raw

2023 11 11T13 07 59 786Z

Vue générale de l’évaluation de la qualité

2023 11 11T13 08 56 557Z

Infographie générale

2023 11 11T13 09 21 434Z

Evaluation de la maintenabilité

2023 11 11T13 10 25 598Z

Détail d’un item : respect des standard Clean code

2023 11 11T13 13 02 542Z

Détail d’un item : Maintenabilité

2023 11 11T13 13 29 185Z

Détail d’un item : Maintenabilité

2023 11 11T13 14 04 477Z

Détail d’un item : Code Smell

2023 11 11T13 14 32 923Z

Vue de détail dans le code

2023 11 11T13 18 37 199Z

Explication du problème avec exemple