🧨 Faut tout refaire ! (ou pas…)

Coup de gueule d’un développeur qui a un peu de recul

Il débarque. Enthousiaste, motivé… parfois un peu trop.
Il regarde le code, la structure, les tests, les dépendances. Et là, il lâche la fameuse phrase :

“Franchement, tout est à revoir. L’archi est nulle, les tests sont mal faits, on utilise encore des vieilles libs… Faudrait tout refondre, je te fais ça en 2 semaines.”

Et toi, tu inspires profondément. Tu souris poliment. Et intérieurement, tu cries.

🤦 Mon cas concret : JUnit4, et le développeur qui ne voit pas plus loin que sa Pull Request

Dernièrement, un développeur fraîchement arrivé sur un projet me fait une remarque sur la façon dont sont conçus les tests unitaires. “C’est bizarre, vous utilisez encore JUnit4 ? C’est dépassé.”

Oui. Et non.

Le projet tourne sous Java 17, tout est conteneurisé, on a une infra stable dans le cloud. Les nouveaux services sont développés en Spring Boot, les modules les plus récents utilisent JUnit 5.

Mais voilà :

Le socle historique du projet date d’une époque où il n’avait probablement pas encore IntelliJ ou Eclipse
Plusieurs développeurs se sont succédé, avec des contraintes différentes à chaque phase.
Il y a des milliers de tests déjà en place, fiables, cohérents, et qui, en l’état, font le job

Changer tout ça “par principe”, sans aucun gain fonctionnel, ça a un coût, un vrai, et un risque.
Ce n’est pas parce que c’est vieux que c’est mauvais. Ce n’est pas parce que c’est nouveau que c’est mieux.

🧠 D’autres exemples du syndrome “faut tout péter”

“Il faut qu’on passe tout en microservices.” → Oui, sauf que le monolithe fonctionne, et que le scinder prendrait 18 mois, sans valeur métier immédiate.
“Il faut réécrire tout le front avec le dernier Angular.” → Le front actuel est en JSF, oui, ce n’est pas la techno la plus hype du moment. Mais il fonctionne, et il offre au client une autonomie réelle pour personnaliser lui-même ses écrans, ce qui est loin d’être simple à reproduire avec Angular. Sans parler du coût de refonte, des tests, de la migration progressive… pour un gain encore flou.
“La couche DAO est trop verbeuse, on devrait tout refaire avec Hibernate en natif.” → Très bien, mais quid des effets de bord ? Des intégrations existantes ? Du code testé depuis 6 ans ?

😶 Pourquoi ça me fatigue (et ce que ça dit)

Ce n’est pas qu’ils ont totalement tort sur le fond.
Oui, certaines technos sont datées. Oui, tout n’est pas parfait. Oui, on pourrait faire mieux, plus moderne, plus clean.

Mais ce que ces remarques oublient, c’est le contexte.
La réalité d’un projet, ce n’est pas GitHub et un benchmark de frameworks. C’est :

un historique
un budget
des deadlines
des contraintes d’équipe
une dette technique gérée et assumée

Ce n’est pas parce que tu ne comprends pas pourquoi c’est comme ça que c’est mal fait.
Et surtout, ce n’est pas parce que tu viens d’arriver que tu dois tout remettre en question.

🧘 Ce que l’expérience apprend (et ce qu’elle évite)

Avec le temps, on apprend à reconnaître :

Ce qu’on peut améliorer maintenant, sans risque ni débat
Ce qui peut attendre, mais mérite d’être inscrit dans la roadmap
Ce qui fonctionne très bien, même si ça n’est pas “sexy”

Et surtout, on apprend à ne pas juger trop vite. À prendre le temps de comprendre un projet. D’absorber le contexte. D’écouter ceux qui y sont depuis plus longtemps. D’avoir un avis… informé.

L’expérience, ce n’est pas juste “avoir vu plus de code”.
C’est savoir s’adapter à un projet existant sans vouloir tout réécrire dès le lundi matin.
C’est améliorer sans casser.
C’est faire avancer sans tout réinventer.

✅ Les bonnes pratiques d’un développeur impliqué

Tu es là depuis 3 jours ? 3 mois ? 3 ans ? Voici ce que j’attends d’un bon développeur:

Tu prends le temps de lire le code avant de le critiquer
Tu poses des questions avant de proposer une révolution
Tu respectes ce qui a été fait, même si tu ne le referais pas comme ça
Tu comprends que tout changement doit s’évaluer : coût, impact, valeur
Tu sais que le “propre” ne vaut rien sans le « utile » et le « stable »

Oui, on progresse tous. Oui, il faut du renouveau.
Mais réfléchir avant de refondre, c’est ça, la maturité. Pas juste pousser du code “moderne”.

🙏 Conclusion : arrêtons de jouer les héros

Un développeur expérimenté ne se contente pas de critiquer à tout-va ou de vouloir tout révolutionner sans recul. Il sait évaluer intelligemment ce qui mérite d’être amélioré rapidement, ce qui peut attendre, et ce qui fonctionne déjà bien. Plus encore, il élève le niveau de toute l’équipe par son savoir-faire, son humilité, et son respect du travail déjà accompli — car derrière chaque ligne de code, même imparfaite, se cache une histoire, des contraintes, et souvent beaucoup d’efforts. Reconnaître cela, c’est contribuer à construire durablement, ensemble.

Remettre en cause, oui.
Tout raser, non.
Prendre du recul, toujours.

💬 Et toi ?

Quelle est ta manière de faire évoluer un projet sans tout révolutionner ?
En tant que développeur, comment abordes-tu les défis liés à l’héritage du code et à la collaboration en équipe ?

#developerexperience #cleancode #webdevelopment #continuouslearning #teamwork