Les applications monolithiques peuvent être difficiles à maintenir lorsque le code grossit et se complexifie. Repartir de zéro n’est souvent ni réaliste ni rentable. Heureusement, il existe des bonnes pratiques pour corriger et améliorer un monolithe existant sans devoir tout réécrire.

La découverte d'un projet

Prendre ses marques sur un gros projet peut être compliqué :

• La découverte du code, de sa logique et son implémentation n’est pas intuitif
• Les technologies sont vieillissantes voire obsolètes
• Les besoins métiers ne sont pas bien maitrisés

Avant même de se plonger dans ces problématiques, certaines règles de base doivent être respectées dans tout code, et vous pouvez commencer par corriger celles qui ne sont pas appliquées sur votre projet.

La déclaration des variables

• Les noms de variables doivent décrire leur rôle ou contenu, et non leur type ou position.

Exemple à éviter : Exemple correct : Si vous ne comprenez pas l’utilité d’une variable dans son code, c’est qu’elle n’est pas suffisamment décrite. Il faut impérativement donner un nom cohérent à son application et la documenter si nécessaire.

• Evitez les « Magic Values »

Il ne faut pas mettre directement des valeurs fixes dans le code (“magic numbers/strings”). Créez plutôt des constantes ou des enums, car vous enlevez de la lisibilité sur votre code. Exemple à éviter : Exemple correct :

• Faites des initialisations claires

Déclarez les variables au moment de l’initialisation, si possible. Évitez des variables vagues initialisées plus tard, cela rend le code moins clair.

• Choisissez le type approprié à une variable

Dans certains langages, il est possible de ne pas préciser le type de variable. Soyez le plus précis possible dans vos déclarations. Par exemple, en Java, évitez l’utilisation de « var » ou de « Object ». Décrire le type de la variable améliore grandement la clarté de votre code.

Séparer les responsabilités (Single Responsability Principle)

Un monolithe accumule souvent du code qui fait trop de choses à la fois :

• Identifiez les classes ou fonctions trop longues.
• Découpez-les en petites unités avec une seule responsabilité.
• Chaque module ou fonction doit être facile à comprendre et à tester.

Si vos fonctions ou celles que vous devez modifier sont trop longues, c’est généralement qu’elles n’ont pas été correctement déconstruites. Par exemple, une fonction processOrder() qui valide, calcule les taxes, envoie l’email et met à jour la base peut être scindée et ne doit pas effectuer toutes ces opérations à la fois. Elle doit être scindée en plusieurs opérations : validateOrder(), calculateTaxes(), notifyCustomer(), updateDatabase(). Cela rend le code plus maintenable, lisible et testable, chaque opération ayant une seule responsabilité.

Refactoring progressif

Ne tentez pas de refondre tout le monolithe en une seule fois. Divisez les modifications en petits refactorings:

• Isoler des fonctions répétitives dans des classes ou modules dédiés.
• Extraire des services ou composants indépendants.
• Renommer les variables et fonctions pour améliorer la lisibilité, comme expliqué dans la première partie.

Exemple concret : Si plusieurs fonctions manipulent le panier d’achat, créez un module CartService et redirigez progressivement les appels existants vers ce module.

Documenter, communiquer et tester

Documenter et communiquer Le code d’un monolithe est souvent un mystère, même pour les développeurs expérimentés.

• Documentez chaque refactoring : pourquoi, comment et quelles dépendances ont été modifiées.
• N’hésitez surtout pas à commenter du code ayant une logique qui a besoin d’être expliquée par un développeur ou par un métier ! Trop de commentaires vaut toujours mieux que pas assez.
• Partagez les informations avec l’équipe pour éviter les erreurs et les doublons.

Exemple concret : Créez un README pour chaque module extrait, avec les interfaces publiques et les exemples d’utilisation. Et surtout commentez votre code ! Exemple de bons commentaires :

Et bien sûr... Testez !

Les tests sont nécessaires, surtout après refactoring ! Si aucun test n’existe, vous devez en implémenter, même quelques-uns, pour mieux comprendre le code.  

Par Vincent