Examen de génie logiciel avancé : 3. Qualité logicielle et refactoring

1. Réponse b : V(G) = E − N + 2
E est le nombre d'arcs, N le nombre de nœuds. On retient la formule par son résultat : un programme sans aucune décision forme une chaîne où E = N − 1, ce qui donne bien V(G) = 1.

2. Réponse b : deux points de décision
Chaque opérateur logique ajoute un point de décision, car il crée une branche supplémentaire dans le graphe de flot : on peut sortir parce que a est faux, ou parce que b l'est. C'est ce qui rend les conditions composées coûteuses à tester.

3. Réponse b : le fait que ce qu'il contient n'a pas de rapport commun
La cohésion décrit ce qui se passe à l'intérieur du module : ses éléments vont-ils ensemble ? Le nombre de dépendances est le couplage, qui est une autre mesure. Un module nommé Utils est le cas d'école de la cohésion faible.

4. Réponse c : modifie la structure interne sans changer le comportement observable
La définition est volontairement stricte. Si le comportement observable change, l'opération est une évolution ou une correction, et elle se conduit autrement : avec une recette, et non avec la seule exécution des tests existants.

5. Réponse b : écrire des tests de caractérisation
Les tests de caractérisation figent le comportement réel, y compris ses défauts, pour qu'on puisse affirmer ensuite que la restructuration n'a rien changé. Documenter le comportement attendu ne protège de rien, puisque le code fait peut-être autre chose.

6. Réponse b : ouvert, fermé
Ouvert à l'extension, fermé à la modification. C'est ce que permet le polymorphisme là où une cascade de selon obligerait à rouvrir, et donc à risquer, du code qui fonctionne déjà.

7. Réponse b : délibérée et prudente
Elle est délibérée parce qu'on la choisit, et prudente parce qu'on sait ce qu'on emprunte et quand on remboursera. C'est le seul cas où la dette est un bon outil de gestion. Elle devient imprudente le jour où janvier passe sans la reprise.

8. Réponse c : remplacer le conditionnel par le polymorphisme
Un champ qui pilote le comportement joue le rôle d'un type ; la réponse est de le rendre réellement typé. Extraire une fonction déplacerait le problème sans le supprimer : la cascade existerait toujours, ailleurs.

9. Réponse b : le code nouveau ou modifié
Un seuil posé sur l'existant est inatteignable sur une base ancienne, et il sera désactivé dans le mois. Posé sur le code nouveau, il est tenable dès le premier jour, et il suffit : la qualité remonte au rythme des modifications.

10. Réponse b : le coût de remise en état au coût de réécriture complète
C'est ce rapport qui rend le chiffre comparable d'un projet à l'autre, et interprétable : un ratio de 5 % se rembourse, un ratio de 60 % pose sérieusement la question de la réécriture.

1. Décompte. On part de 1, puis on ajoute un par point de décision :

• d.client = vide : 1
• ou d.site = vide : 1
• d.urgence < 1 : 1
• ou d.urgence > 4 : 1
• d.urgence = 4 : 1
• et d.responsable = vide : 1
• pour chaque : 1
• piece.quantite <= 0 : 1

Huit points de décision, dont quatre apportés par les opérateurs logiques. V(G) = 1 + 8 = 9.

2. Nombre minimal de cas. La complexité cyclomatique majore le nombre de chemins indépendants, donc neuf cas de test suffisent et sont nécessaires pour couvrir toutes les branches. On accordera le point à qui répond neuf en citant la mesure ; répondre « autant que de retourner », soit cinq, couvre les sorties mais non les branches, et laisse par exemple d.site = vide jamais exercé.

3. Jeu de cas.

Le cas 7 mérite une mention : une demande sans aucune pièce est acceptée. C'est peut-être voulu, peut-être non. Un jeu de test construit sur les branches fait apparaître la question, ce qu'une lecture rapide du code ne fait pas.

4. Faut-il découper ? V(G) = 9 se situe dans la zone « raisonnable », en dessous du seuil de 11. La réponse attendue est non, pas pour la complexité, et la nuance est le point important : cette fonction est plate, chaque contrôle est indépendant du suivant, et elle se lit de haut en bas sans effort. Le chiffre ouvre la discussion, il ne la tranche pas.

On pourra signaler un autre reproche, qui n'est pas une affaire de complexité : la fonction renvoie des messages d'erreur en clair, donc elle mélange la validation et la présentation. Renvoyer un code d'erreur, et laisser l'appelant choisir le message, rendrait la règle réutilisable et traduisible.

1. Envie de fonctionnalité. La méthode s'intéresse plus aux données d'autrui qu'aux siennes. La transformation est déplacer la méthode vers Client, ou extraire d'abord la part qui concerne le client si le reste doit demeurer dans Facture. Le bénéfice est la baisse du couplage : Facture cesse de connaître la structure interne de Client, qui peut alors évoluer seul.

2. Groupe de données, et liste de paramètres longue. Ces cinq valeurs voyagent toujours ensemble, ce qui est la définition d'un concept qui n'a pas encore de nom. La transformation est introduire un objet paramètre, ici une Adresse. Le bénéfice est double : les six signatures se réduisent à un paramètre, et l'objet devient le seul endroit où écrire la validation d'une adresse, aujourd'hui recopiée ou absente.

