Si vraiment on part sur une réécriture, autant changer carrément de langage.
C’est une possibilité encore plus rare que de pouvoir refondre l’application en profondeur, parce que ça implique :
Soit d’avoir une équipe technique qui maitrise raisonnablement un nouveau langage qui soit plus performant que la JVM (et mine de rien ça réduit les choix) ;
Soit d’accepter de perdre une grande partie de la connaissance métier en changeant l’équipe de développement au passage.
Dans les deux cas ça mène à des risques forts et réels de nouveau projet qui se vautre parce que codé n’importe comment.
D’ailleurs mon expérience (et ça n’est que ça) c’est que sur un projet du type dont je parle ici (gros monolithe) qui tourne sur la JVM, c’est rarement le langage et l’environnement d’exécution qui sont le facteur limitant. Aujourd’hui les JVM sont performantes pour le côté calculatoire, et l’occupation mémoire est plutôt un problème quand on doit lancer des dizaines de JVM en parallèle (typiquement pour une architecture micro-services), car ça implique d’avoir des dizaines de fois l’overhead de la JVM et dégrade le rapport entre mémoire « utile » de travail et mémoire « technique ».
Par contre, ce que j’ai très souvent constaté, c’est du code très inefficace parce que codé n’importe comment, qui se retrouve avec au moins l’un de ces problèmes :
Les personnes qui l’ont développé ne connaissaient rien au langage et aux outils et ont fait n’importe quoi avec (exemple : remonter toute une table en Java pour faire un filtre avec Java au lieu de faire une requête). Très présent si le code a été outsourcé sans contrôle très strict...
Croyance que « JVM = garbage collector = mémoire magique », le code se retrouve pourri de fuites mémoires (souvent ça va avec une mauvaise architecture).
Architecture du code absurdement complexe qui empile les couches de « services » et de « factories » jusqu’à l’infini, ce qui impose de créer des centaines d’objets pour la moindre opération, sans garantie que les fonctionnalités soient bien isolées. Spécialité de gros frameworks de très grosses entreprises, oui c’est à toi que je pense IBM.
Dans ce cas un truc qui, d’expérience, fonctionne bien c’est de reprendre un projet sur une base propre, avec une architecture propre, quitte à copier les éléments (en particulier le code métier) qui fonctionnent du le projet d’origine.
[^] # Re: Ecoconception
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Quarkus, Spring Boot et les monolithes : Peut-on moderniser un projet géant sans tout casser ?. Évalué à 4.
C’est une possibilité encore plus rare que de pouvoir refondre l’application en profondeur, parce que ça implique :
Dans les deux cas ça mène à des risques forts et réels de nouveau projet qui se vautre parce que codé n’importe comment.
D’ailleurs mon expérience (et ça n’est que ça) c’est que sur un projet du type dont je parle ici (gros monolithe) qui tourne sur la JVM, c’est rarement le langage et l’environnement d’exécution qui sont le facteur limitant. Aujourd’hui les JVM sont performantes pour le côté calculatoire, et l’occupation mémoire est plutôt un problème quand on doit lancer des dizaines de JVM en parallèle (typiquement pour une architecture micro-services), car ça implique d’avoir des dizaines de fois l’overhead de la JVM et dégrade le rapport entre mémoire « utile » de travail et mémoire « technique ».
Par contre, ce que j’ai très souvent constaté, c’est du code très inefficace parce que codé n’importe comment, qui se retrouve avec au moins l’un de ces problèmes :
Dans ce cas un truc qui, d’expérience, fonctionne bien c’est de reprendre un projet sur une base propre, avec une architecture propre, quitte à copier les éléments (en particulier le code métier) qui fonctionnent du le projet d’origine.
La connaissance libre : https://zestedesavoir.com