La poésie du code

Pour écrire du code, vous devez être capable de lire du code existant, de l’enrichir par votre instinct. Le code peut concerner n’importe quel sujet, un site éditorial, un site ecommerce, une interface web, etc. Le tout répond à un besoin. Cela peut paraître intimidant au départ, déstabilisant mais à force que votre expérience augmente, votre confiance s’installera. Toutefois, il vous faudra toujours vous inspirer des multiples projets au sein de votre équipe mais également présents sur github, ou des sites spécialisés. A votre tour, il sera envisageable de partager votre code, votre savoir-faire.

DoD (Definition of Done)

Qu'est-ce ?

Ce sont des règles mises en place par l'équipe et pour l'équipe qui permettent de s'assurer que le travail accompli est bien terminé et fiable.

Pourquoi ?

Pour réduire les risques sur les livrables (Limite le coût du rework).

S'assurer que les objectifs sont bien atteints (limite les tentions entre la Team Dev et PO/Client).

Pour que la satisfaction client soit optimale.

Intégrer SonarQube à vos projets .Net

On est tous confronté à l'exigence d'avoir une certaine qualité de nos applications. Mais souvent pris par les délais, on cherche à minimiser (voir négliger) la charge demandée par cela. Ainsi, je vous propose dans cet article un moyen rapide de mettre en place Sonar sur vos projets .net et par la suite de concentrer votre charge surtout sur l'analyse et suivi des indicateurs. Mais avant de commencer, il semble nécessaire de rappeler quelques notions liées à la qualité logicielle.

SonarLint, codez connecté avec SonarQube

sonarlint-black-256

Lors d'un projet, la qualité est aujourd'hui devenue une des priorités. Concernant celle du code source, de nombreux outils existent pour nous guider. Aujourd'hui nous allons aborder le sujet du plugin SonarLint en lien avec SonarQube.

Mais avant d'aborder ce qu'est SonarLint par rapport à SonarQube et en quoi celui-ci peut nous aider lors des phases d'amélioration du niveau de qualité du code de nos projets, voici un bref rappel sur SonarQube.

Vérifier les emails avec www.mail-tester.com pour éviter d’être considéré comme spammeur

keep-calm-and-stop-spamming

Sur un site web, il est assez fréquent que l'on soit amené à envoyer des mails suite à diverses actions. Dans nos développements, il nous incombe de faire l'habillage de ces mails, et ensuite de les tester sur différents clients de messagerie. Mais voilà, certains mails peuvent être considérés comme spams, je vous propose donc dans cet article de découvrir l'outil www.mail-tester.com qui vous permet de voir si vos mails sont considérés comme spams mais aussi d'améliorer vos envois.

Coder PSR-2 compliant sous Sublime Text

Sublime-Text-2

Pour ceux qui, comme moi, préfèrent Sublime Text aux IDEs bloatwares mais veulent tout de même appliquer un contrôle qualité sur leur code simplement par satisfaction personnelle (si si je vous jure ça existe) ou plus vraisemblablement pour s'assurer du respect des normes de vos différents projets, je vous propose d'installer un petit plugin assez sympa : Sublime PHPCS

Audit PHP : sécurité et bonnes pratiques

PHP_LOGO

Créé en 1994, PHP (Hypertext Preprocessor) est un langage de programmation très répandu sur Internet.

C'est un langage puissant, facile à aborder et permissif.
De ce fait, il est fréquent de retrouver des codes PHP qui ne respectent pas les normes élémentaires de sécurité et de bonnes pratiques.

Cet article est un aide-mémoire qui dresse une liste (non exhaustive) des points à contrôler dans le cadre d'une revue de code.

Devoxx France 2013 – Implémenter la qualité sur un projet Java

A l'occasion de Devoxx France 2013, j'ai assisté à la conférence intitulée « Implémenter la qualité sur un projet Java » présentée par Vincent Massol (profil github), contributeur du projet XWiki.

Vincent nous parle des bonnes pratiques dans la gestion d'un projet Java, en prenant comme modèle son expérience sur XWiki.

Stabilité de l'API

Il faut faire attention aux utilisateurs et même aux développeurs du framework.

Clirr est un outil qui casse la construction d'un projet s'il y a un changement dans une API. La comparaison peut se faire au niveau binaire ou au niveau du code source. Lorsque l'on a intentionnellement changé l'API, il faut documenter le changement pour qu'il soit ignoré par l'outil, qui signalera cela dans son rapport.

