On se retrouve après un interlude sur le technical leadership pour un résumé de ma veille technique de la semaine !

Au programme cette fois un résumé des nouveautés intégrées à Java depuis la version 8, des conseils pour écrire du code maintenable et enfin une alternative à Postman directement au coeur de votre IDE JetBrains !

Java

Aller, on commence par cet article issu de Baeldung qui reprend dans les grandes lignes les modifications majeures apportées au langage Java entre la version 8 et 17.

On retrouvera notamment de grandes améliorations apportées aux String, surtout avec l’arrivée des text blocks permettant de créer des chaînes de caractère multilignes de manière simple et élégante.

Egalement au programme l’introduction des records qui permettent de créer en quelques lignes à peine des objets immutables, sans avoir à rédiger getters, setters, equals, hashCode ou encore toString.

Enfin, si je dois me limiter aux nouveautés que je te présente, j’aimerais parler de l’amélioration des messages des NullPointerException. Désormais, on pourra maintenant identifier directement l’origine du null lorsqu’une NullPointerException est lancée sur un appel chaîné.

L’article mentionne également l’introduction du pattern matching et des sealed classes que je te laisse découvrir !

Software Craft

On enchaîne sur un peu de craft avec quelques conseils d’Henrik Warne pour produire du code mainteable.

Henrik nous livre dans cet article sa définition d’un code maintenable et comment produire un code répondant à cette dernière. Pour lui, un code maintenable peut se résumer à ceci : il est facile à changer, et donc facile à comprendre.

C’est bien de le dire, encore faut-il y arriver. Henrik explique ce qui, dans son expérience, fait qu’un code lui est apparu comme facile à maintenir.

Un code dont apparaissent les différentes étapes : lorsqu’on démarre la lecture d’un algorithme on doit directement avoir une idée de ce qu’il fait, juste en le parcourant rapidement. Pour cela, il est important de découper le code à l’aide de méthodes et de ne pas simplement jeter là toutes les lignes composant l’algorithme.
Un code testé : qui permet donc de faire tourner le logiciel, sans avoir à le manipuler. De plus, on documente ainsi les fonctionnalités de ce dernier.
Un code avec des noms clairs et parlant : les noms doivent véhiculer des concepts, métiers idéalement.
Un niveau de logging suffisant : les logs détaillent le déroulement de l’application, ils permettent de dégager un sens de ce qu’il se passe sans débugger.
Des commentaires : pas de ceux qui répètent ce que le code dit déjà, mais plutôt de ceux qui expliquent pourquoi on a écrit le programme d’une certaine façon.

Outils

On termine avec cet article de Julien Lengrand Lambert.

Il nous propose de remplacer Postman (ou autre client du genre) par IntelliJ et son client HTTP. La motivation principale de Julien ici est de ne pas avoir à sortir de son IDE, ce qui représente toujours une perte de temps et la nécessité de switcher de contexte.

De base le principe est simple, au lieu d’écrire nos requêtes HTTP dans Postman, nous utilisons le client HTTP de JetBrains pour rédiger des requêtes dans son format propriétaire et ensuite les exécuter. Le client offrant la possibilité de tester les réponses des requêtes, on a là un bon candidat pour remplacer Postman (si comme moi tu l’utilises de manière très basique).

Mais Julien a voulu aller plus loin, car Postman nous offre la possiblité de générer des requêtes sur base d’une spécification OpenAPI. Et là, ça manque du côté de JetBrains et de son client. Du coup, Julien a ajouté un générateur de requêtes pour le client JetBrains à ceux existant déjà sur OpenAPI Generator. Ainsi, il nous est possible de générer les requêtes au format de JetBrains en lisant le contrat OpenAPI de notre API.

Plus besoin de switcher de logiciel pour tester nos API : elle est pas belle la vie ?

Va lire l’article pour voir comment porter les tests rédigés dans un outil d’intégration continue !

Conclusion

Voilà qui termine cette semaine. Je profite du mot de la fin pour communiquer un peu sur le format.

Je me cherche un peu sur ce que je peux tenir de manière hebdomadaire. En termes de temps d’une part et de débit d’autre part. Quelle quantité fournir pour que ça reste jouable pour moi et intéressant pour toi ?

Du coup, je pense me limiter à trois ressources par semaine, que je te résume. Et si ça t’intéresse, tu vas voir le poste de l’auteur·ice !

En plus, de temps en temps (je pense à une fois par mois, mais je ne vais pas me lancer dans de veines promesses), j’écrirai un article sur un sujet qui me tient à coeur, pas lié à ce que je l’ai lu, écouté ou visionné !

Et puis ben, peut-être que ça changera encore… La vie c’est aussi et surtout du changement !

Nerthus

On My (Technical) Watch #8

Java

Software Craft

Outils

Conclusion

Sources