Spring, générateurs, des amis qui vous veulent du bien
Aujourd’hui, j’ai vu passer un tweet qui fut la goutte d’eau après des mois de frustrations avec Spring. Il faut que je vous parle de Spring. Spring ? C’est LE framework web Java. Il faut dire que c’est tellement simple, surtout avec Spring Boot et un générateur du type JHipster. Simple, rly ?
Simple, rly ?
On le sait tous au fond de nous, Spring n’est pas simple. Sous le capot, ça fait beaucoup, beaucoup de choses.
Des états mutables partout, rapidement des dizaine de classes dans le projet (surtout quand on rajoute bonne vieille archi N tiers resources services repository DAO DTO VO WTF, et les mappers entre chaque classe), un arbre de dépendance chaotique avec des conflits permanents entre dépendances (merci les spring boot starter pour rajouter un peu plus de chaos dans l’arbre de dépendance), toujours 10 façons de faire les choses, des montées de versions compliquées, des surcouches de surcouches, l’injection de dépendance qui devient vite un bordel sans nom…
Même les experts sur la techno passeront de longues heures de debugging dans les tréfonds du framework et de Stackoverflow, car au fond personne ne sait vraiment pourquoi son bean est à null.
Cette image de Kyle Kingsbury tirée d’un talk sur jepsen résume bien la situation
Rajoutez à tout ça du Spring Security, du Spring Data, un Spring Cloud, des abstractions louches du type Spring Kafka, un peu d’AspectJ ou encore un bon vieux Hibernate des familles, et bienvenue en enfer.
Bon, au moins, vous aurez le temps de prendre votre café le temps que votre microservice démarre.
Les générateurs
Mais heureusement, les générateurs type JHipster sont là pour nous sauver. En un clic, j’ai un projet qui démarre.
Un projet qui démarre, mais avec une archi prédifinie probablement non adaptée à votre use case et difficilement modifiable sans tout péter. Un projet qui utilise vous ne savez quoi comme librairie, configuré vous ne savez comment.
Votre pom fait également maintenant plus de 1000 lignes, vous tirez des dizaines de dépendances, un gros tas de plugins Maven. Vous ne maitrisez plus votre projet.
La slide suivante, tirée du célèbre Simple Made Easy de Rich Hickey résume là encore parfaitement la situation:
Spring et les générateurs sont faciles. Vous avez une appli qui boot en 2 minutes, mais je reste persuadé que sur le long terme, vous êtes perdant (du vécu sur un gros projet).
D’ailleurs, une autre citation du talk est parfaitement dans le sujet:
So the word in this case is about being familiar.
I think that, collectively, we are infatuated with these two notions of easy. We are just so self-involved in these two aspects; it’s hurting us tremendously. Right? All we care about is, you know, can I get this instantly and start running it in five seconds? It could be this giant hairball that you got, but all you care is, you know, can you get it. […]
In particular, if you want everything to be familiar, you will never learn anything new because it can’t be significantly different from what you already know and not drift away from the familiarity. […]
And it is, and I think you really have to ask yourself, you know, are you programming with a loom? You know, you’re having a great time. You’re throwing that shuttle back and forth. And what’s coming out the other side is this knotted, you know, mess. I mean it may look pretty, but you have this problem. Right? What is the problem? The problem is the knitted castle problem. Right?
Bon je vais m’arrêter là avec les citations du talk car en fait je me rend compte que je pourrais mettre ici tout le transcript.
Un projet informatique, c’est pas une conférence où je montre que je peux boot une appli en 30 minutes sous les applaudissements de la salle.
Lock in
Vous avez commencé votre projet avec Spring, et maintenant vous voulez changer sans tout péter car Spring ne vous convient plus.
On entre dans le fameux débat framework vs librairie. Un framework comme Spring conditionnera votre façon de coder, posera un cadre extrêmement rigide sur ce que vous pouvez faire, et il sera très dur de sortir de ce cadre. C’est généralement à ce moment que les gros hacks pour contourner le framework apparaissent dans le projet.
Vous êtes malheureusement condamné à utiliser Spring jusqu’à la mort du projet, deal with it.
Spring 5
Bob, revenant du DevoxxFR: Mais Spring 5 arrive, c’est reactive !
Alice: Oui mais peut être que ce paradigme-
Bob: Non mais mon programme sera reactive ! Spring en reactive c’est génial ! En plus je peux le faire en Kotlin !
Alice: …
Conclusion
Oui, j’aurais pû mettre des balises <rant></rant> autour de ce post, et c’est peut être légèrement (?) exagéré. Vous ne serez probablement pas d’accord avec moi.
Pas grave, suis un sysadmin au quotidien, donc Spring ou pas Spring finalement…
Add a comment
If you have a bug/issue with the commenting system, please send me an email (my email is in the "About" section).