# JWT ne devrait pas être le choix par défaut pour les sessions
par Thomas Broyer
Dans un monde d’applications web single page communiquant avec des APIs exposées par le serveur, on a besoin d’authentifier ces appels d’APIs. Dans un billet de blog de mai dernier, Evert Pot explique les avantages et inconvénients des JSON Web Tokens (JWT), et pourquoi ils ne devraient pas alors être notre solution “par défaut” pour gérer ces sessions utilisateurs.
# YAGNI, les exceptions qui confirment la règle
par Mathieu Petit
En programmation, quand on n’a pas besoin de quelque chose et bien on ne le fait pas, c’est le concept prôné dans l’acronyme YAGNI (You Aren’t Gonna Need It), mais il peut y avoir quelques exceptions à cette règle ; développer des fonctionnalités qui dépassent le besoin identifié peut devenir extrêmement utile pour la suite ou tout simplement pour le débogage, comme par exemple l’ajout d’une colonne “created_at” pour les tables d’une base de données. Cet article de blog de Luke Plant liste différents cas où ne pas suivre la règle YAGNI peut s’avérer judicieux.
# Revue de code
par Kevin Roy et Mathieu Sanchez
Chez Atol CD, la qualité de nos développements fait partie de notre ADN et l’un des moyens mis en œuvre est la revue de code. Nous partageons ici 2 articles décrivant ce processus et ses bénéfices pour les développeur⋅euse⋅s.
Le premier est un retour d’expérience d’une développeuse junior chez Pinterest. Elle revient sur les bénéfices de la revue de code (apprentissage, exploration du code de l’application) et, surtout, les échanges entre les développeur⋅euses qui en résultent. C’est peut-être ce dernier point qui est à notre sens le plus important : la revue de code est un vecteur social d’échanges.
Bien que l’article mette l’accent sur les avantages de la revue de code par une junior, il ne faut pas oublier que ces mêmes avantages s’appliquent lors de l’intégration d’un⋅e nouveau⋅elle développeur⋅se dans une équipe.
De la même manière, l’auteur du deuxième article témoigne de la manière dont a évolué sa revue de code dernièrement. En repartant de l’essentiel – que le code fonctionne – il propose que la simple analyse syntaxique ne suffit pas, car elle ne permet pas de comprendre pleinement la démarche prise par le⋅a développeur⋅euse et le problème qu’il⋅elle cherche à résoudre. Ce faisant, le⋅a reviewer⋅euse peut devenir moteur⋅rice dans les corrections et retouches éventuelles et donner des retours précis, construits, avec un objectif qui n’est plus un simple challenge syntaxique. La compréhension de la démarche de l’autre permet des échanges plus agréables et sains. L’équipe elle-même absorbe des méthodes de travail plus que de simples nouvelles lignes de code, et la compréhension globale de ce qui fait la qualité du produit livré au client ne s’en trouve que renforcée.
Dans l’absolu, ces deux articles véhiculent un message assez proche : comment peut-on faire de la revue de code une plateforme d’échange efficace, sociale, bienveillante et porteuse de sens.
# Flight rules for Git
par Guillaume Poittevin
Les règles de vol (flight rules) est un mécanisme de consignation des informations acquises sur le terrain par la NASA. L’idée est d’avoir des informations détaillées sur la marche à suivre face à de nombreuses situations.
Le principe a été appliqué à Git, disponible en français, vous y trouverez de nombreuses astuces pour sortir de situations plus ou moins critiques.
Laisser un commentaire