Java est un langage de programmation encore répandu, bien adapté à la construction d’applications portables. Peut-être avons-nous encore quelques chose à en apprendre.
Par le passé, nous vous conseillions d’utiliser le constructeur pour injecter les dépendances avec Spring, et nous avons présenté Lombok.
Devinez…
Ces deux compères s’entendent parfaitement, à une petite astuce près pour pouvoir utiliser le @Value de Spring.
Nous parlerons de tout ceci dans ce billet.
Il y a quelques mois, notre équipe a accueilli un nouveau venu. En plus de notre mission, il découvrait aussi Java, après quelques années en tant que développeur .NET. Parmi ses premières réactions, il y a eu plusieurs « Quoi, tu dois faire ça toi-même, en Java ? En .NET, c’est le compilateur qui le fait pour toi ! »
Il est vrai qu’en Java, le langage et les conventions amènent une quantité non négligeable de code à faible valeur ajoutée. Mais ne craignez pas ! Le chevalier Lombok vient à votre rescousse.
Poursuivre la lectureOn ne va pas discuter aujourd’hui le bien-fondé des tests. Je veux simplement vous suggérer une bibliothèque qui permet de les écrire différemment et, selon moi, les rendre plus compréhensibles.
Poursuivre la lectureIl y a quelques semaines, je faisais une revue sur le code d’un jeune développeur.
C’était un boulot impressionnant sur un sujet qu’il ne connaissait pas, sauf sur un point : toutes les impressions utilisaient System.out.println().
C’est compréhensible : c’est ainsi que les développeurs Java apprennent à coder, tout comme les développeurs Python font leurs premiers essais avec print.
Mais ce n’est pas une solution pratique pour une « véritable » application.
Récemment, un collègue m’a dit avec un grand sourire : « J’ai un candidat à évaluer. Il a mis J2EE sur son CV, mais c’est pas possible, il est trop jeune. Moi, j’aurais pu faire du J2EE, pas lui. »
C’est une plaisanterie assez récurrente entre techniciens Java assez expérimentés : il n’est pas rare pour les candidats d’entendre J-2-E et de penser qu’on n’a pas prononcé le second par élision. Ce n’est pas le cas : on pense aujourd’hui bien plus souvent JEE que J2EE, mais il y a un passé pour justifier cette erreur.
Poursuivre la lectureSi vous utilisez Spring depuis longtemps, ou si vous copiez-collez quelques tutos ou solutions trouvés sur la toile, vous avez certainement quelques champs privés annotés avec @Autowired.
Ça fonctionne, mais il y a une meilleure façon de faire.
Quand vous concevez un programme Java qui va se connecter à une base de données, vous avez probablement besoin d’un pilote JDBC. Quand cette base de données est un produit Oracle, vous gardez le O et ça devient OJDBC.
Pendant des années, je me suis contenté d’utiliser la version sélectionnée par un architecte. Puis je suis devenu l’architecte et il m’a fallu comprendre quelle version choisir. Ce n’est pas vraiment compliqué, seulement pas très bien expliqué. Je vais donc tenter d’apporter ma contribution…
Poursuivre la lectureCette année m’a donné l’occasion de discuter avec des personnes d’horizons différents. Parmi celles-là, des responsables techniques, des encadrant·es techniques, des architectes… Vous voyez l’idée. Au cours de ces échanges, j’ai entendu une remarque récurrente, dont je craignais jusque-là qu’elle ne soit l’expression de ma propre nature exigeante.
Mais non ! D’autres l’ont remarqué et partagent mon avis. Celui-ci se résume de la façon suivante : une nouvelle génération de développeurs / développeuses est arrivée sur le marché. Ils aiment faire les choses rapidement et le fonctionnement profond des choses ne les intéresse pas. Ceci se coordonne avec une époque où les frameworks fleurissent, nous promettant de développer mieux, plus vite et avec plein de magie qui nous évite de devoir comprendre ce qui se cache derrière ces astuces.
Poursuivre la lecture