Dans cette vidéo, je voudrais vous montrer que Pharo
offre aussi la possibilité d'avoir un assistant qui va
vérifier la qualité de votre code, et qu'on appelle soit
le Quality Assistant, soit Code Critics qui va faire
tourner automatiquement des règles de bonne conduite sur votre code.
Regardons ça un petit peu de plus près.
Vous avez vu qu'à chaque fois que je browse une classe,
vous avez ce petit pop-up qui s'affiche.
En fait, ce qui se passe c'est que de manière
automatique, quand je suis en train de browser, on va
prendre peut-être CubHelix pour voir, vous avez cette
petite zone-là dans laquelle s'affiche des
indications. Et quand je le fais sur le package aussi.
Alors comme c'est un petit peu difficile de trouver un
exemple probant, on va utiliser notre propre code et on
va écrire du code pas beau dedans, comme ça vous allez le voir.
Donc, si je vais dans Counter, imaginons par exemple que
je laisse du code de debugage,
là le système me dit automatiquement deux choses.
Il me dit qu'il y a du code de debugage qui est resté
dans la méthode. Qu'est-ce que je vais pouvoir faire?
Je peux comprendre d'où vient cette règle.
Donc si je clique dessus, il me dit utilise des
breakpoints, ce n'est pas forcément intelligent dans du code de production.
Il peut me dire, je vais résoudre automatiquement ce problème.
Essayons, on va voir.
Il me dit, il faut enlever ça.
Oui, ok, très bien.
Et du coup, je n'ai plus ce problème-là.
Donc là, vous avez vu qu'on le fait alors que je suis en
train de programmer. Finalement, le système va réagir.
Maintenant, il y a une autre façon de le faire, ce que je
peux faire c'est ouvrir le Critic browser sur mon package.
Là, c'est un tout petit package.
On va faire une erreur histoire qu'on puisse la voir.
Donc là, si je fais "self halt"
ou par exemple je vais faire une autre méthode.
Je vais faire une méthode "increment3" et je vais
invoquer une méthode qui n'existe pas.
On va l'appeler "foofoo".
Donc là, c'est rouge mais imaginons que je ne m'en soit
pas rendu compte dans un état de fébrilité.
Je vais utiliser le Critic browser
sur mon code et donc là ce que me montre le critic
browser c'est l'ensemble des règles.
Donc, il y a quand même pas mal de règles avec des
explications. Si vous avez ce code-là, alors à ce
moment-là il vaut mieux l'utiliser comme ça, si vous avez
une affectation à l'intérieur.
Vous avez plusieurs sortes de règles.
Vous avez des règles qui sont liées à l'optimisation, des
règles qui peuvent potentiellement identifier des bugs fixes.
Vous avez des règles qui identifient des vraies.
Donc là, par exemple, si je viens ici, je vois le code.
Donc, je peux browser ma définition comme ce qu'on a fait
tout à l'heure, ou je peux le transformer.
Et donc, le warning a disparu.
Maintenant, ce qui est important de voir, c'est que
toutes ces règles sont basées sur des heuristiques.
Ça veut dire que, parfois, vous faites des choses qui ne
sont pas très catholiques. Vous le savez et il faut
laisser comme tel dans le système.
Ce qu'on peut aussi faire, on peut dire, ça c'est un faux
positif. Imaginons que j'ai un message
"foofoo" et que je sais que je veux le garder, je vais
pouvoir dire cette règle est fausse pour cette
méthode. Je vais le marquer.
Là c'est en gris qu'est-ce que ça veut dire?
Ça veut dire que moi plus tard, je vais pouvoir regarder
et me dire peut-être que cette règle était vraie et que
ça faisait du sens de la
revisiter.
Ce qu'on peut faire, en fait on va pouvoir sauver les Critics.
Ça veut dire qu'on va sauver les résultats des règles et
aussi des faux positifs.
Quand on a écrit que quelque chose était faux, on ne veut
pas qu'à chaque fois qu'on fasse tourner des règles, le
système nous le dise en permanence.
Donc quand je sauve les critiques, il va les mettre dans un Manifest.
On va voir ça, Là, j'ai mon Manifest qui va être
versionné avec le système.
Il ne faut pas aller voir comment c'est codé à l’intérieur, on s'en fiche.
Le Manifest, ça permet de coder des choses mais peu importe.
Ça, vous n'y touchez pas, c'est le code critic qui va l'utiliser
pour les prochaines exécutions.
Et donc, vous avez un Manifest par package.
Quand vous allez versionner le code, vous allez
versionner vos Manifests avec, et quand vous allez
refaire tourner le code critique, automatiquement, il va
prendre en compte les faux positifs et toutes les
méta-remarques que vous avez mis dedans.
Donc, ce qui est vraiment intéressant avec ces règles de
qualité, c'est que Pharo va l'intégrer dans un processus de développement.
Ce qu'on va faire c'est qu'on va faire en sorte qu'on a
des serveurs Jenkins qui vont, à chaque fois que vous
allez commiter votre projet, le charger et faire tourner
automatiquement ces règles de qualité pour vérifier que
votre programme suit bien ces règles.