⚠️ Lisez cette lettre dans votre navigateur
pour profiter des corrections de dernière minute
Les liens marqués avec 🔒 sont accessibles seulement aux membres de Theodo.
Centre de formation Craft
Je parle ici de mes activités transverses au sein de Theodo.FinTech
Nos tech-leads ont beaucoup de responsabilités : faire progresser leurs devs, résoudre les petits et grands problèmes des projets, collaborer avec le métier pour élaborer les meilleures fonctionnalités etc.
Le système de classe inversée que nous avions adopté pour leur propre formation était un fardeau supplémentaire et c’est sans surprise que ce système s’essouffle.
Nous mettons donc en place un nouveau système : les formations prendront la forme d’ateliers pratiques durant lesquels nos tech-leads travaillerons leurs compétences en bâtissant une application liée à la finance.
Cet atelier ne nécessite pas de préparation de leur part. De plus nous en profitons pour fusionner deux cérémonies du précédent agenda.
Nous espérons ainsi gagner en efficacité et inciter les TL à faire ruisseler ces compétences sur leurs devs.
Améliorer sa pratique
Quelques réflexions issues de mes observations sur les projets
Import *
Dans la précédente édition j’indiquais que j’étais promoteur des import * (import à la demande) en Java. On m’a fait remarquer que cette position n’allait pas de soi et que j’aurais pu développer. Voici donc mon point de vue.
Tout d’abord permettez moi d’évacuer une idée fausse : la section des imports n’est pas conservée dans les fichiers compilés. Les import à la demande n’ont donc aucun impact sur les performances de l’application.
A quoi sert la section des imports ?
Si vous êtes un compilateur 🤖
Elle vous sert à lier les méthodes et les champs à la bonne classe. En effet dans le classpath entier les collisions sont fréquentes.
En revanche une classe a rarement besoin d’utiliser des classes ayant le même nom (à l’exception des Mappers).
Si vous êtes un humain, la plupart du temps elle ne sert à rien 🙈
c’est pour ça que les IDE ont tendance à masque cette section.
Mais parfois, elle est utile quand même !
Personnellement les imports m’aident à me faire une représentation de l’architecture de l’application. Par exemple si je vois ceci :
package com.company.myapp.domain;
...
import com.company.myapp.infra.adapters.*;J’en déduis que l’application a probablement une architecture hexagonale, qu’elle a un sérieux problème puisque son domaine a une dépendance vers l’infrastructure, et qu’elle n’utilise probablement pas ArchUnit pour préserver son architecture 🙂
Autre exemple :
package com.company.otherapp.payment;
...
import com.company.otherapp.catalog.*;
import com.company.otherapp.shipping.*;J’en déduis que je suis dans une application qui a des domaines “payment”, “catalog”, “shipping”, probablement une application qui vend des produits donc. De plus le domaine “payment” dépend des deux autres. Cela peut être mauvais signe d’avoir des couplages entre beaucoup de domaines. Ici c’est peut-être justifié. Les imports m’incitent à diriger mon attention sur ces couplages.
Bref, ce qui m’intéresse dans la section des imports ce sont les collaborations entre packages. Avoir la liste de chaque classe de chaque package n’ajouterait que du bruit.
Voilà pourquoi je préfère les imports à la demande.
Plusieurs éléments renforcent ma conviction que les imports à la demande vont dans le sens de l’histoire :
Les imports de modules de Java 23 dont je parlais dans ma dernière NL.
En C# on n’a pas de packages, on a des namespaces. Dans une classe il est possible d’importer un namespace mais pas de désigner individuellement les classes. Autrement dit en C# on a uniquement des imports à la demande.
Argument d’autorité au carré : dans ce talk Kevlin Henney cite Robert Martin et tous les deux se prononcent en faveur des imports à la demande.
Est-ce qu’il y a des inconvénients à l’import à la demande ?
Parmis les arguments contre l’import à la demande, les confusions potentielles, typiquement java.util.Date et java.sql.Date qui ont la même interface mais pas le même comportement, ou java.awt.List et java.util.List qui ont quelques méthodes en commun.
On m’a aussi raconté l’histoire d’un renommage dans un IDE qui avait entraîné une collision de noms dans un autre endroit de la code-base.
Personnellement je n’ai jamais rencontré de bugs causés par ces confusions car le compilateur nous prévient très rapidement qu’on utilise pas le bon type, avant de pousser le code sur l’outil de versionning.
De mon point de vue, la balance penche clairement en faveur de l’import à la demande. Et vous ?
Veille
Quelques pépites que j’ai envie de partager avec vous
IntelliJ 2024.2 est sorti !
Deux minutes pour faire le tour des principales nouveautés :
La “grepabilité” : à quel point votre code est-il cherchable ? Cette métrique est un peu plus difficile à mesurer que “le nombre moyen d’indentations par ligne” mais elle mérite qu’on s’y intéresse ! Merci MarineMB de m’avoir transmis cet article :
Puzzler
Ici un petit challenge pour apprendre en s’amusant !
Réponse à l’énigme précédente
Les trois scripts suivants sont très semblables. Pourtant leurs exécutions donnent des résultats très différents :
var babyAge = 1;
{
var babyAge = 2;
}
console.log(babyAge); // Affiche 2let babyAge = 1;
{
let babyAge = 2;
}
console.log(babyAge); // Affiche 1let babyAge = 1;
{
var babyAge = 2;
// ^ SyntaxError: Identifier 'babyAge' has already been declared
}
console.log(babyAge);Les mots clé let et var servent tous les deux à déclarer des variables, mais la ressemblance s’arrête là :
var
Le scope de la variable est le corps entier de la fonction
La variable est visible même avant sa déclaration avec la valeur
undefinedLa variable peut être déclarée plusieurs fois
Une variable déclarée à la racine (en dehors d’une fonction) est ajouté à l’objet global
let
Le scope de la variable est le bloc qui contient la déclaration
La variable n’est pas lisible avant sa déclaration (tenter de la lire provoque une
ReferenceError) ou après la fin du bloc (même erreur)Il n’est pas possible de redéclarer la variable (
SyntaxError) même si la première fois elle a été déclarée avec le mot clévarUne variable déclarée à la racine (en dehors de tout bloc) est visible globalement mais n’est pas ajouté à l’objet global
Énigme du jour
Voici quatre expressions, saurez-vous deviner comment JavaScript les évalue ?1
Et surtout saurez-vous l’expliquer ?
[] + []
[] + {}
{} + []
{} + {}J’ai piqué cette énigme à cette excellente vidéo de Gary Benhardt :
https://www.destroyallsoftware.com/talks/wat