EnglishCommencer

L'inspection continue

L'analyse statique lancée à chaque poussée : linter, familles de constats de SonarQube, mesures de couverture et de duplication, dette technique, notes, porte de qualité sur le nouveau code et faux positifs.

  • 25 cartes
  • 4 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation

Quelques cartes du deck

  • Inspection continue : de quoi s'agit-il ?

    Voir la réponse

    Pratique qui analyse automatiquement le code à chaque changement et signale bogues, failles et mauvaises pratiques avant la fusion.

    Un défaut signalé sur le changement qui l'introduit est corrigé par son auteur, tant que le contexte est frais. Découvert des mois après, il coûte bien plus.

  • L'analyseur signale la lecture ci-dessous (règle Java S2095, ressource non fermée). Quelle correction ferme le fichier à coup sûr ?

    ```java
    String lire(String chemin) throws IOException {
    BufferedReader lecteur = new BufferedReader(new FileReader(chemin));
    String ligne = lecteur.readLine();
    lecteur.close();
    return ligne;
    }
    `

    • Un try avec ressources
    • Appeler close() avant readLine() pour libérer le fichier tôt
    • Ajouter un catch qui ignore l'exception et rend null
    • Appeler close() dans un bloc catch qui relance l'exception
    Voir la réponse

    Un try avec ressources

    Si readLine() lève une exception, close() n'est jamais atteint et le fichier reste ouvert. Le try avec ressources ferme le lecteur dans tous les cas, avec ou sans exception ; un catch ne ferme que sur le chemin de l'erreur.

  • Un point sensible de sécurité (security hotspot) n'est pas forcément une faille : un humain doit l'… pour décider s'il est sûr ou à corriger.

    Voir la réponse

    Un point sensible de sécurité (security hotspot) n'est pas forcément une faille : un humain doit l'examiner pour décider s'il est sûr ou à corriger.

    La porte de qualité par défaut exige que tous les points sensibles du nouveau code soient revus, sans pour autant les tenir tous pour des failles.

  • Analyse statique : de quoi s'agit-il ?

    Voir la réponse

    Examen du code source sans l'exécuter, pour y repérer des constructions fautives ou dangereuses.

    Elle voit tous les chemins, y compris ceux que les tests n'empruntent jamais, mais elle peut se tromper : elle produit des faux positifs.

  • Sur une application de dix ans, la porte de qualité bloque toutes les fusions et l'équipe veut la couper. Quelle solution garde l'inspection utile ?

    • Baisser tous les seuils jusqu'à ce que l'ancien code passe
    • Appliquer la porte au seul nouveau code
    • Marquer tous les constats actuels comme faux positifs
    • Ne lancer l'analyse qu'avant les grandes versions
    Voir la réponse

    Appliquer la porte au seul nouveau code

    Les seuils portent ici sur tout le code et la dette ancienne bloque chaque changement. Les restreindre au nouveau code exige que chaque modification soit propre, sans geler l'équipe. Abaisser les seuils ou masquer les constats détruit la valeur de l'inspection.

Réviser ce deck