Comment savoir si ma refonte en microservices est utile ou si j'ai tout cassé?

[AaronT]

Salut tout le monde. Je me retrouve dans une situation un peu bête, je viens de passer une semaine à refactoriser un vieux module de traitement de fichiers, en pensant bien faire en le découpant en microservices plus propres. Maintenant que c’est fait, je me demande si je n’ai pas trop cassé quelque chose qui fonctionnait parfaitement, juste pour le plaisir d’appliquer une architecture plus moderne. Des fois, j’ai l’impression de sur-ingénieriser des solutions simples par réflexe. Est-ce que ça vous arrive aussi de douter après une grosse refonte ?

[Kenneth_M]

Oui, ça arrive souvent après une refonte; le doute devient presque un réflexe: est‑ce que j’ai cassé quelque chose qui fonctionnait ou bien est-ce que j’ai juste perdu en simplicité ?

[AndrewRR]

Moi, après une refonte, j’essaye d’isoler les tests et les contrats entre services pour voir s’il y a des régressions; sinon on peut se retrouver avec des surprises qui ne disent pas leur nom.

[Jonathan53]

Côté émotion, c’est parfois lourd; mais côté idée, il faut regarder le coût de maintenance et le vrai bénéfice; une refonte sans gains mesurables, c’est juste une déco en plus.

[Hannah30]

J’ai l’impression d’avoir mal compris le sujet: quand tu parles de refonte tu penses microservices, mais on a peut‑être juste refactorisé en blocs plus petits sans changer le fond.

[John.W]

Et si le vrai problème n’était pas le doute mais la tolérance au risque et la manière dont on évalue l’utilité réelle d’un changement ?

[StevenP]

On dirait que c’est aussi un test de style: on lit ou on code; bref, le mot clé refonte revient, mais c’est surtout un moment où les attentes des lecteurs/consommateurs du code comptent.