3. Conditionnel sur le type, répété. C'est l'odeur la plus coûteuse des quatre, parce qu'elle se paie à chaque ajout de statut : il faut retrouver les quatre selon, et en oublier un ne produit aucune erreur de compilation. La transformation est remplacer le conditionnel par le polymorphisme, en faisant du statut un type porteur de son comportement. Le bénéfice est la conformité au principe ouvert, fermé : un statut nouveau devient une classe nouvelle, et le compilateur exige ses méthodes.

4. Classe tentaculaire. Les trois indices se renforcent : la taille, le couplage sortant, et surtout la fréquence de modification, qui est la mesure la plus parlante. Une classe modifiée dans 78 % des tickets n'a pas une raison de changer mais vingt, donc elle viole la responsabilité unique. La transformation est extraire une classe, une par responsabilité, en se guidant sur les tickets eux-mêmes : regrouper ceux qui touchent aux mêmes lignes révèle les axes de découpe. Le bénéfice est la fin du goulot : deux demandes sans rapport cessent de se gêner dans le même fichier.

1. Les fonctions au-dessus du seuil. La zone « difficile à suivre » commence à 11. On additionne donc les deux dernières tranches :

18 + 6 = 24 fonctions sur 186, soit 12,9 % du module.

Cette part est plus parlante que la moyenne parce que la moyenne est écrasée par la masse des fonctions simples. Ici, 120 fonctions sur 186 sont à 5 ou moins : la complexité moyenne du module serait rassurante et n'apprendrait rien, alors que la souffrance de l'équipe se concentre dans les 24 fonctions que personne n'ose toucher. On mesure la qualité interne par sa queue de distribution, non par son centre.

2. Le ratio de dette.

62 ÷ 410 = 0,151, soit un ratio de 15,1 %.

Il dit que remettre le module en état coûterait un peu moins d'un sixième de ce que coûterait sa réécriture. C'est élevé, et c'est largement remboursable : l'ordre de grandeur plaide pour la reprise.

Il ne dit en revanche rien de trois choses, et les énoncer vaut autant que le calcul. Il ignore d'abord la valeur métier : une dette de 62 jours sur un module qu'on arrête l'an prochain ne se rembourse pas. Il ignore ensuite la répartition : ces 62 jours peuvent tenir dans 24 fonctions ou être étalés sur 186. Il ignore enfin le risque : une couverture de 18 % rend chaque jour de remise en état plus dangereux qu'il n'en a l'air, puisque rien ne signale la régression.

3. Réécriture ou reprise ? La position attendue est la reprise progressive, et le barème récompense les arguments chiffrés, non la conclusion seule.

• Le ratio le dit. 15,1 % signifie que la réécriture coûte près de sept fois la remise en état. On ne finance pas sept pour obtenir un.
• Le module n'est pas uniformément malade. 120 fonctions sur 186 sont saines. Réécrire, c'est jeter les deux tiers d'un travail qui fonctionne pour atteindre 13 % de code difficile.
• La couverture de 18 % condamne la réécriture. Sans tests, rien ne décrit le comportement attendu ; la spécification du module, ce sont sept ans de cas particuliers inscrits dans son code. Une réécriture les redécouvrirait un par un, en production. C'est l'argument décisif, et c'est aussi pourquoi la première étape du plan porte sur les tests.

On acceptera la position inverse si elle est défendue par des éléments absents du tableau de bord et posés en hypothèse : technologie en fin de support, impossibilité de recruter sur ce langage, changement de modèle métier rendant le périmètre obsolète. C'est la qualité de l'argumentation qui est notée.

4. Plan de reprise en quatre étapes.

L'ordre compte et il est noté : le filet avant la découpe. Un plan qui commence par l'extraction de fonctions sur du code non testé est un plan qui parie, et il perdra le point.

5. La porte de qualité. Sur le code nouveau ou modifié uniquement :

• couverture des lignes nouvelles ou modifiées : 80 % au minimum ;
• duplication introduite : aucune ;
• aucune fonction nouvelle au-dessus de V(G) = 10 ;
• aucune vulnérabilité ni aucun défaut bloquant ajouté.

Le périmètre est le point noté. Posée sur la totalité du dépôt, une exigence de 80 % de couverture est inatteignable à partir de 18 %, donc elle sera contournée ou désactivée avant la fin du trimestre. Posée sur le code touché, elle est tenable dès la première demande, et elle fait remonter la qualité exactement là où l'équipe travaille. C'est la règle du cliquet : on n'empêche pas la dette existante, on empêche la dette nouvelle.

6. Les cas de test des six fonctions.

6 × 27 = 162 cas de test au minimum.

C'est un plancher, et c'est le sens de la question. La complexité cyclomatique donne le nombre de chemins indépendants, donc le minimum pour couvrir les branches ; elle ne couvre ni les valeurs limites de chaque seuil, ni les combinaisons de données, ni les cas d'erreur d'infrastructure. En pratique, on dépassera largement ce chiffre.

Et ce chiffre est aussi le meilleur argument de l'étape 2 du plan : 162 cas pour six fonctions est le prix du filet si on les laisse telles quelles. Après découpe, les mêmes branches se répartissent sur des unités de V(G) = 3 ou 4, chacune testable en quelques cas lisibles, et le total nécessaire ne bouge presque pas pendant que l'effort d'écriture, lui, s'effondre.