Voici quelques pratiques mise en place sur le projet XWiki pour la gestion de ses API :

  • Création d'un package 'internal' : Les classes/méthodes/attributs présents dans ce paquetage peuvent être visibles au sens Java mais le développeur ne doit pas les utiliser. S'il le fait quand même, il prend le risque que son code ne compile plus ou ne s'execute plus lors d'une nouvelle version de la librairie. Il ne faut pas oublier d'exclure ce paquetage de la javadoc et de l'analyse Clirr.
  • Gestion de la dépréciation dans l'API
    • Version courante : Utiliser l'annotation @Deprecated dans le code et le tag @deprecated dans la javadoc (voir aussi la documentation Oracle sur le sujet).
    • Future version : Déplacer le code déprécié vers des artefacts dont le nom se termine par "-legacy". Les classes dépréciées sont déplacées. Les méthodes dépréciées sont déplacées en utilisant AspectJ.
  • Gestion des nouvelles API : Celles-ci sont potentiellement instables. Il faut utiliser l'annotation @Unstable et préciser une limite de validité.

Attention à l'ajout de méthodes dans une interface ! Mais cela ne sera plus un problème à partir du jdk8, qui permet d'ajouter une implémentation par défaut sur une interface.

L'enfer des jars

Il arrive parfois que certaines classes soient dupliquées à l'exécution (même classes dans 2 jars présents dans le classpath). Lorsque les classes sont différentes, cela constitue un véritable problème qui peut être résolu en utilisant les plugins maven suivants :

  • duplicate-finder pour détecter les classes dupliquées.
  • enforcer pour forcer l'application de certaines règles (version du jdk, version des artefacts ...).

Tests de couverture

La librairie JaCoCo mesure la couverture des tests et, si la valeur est en dessous d'un certain seuil, la construction du projet échoue.

Attention : Certains tests peuvent être non déterministes et le taux de couverture peut varier d'une exécution à l'autre, sans modification du code. C'est notamment le cas lorsqu'on utilise la classe ConcurrentHashMap avec plusieurs threads. Vincent propose de rajouter un paramètre nommé threshold (voir la discussion sur le projet github de JaCoCo) pour définir une marge de tolérance par rapport au seuil.

Faux positif/négatif

Un faux positif correspond à un test qui passe alors qu'il aurait dû échouer. A l'opposé, un faux négatif correspond à un test qui ne passe pas alors qu'il aurait dû passer. Exemple de faux négatif : crash, lenteur du système. Voici quelques plugins Jenkins qui peuvent servir dans ces situations :

  • Groovy Postbuild : Ce plugin permet de contrôler le résultat d'un build et éventuellement rajouter un badge sur le sommaire du build et/ou l'historique des builds. Dans notre cas, il peut rechercher du texte dans les logs afin de vérifier qu'un test passe réellement.
  • Email-ext : Ce plugin permet d'étendre la fonctionnalité de notification par email. On pourrait, par exemple, annuler l'envoi d'email lorsque le système est lent (mais l'interface web de jenkins continuerait de montrer le problème).
  • Scriptler : Ce plugin permet de centraliser les scripts Groovy d'une instance Jenkins. On peut aussi jouer un script sur tous les jobs jenkins ou sur tous les noeuds/esclaves. Remarque : le plugin gère 2 sites de partage de scripts : jenkins-scripts ou scriptlerweb.

Bug tracking

Avec le temps, les courbes de bugs ouverts et bugs corrigés tendent à diverger. Pour atténuer cette divergence, le jeudi a été déclaré jour de correction des bugs par les contributeurs du projet XWiki. Afin de diminuer rapidement les bugs ouverts, ceux-ci commencent par fermer les bugs corrigés et les bugs en doublon. Ensuite, ils corrigent les bugs faciles et requalifient certains bugs en évolution. Pour voir le résultat, consulter le tableau de bord du projet XWiki.

Pour terminer, Vincent souligne qu'il faut paramétrer les outils afin qu'ils fassent échouer un build lorsqu'une mesure est mauvaise. Sans cela (paramétrage pour émettre un simple avertissement), on va avoir tendance à ignorer le message, puis laisser le problème empirer et finalement ne jamais le corriger.

Forum PHP 2012

Le forum PHP 2012 s'est déroulé les 5 et 6 juin. Organisé par l’AFUP (Association Française des Utilisateurs de PHP), l'édition 2012 était très attendue après l'absence de l'événement en 2011. Les thèmes ont été très larges : qualité, performance, cloud, tests unitaires, etc.