#3. Opacité du build

De plus, Lombok va nécessiter une passe de précompilation pour générer le code « caché » par les annotations. Ce qui signifie… que le développeur n’a pas accès à ce code, ne peut pas placer de breakpoints et peut difficilement tracer les piles d’appels, que ce code n’est ni modifiable, ni testable, ni documenté (commenté). Des outils d’analyse statiques comme SonarQube seront donc toujours mécontents, entre coverage insuffisant et appel à des méthodes « qui n’existent pas ». De plus, cette passe de précompilation nécessite un plugin extérieur au code, qui soit installé soit dans l’IDE soit dans la configuration maven / gradle. Ce qui signifie qu’une personne sans cette dépendance (extérieure au code!) ne peut pas compiler le projet. Un projet sous Lombok impose l’utilisation de toute la grappe Lombok. Ce qui implique que si l’IDE nécessite une mise à jour et que le plugin n’est plus / pas encore compatible, bye bye le projet.

Et le code généré par Lombok repose sur une utilisation un peu douteuse de l’API java. Premièrement, l’API interne utilisée repose sur des méthodes disponibles dans seulement 2 compilateurs. Personne ne sait si il fonctionnera sur une autre version de JDK, ou si le projet utilise un compilateur différent. De plus, cette API interne utilise une API non publique, donc non supportée et sans assurance de maintien. De l’aveu même de l’auteur de Lombok : « It’s a total hack. Using non-public API. »

De plus, une bonne pratique est toujours de limiter le nombre de dépendances. Ajouter Lombok est donc une contre-performance dans beaucoup de domaines !

#4. Nos solutions conseils

Utiliser son IDE

La plupart des IDE modernes proposent des actions et des raccourcis clavier qui couvrent les cas les plus utilisés de Lombok: génération de getters, setters, constructeurs,….

Se poser la question du langage

Nous l’avons vu, changer la version de Java offre déjà une solution. Mais si le projet le permet, demandez vous si Java est la bonne solution. Les enfants spirituels de Java, Kotlin et Scala , proposent pas mal de sucre syntaxique (entre autre) palliant aux manques de Java. Comme ils compilent sur la JVM, on peut même faire cohabiter Java et l’un ou l’autre des langages (ou les deux !) dans un même projet, pour une migration en douceur.

Coder le métier et pas la technique

Le code généré par Lombok est principalement du code technique, sans intelligence métier. Pour reprendre l’exemple des getters et des setters, préférez une API interne à des dummy setters. Une API interne permet en effet de coder le métier dans l’objet concerné et de ne pas  déplacer cette logique dans des couches externes. Prenons un exemple, un élève possède une liste de notes et sa moyenne :

Sans intelligence, on doit déporter le calcul de la moyenne ailleurs, probablement à un endroit qui n’a pas la responsabilité de connaitre l’implémentation du calcul.

En somme, du code plus propre ne passe pas forcément par du code caché. Les outils de générations de code automatisées sont souvent pratiques et utiles dans une phase exploratoire, mais les projets à long terme se heurteront toujours à des contraintes non prévues, alors que des solutions simples existent pour un code propre dès le départ. Pour la maintenabilité de vos projets, arrêtez d’utiliser Lombok !

La programmation fonctionnelle, encore un buzz word ? Pas forcément ! Dans cette parole d’expert,…

Underscore et Lodash, deux classiques Dans le développement Javascript il y a deux librairies qui…

ARCA Computing

Société innovante d’ingénierie informatique. Studio de développement, formations, conseils et expertises basé à Bordeaux.

74 rue Georges Bonnac - Tour 3
33 000 BORDEAUX