-Bonjour à tous.
On va s'intéresser à la critique de code automatique
qui est intégrée à Pharo.
On va réutiliser pour ça le package "MyCounter"
qu'on a développé dans le redo numéro deux.
Vous pouvez voir qu'on a toujours nos tests, nos méthodes.
La critique de code automatique, c'est ce qu'on a, par exemple,
ici : j'ai modifié la méthode "increment".
On a une méthode qui n'est pas définie, qu'on appelle.
Vous pouvez voir un panneau "attention" sur le côté gauche
qui vous indique que ça n'a pas fonctionné.
Et vous avez aussi des explications en dessous :
"Super and self Messages sent but not implemented"
et "Messages sent but not implemented."
Ça veut dire qu'il ne comprend pas la méthode indéfinie.
C'est normal, on ne l'a pas définie.
Vous pouvez avoir plus d'informations sur ces warnings.
Par exemple, celui-là, il va vous dire
que si le message envoyé à self ou super
existe dans la hiérarchie,
il n'existe pas, car on ne l'a pas défini.
Pareil ici, le message est envoyé, mais pas implémenté.
Et ce que vous pouvez faire d'intéressant,
c'est, par exemple, pas avec cette méthode-là...
Mais si on appelle, par exemple, "self halt",
qui est un appel au débogueur, et qu'on sauve,
on va avoir un message en warning qui va apparaître aussi :
"Debugging code left in methods",
donc il nous reste du code de débogage.
On voit l'explication, il reste des breakpoints, logging statements.
On a, cette fois-ci, l'option de le réparer directement.
On peut regarder ce qui va se passer.
Si on le répare automatiquement, on a la recherche de mots
sur la méthode "increments"
et il va supprimer la ligne qui fait appel à ce segment.
Très bien, maintenant, on va remettre notre méthode qui n'est pas définie
et on va utiliser la critique de code directement sur notre package.
Pour ce faire, vous faites clic droit dessus
et vous allez dans Browse critiques.
Browse critiques va nous ouvrir un Critic Browser
qui contient une liste de règles
qu'il va mettre en application sur notre package
pour voir si elles sont respectées.
Il y a pas mal de règles.
Ici, elles n'ont pas été utilisées, puisqu'on ne s'en sert pas.
Mais on peut voir, par exemple, qu'il y a des soucis, des bugs.
Ça, ce sont les deux warnings qu'on a pu voir tout à l'heure.
Et vous avez la possibilité, à l'aide de ce Critic Browser,
de définir les faux positifs, de marquer comme faux.
On va dire que cette règle, on sait que c'est faux,
donc on la marque comme fausse.
Il faut cliquer ici pour la marquer comme fausse.
Vous avez aussi la possibilité
de sauver ces critiques pour plus tard,
de conserver les faux positifs que vous avez annotés pour plus tard.
Vous pouvez le faire en cliquant ici.
Ça nous le met dans Manifests, très bien.
Vous pouvez voir, si on retourne dans le System Browser,
qu'une nouvelle classe a fait son apparition
qui, si on regarde du côté classe, va avoir les règles,
et qui nous permet de sauvegarder les règles
qu'on a pu établir sur notre package.
Ça, ça va vous permettre de le versionner,
et ça va aussi vous permettre de l'intégrer
à un site de développement continu
pour pouvoir lancer la vérification de ce Manifest
à chaque fois que vous changez votre code
et de vérifier que les règles ont été respectées.
Voilà, c'est une explication sur les outils que vous pouvez avoir
en dessous de votre code, qui l'analysent directement,
et un outil plus large qui analyse votre package
pour voir les règles qui sont respectées.
Vous pouvez sauvegarder cet outil dans un Manifest
et le versionner, l'intégrer dans un site de développement continu.