Les 2 outils ‘code quality’ que nous avons adoptés

La diversité de background et des habitudes des développeurs d’une équipe entraîne forcément de la diversité dans le code. Un changement de style peut être source de migraines, et personne n’a envie de se demander “cette fonction est en camelCase ou en snake_case ?”.

Heureusement, les linters sont là pour vérifier l’homogénéité de ces “petites” choses, et pour s’assurer que le code suit les conventions de la communauté (par défaut en tout cas). Ils peuvent être configurés pour chacune de leurs règles afin de s’adapter aux habitudes et buts de ton équipe. Et il est toujours possible de laisser passer ce qui est identifié comme erreur, voire de les marquer comme invalides lorsque le robot se trompe (les robots n’ont (presque) jamais tort).

Ils sont une partie importante de notre git flow, détaillé ici.

Cylon raider, heu, non, un Linter cherchant des typos dans ton code (illustration)

S’assurer que le code suit des standards déterminés et acceptés par l’équipe facilite la maintenance, les code reviews, l’arrivée de nouveaux développeurs et offre un outil de plus pour la montée en compétences des plus juniors. C’est une première étape, relativement simple, pour commencer à travailler sur la qualité de code.

Dans cet article, nous verrons comment mettre en place deux outils qui utilisent des linters :

• overcommit pour installer des hooks git, évitant ainsi les commits ne suivant pas les conventions dans les pull request ;
• Code Climate Quality pour ajouter des contrôles aux pull requests, des statistiques et des tendances pour le long terme.

Assez parlé!

Installation et configuration d’overcommit

Comme dit ci-dessus, overcommit permet d’installer des hooks git qui peuvent bloquer un commit ou un push si un contrôle ne passe pas. Beaucoup de contrôles peuvent être activés, comme tenter de pousser une branche protégée, le format des messages de commit, le résultat de linters, etc. Dans ce chapitre, nous nous concentrerons particulièrement sur RuboCop.

Overcommit râle suite à un message de commit vide (exemple concret cette fois)

Installer la gem et activer les hooks

Si tu utilises bundler, ajoute ceci à ton Gemfile

group :development do
  […]
  gem 'overcommit', require: false
  […]
end

Sinon, installe simplement la gem $ gem install overcommit.

C’est la même chose pour RuboCop, si tu ne l’as pas déjà installé.

Ajoute la gem au Gemfile (si elle n’y est pas déjà présente)

group :development do
  […]
  gem 'overcommit', require: false
  gem 'rubocop', require: false
  […]
end

Ou installe-la via $ gem install rubocop.

Puis lance $ overcommit --install dans ton projet pour installer les hooks. Facile, non ? Oui, enfin, overcommit n’est pas capable de deviner les langages que tu utilises, ni quels linters tu souhaites activer, il faut faire un poil de…

Configuration

Crée un fichier .overcommit.yml à la racine du projet. Jette un œil à la configuration par défaut et change ce qui t’intéresse dans le fichier que nous venons de créer. Voici un exemple pour activer RuboCop :

PreCommit:
  RuboCop:
    enabled: true
    requires_files: true

Il est nécessaire de signer la configuration à chaque fois qu’elle change, il suffit de lancer $ overcommit --sign. Ceci permet de s’assurer que chacun s’accorde avec tous les changements faits sur sa machine concernants overcommit.

Et voilà ! Tout fichier ruby qui passera dans un commit sera désormais validé par RuboCop.

Bad line no commit! — RuboCop

Pour répandre la bonne parole à toute l’équipe, ajoute $ overcommit --install et $ overcommit --sign au README.md !

Laissez passer

Imagine-toi en train de retravailler un vieux bout de code. Tu l’as amélioré, mais ce n’est pas parfait et tu arrives au bout de ta timebox. Les linters risquent de ne pas apprécier certaines parties du code que tu essaies de soumettre. Et bien, il est possible de demander à overcommit d’ignorer quelques contrôles pour laisser passer un commit. Pour ce faire, il faut utiliser la variable d’environnement SKIP.

Retravailler du vieux code et ignorer les linters (illustration des sentiments du développeur)

Par exemple, $ SKIP=RuboCop git commit si tu souhaites ignorer RuboCop lors d’un commit. Sépare les outils par une virgule pour en ignorer plusieurs, par exemple $ SKIP=RuboCop,Reek git commit.

Mais il est toujours important de s’aligner lorsqu’un collègue ignore des erreurs de style. C’est pourquoi nous utilisons…

Code Climate Quality : présentation et installation

« Quality de Code Climate propose une relecture automatisée de code, indiquant la couverture des tests, la facilité de maintenance, etc., vous permettant de gagner du temps et de fusionner les pull requests en toute confiance. » (traduction libre par moi-même) (NB : cet article n’est affilié d’aucune façon à Code Climate). Le fonctionnement habituel utilise les webhooks de github et s’intègre automatiquement aux pull requests. Fournissant ainsi un bel outil qui fait une sorte de première review automatique, permettant aux relecteurs de se concentrer sur le concret, ou d’accéder à de la documentation. En plus vous aurez de jolis graphiques de progression de votre application sur le plus long terme :)

Code Climate quand il n’aime pas trop un commit

Code Climate ajoutera un rapport à chaque pull request avec un joli résumé des problèmes que celle-ci introduit et corrige. En plus des linters et des détecteurs de code smells, un outil que j’apprécie particulièrement dans Code Climate est le moteur de duplication, capable de détecter du code similaire n’importe où dans une application. Très utile pour s’assurer de garder une application DRY ! (DRY fait partie de notre manifeste, à découvrir ici)

Un feedback positif de plus lorsqu’on réduit de la dette technique !

Augmenter la couverture de tests est d’autant plus agréable !

L’installation est très simple et se passe principalement dans le navigateur web. Les options avancées nécessitent un fichier .codeclimate.yml à la racine du projet, mais il est possible de se lancer sans ça. Le guide officiel est très bon, donc je ne vais pas le recopier ici.

Comment nous utilisons overcommit et Code Climate Quality ensemble

Notre configuration nous permet d’être plus stricts localement via overcommit, et plus flexibles avec codeclimate. Par exemple, overcommit lance un détecteur de code smells appelé Reek, que nous n’avons pas activé sur Code Climate. Aussi, les specs sont ignorées sur code climate, mais overcommit les passera en revue.

Avec Code Climate Quality, overcommit devient principalement un outil de productivité : il n’est pas nécessaire de pousser ses changements et d’attendre que le robot les ait contrôlés. Les commits “Fix rubocop”, qui rendent difficile la code review commit-par-commit, ont disparu.

Et la relecture humaine, dans tout ça ?

Nous utilisons ces outils pour automatiser une partie de la relecture de code et pour garder de fortes conventions de qualité de code au sein de l’équipe. Ces robots sont vraiment bons, et il y a probablement d’autres outils géniaux dans l’univers, il s’agit de trouver ceux qui vous conviennent au mieux.

Ceci dit, les relectures automatiques ne remplacent pas les relectures de code par des humains. Il est possible d’écrire du code sans erreurs détectables par un linter ou par un détecteur de code smells, mais qui n’a absolument aucun sens ou aucune utilité. Il est aussi possible d’avoir deux fichiers qui font grosso-modo la même chose, par exemple dans le cadre d’un A/B test, ce qui crée de la duplication fonctionnelle, indétectable par un robot. Faire relire le code par un humain permet aussi d’améliorer votre bus factor.

Si tu souhaites avoir ton code revu par des humains et des robots, tu peux venir développer avec nous !

Captain Contrat recrute !