Code de qualité: appliquer des bonnes pratiques dans le développement logiciel

Anthony Ricaud, @rik24d ou anthony@ricaud.me

Julien Wajsberg, @jwajsberg ou julien@mozilla.com

Code de qualité: appliquer des bonnes pratiques dans le développement logiciel

Anthony et Julien Anthony Ricaud (@rik24d) & Julien Wajsberg (@jwajsberg)
Paris-Web, Le Beffroi, 17 octobre 2014

Mozilla a une mission

Firefox

Firefox OS : un OS mobile libre pour le web

Firefox OS

Pourquoi ?

Pourquoi ?

  • Qualité et maintenabilité
  • Réutilisation et trousse à outils
  • Techniques éprouvées du monde open source

Versions et tickets

Un gestionnaire de tickets

  • Libérer l'esprit
  • Partager les tâches
  • Documenter l'historique

Quelques règles importantes

  • 1 ticket = 1 tâche : correction de bug ou nouvelle fonction
  • Votre message de commit est important, il doit avoir la référence vers le bug :
    Bug 1082064 - [Messages] Prevent double DOMContentLoaded events r=schung
  • Ces règles permettent de travailler à plusieurs.

quelques bugtrackers

Revue de code

Revue de code

  • Diffuser les connaissances
  • Limiter le bus factor
  • Augmenter la cohérence de la base de code
  • Un premier filtre pour des bugs

Quelques règles

  • Le reviewer est responsable du code committé.
  • Ce n'est pas un linter

Les outils de revue de code

Voir la conférence suivante d'Agnès !

Agnès Haasser

Vérificateurs de code

But d'un linter

  • Permet de vérifier automatiquement des critères parfois arbitraires
  • Faire des choix arbitraires une bonne fois pour toutes, et s'y tenir
  • Pas de bikeshed, donc gain de temps

types de vérifications

  • On réintroduit un peu de rigueur dans des langages dynamiques
  • Globales, écrasement, fonction dans une boucle, this, bugs potentiels, =, ==
  • On trouve des linters pour chaque language : csslint, jshint, eslint, jscs, php-cs…

et sur un projet existant ?

  • Certains linters viennent avec un outil de correction automatique. Pas toujours joli mais efficace
  • On peut mettre en place une "fail list": on prend une photo de l'état existant, puis on avance pour l'améliorer.
  • On peut mettre en place un commit hook: à chaque commit, on vérifie si le changement n'introduit pas de problèmes.

Résultat du hook de commit

Tests unitaires

Principe

  • On isole une unité de code (souvent un fichier) et on le teste indépendamment des autres composants.
  • Permet de tester tout votre code sans effets de bord

Quelques intérêts

  • Un bug n'est corrigé qu'une fois. On est assuré qu'il ne reviendra pas dans la même forme.
  • Donne confiance pour faire des modifications
  • Écrire un test oblige à utiliser le code proprement dit. On fait donc une revue de l'API développée, voire on crée l'API en rédigeant les tests.
  • Est-ce que l'unité testée a l'air unitaire, ou bien regroupe-t-elle plusieurs responsabilités ?
  • C'est plus rapide de jouer les tests d'un fichier que de tester l'application à la main : on réduit le temps de feedback.

tests passed… with bad tests Image par Bernd Lörwald

Des tests unitaires en JavaScript

Étapes nécessaires

  • La première étape est d'écrire un premier test, même minimal
  • Les premiers tests ont beaucoup de valeur
  • Imposer l'écriture de tests pour les fichiers qui sont déjà testés.
  • Il faut que quelqu'un prenne le temps d'écrire les premiers tests pour chaque fichier de l'application.

Tests fonctionnels

Tests fonctionnels

  • Teste un scénario d'usage
  • Confiance que toutes les parties fonctionnent ensemble
  • Mais plus lent à tourner
  • Et ne donne pas la source du problème
  • Se concentrer sur les scénarios les plus critiques

Tests fonctionnels

  • Exemples : Selenium, PhantomJS, SlimerJS, CasperJS
  • 1re étape : Choisir un outil et écrire son premier test
  • 2e étape : Choisir les scénarios importants à tester

Intégration continue

Intégration continue

  • Faire tourner vos scripts à chaque commit
  • Un humain peut le faire
  • Mais une machine n'oubliera pas
  • Et le fera toujours de la même manière

Intégration continue

  • Vous saurez exactement quand un problème apparait
  • Vert : on bosse; Rouge : on corrige
  • Peut générer de jolis graphiques à afficher au bureau
  • On peut aussi faire tourner cela sur les patchs en cours

Intégration continue

  • Exemples : Travis, Jenkins, Build Bot
  • 1re étape : Avoir des scripts faciles à lancer à la main
  • 2e étape : Configurer un système pour lancer ces scripts

Générateur de styleguide

Générateur de styleguide

  • Le pendant code des styleguide designer
  • Permet de vérifier rapidement les changements
  • HTML minimal pour utiliser un composant
  • Rôle de documentation

Générateur de styleguide

  • Répertoire d'outils
  • 1re étape : Adopter lors d'un redesign de composant
  • 2e étape : Vérifier le guide lors des revues de code

Documentation au besoin

Documentation au besoin

  • Lorsqu'un problème survient, les messages d'erreur informent le développeur
  • Si un script ne trouve pas un navigateur, il suggère comment indiquer le chemin vers le navigateur
  • Si un script nécessite une librairie, il indique comment l'installer
  • Utiliser la formation des nouveaux employés pour l'inspiration
  • You should install gjslint to lint your patch https://developers.google.com/closure/utilities/docs/linter_howto

Gestion de la dette technique

Gestion de la dette technique

  • Elle ne peut pas être de 0.
  • C'est un investissement pour demain. On choisit une solution plus simple aujourd'hui car on ne connait pas les besoins de demain.
  • Ce n'est pas de la paresse.
  • Les réécritures sont plus efficaces si elles sont dans le cadre d'une fonctionnalité.

En conclusion

Choisissez dès maintenant une pratique à mettre en place avant Halloween !

Thanks

Red panda (Firefox) Photo by Yortw