🍪🧽 Grand ménage de printemps, la refonte d’un formulaire à étape en suivant les principes SOLID

Temps de lecture : 9 minutes

avr. 03, 2024

Plusieurs semaines pour refacto une plateforme, n'est-ce pas ça le rêve ultime de tous les dévs ? Oui ? Non ? Peut-être ? C'est bien quand c'est fini aussi !

Depuis quelques semaines je suis en plein ménage de printemps sur la plateforme de souscription en ligne de La Nef et je vais vous raconter comment on a refacto, entre autre, un énorme formulaire à étapes en respectant les principes SOLID (teaser : ce n'était pas une mince affaire).

Au programme aujourd’hui :

Grand ménage de printemps, la refonte d’un formulaire à étape en suivant les principes SOLID par Mélanie
L’agence de recrutement pour les leads dévs RoR !

Temps de lecture : 9 minutes

Hello les petits Biscuits !

Bienvenue sur la 20ème édition de Ruby Biscuit.
Vous êtes maintenant 471 abonnés 🥳

Avant de vous laissez avec l’article du mois, je tenais à vous rappeler que vous êtes tous les bienvenus pour donner votre avis en commentaire et partager vos expériences sur les sujets que nous abordons. Vous pouvez aussi mettre un petit like ❤️ et/ou partager la newsletter à un copain ou une copine ! 😉

Bonne lecture.

Grand ménage de printemps, la refonte d’un formulaire à étape en suivant les principes SOLID

Petit mot sur La Nef avant d'aller plus loin :
La Nef est une coopérative bancaire française éthique, dédiée au financement de projets écologiques et sociaux, promouvant la transparence et l'impact positif. Nous avons développé leur plateforme de souscription en ligne en 2018. Depuis ils ont beaucoup évolué et la plateforme avec. Notamment depuis le lancement du Big Banque, une grande campagne lancée il y a un peu plus d'un an, visant à transformer La Nef en la première banque éthique indépendante de France. Et dire qu'on les a rencontrés quand ils finançaient Veja alors que personne ne connaissait encore la marque.

Revenons-en au code maintenant. Quel était notre point de départ avant le refacto :

Un formulaire complexe composé de 8 à 12 étapes dont l’ordre et la visibilité de chacune d’elles dépendent de la réponse de l’utilisateur aux précédentes. Il y avait donc un parcours "de base" mais qui allait devenir dynamique dès la complétion de la première étape.

En fonction des choix, certaines étapes pouvaient s'ajouter ou disparaître de la liste. Il était possible de revenir sur ses pas pour modifier ses choix. On avait également des sous-étapes (comme vous pouvez le voir sur l'image du breadcrumb ci-dessous).

Aujourd'hui on ne parlera pas de ces sous-étapes (ok si vous insistez vraiment pour qu'on en parle, on le fera une prochaine fois).

Enfin, chaque étape avait son propre controller et nous n'utilisions pas de librairie pour gérer ces étapes.

Le système d'étapes était géré majoritairement au sein d'un unique controller Subscriptions::ApplicationController et d'un decorator SubscriptionDecorator, qui se voyaient attribuer une lourde charge de responsabilités.

Les étapes étaient définies avec leur ordre dans un hash avec des conditions dispersées qui définissaient si les étapes étaient accessibles avec des prédicates. Comme ca :

STEPS = {
    subscription: StepDisplay.new(
      url: :edit_subscription_url, 
      order: 1, 
      predicate: nil
    ),
    child_details: StepDisplay.new(
      url: :edit_subscription_child_url,
      order: 2,
      predicate: ->(subscription, _, _) do
       subscription.client_choice&.child?
      end
    ),
    user_details: StepDisplay.new(
     url: :edit_subscription_user_details_url, 
     order: 3, 
     predicate: nil
    ),
    documents: StepDisplay.new(
      url: :edit_subscription_documents_url, 
      order: 4, 
      predicate: nil
    ),
    payment_option: StepDisplay.new(
      url: :edit_subscription_payment_url, 
      order: 5, 
      predicate: payment_option_predicate
    ),
    sign: StepDisplay.new(
      url: :subscription_sign_url, 
      order: 6, 
      predicate: nil
    )
 }.freeze

On avait dans le controller toute la logique pour retrouver l'étape précédente, la suivante, celle en cours et aussi pour définir si une étape était visible, complète etc. Les conditions étaient vraiment éparpillées de partout, il y en avait même un peu dans un helper et l'évolution de la plateforme nous avait contraint d'ajouter des couches supplémentaire au fur et à mesure des années.

Vous l'avez compris, c'était un vrai champ de bataille. Impossible de toucher à une étape sans en casser une autre.

Il fallait absolument revoir ce système et expliquer aux chefs de projets et au client pourquoi c'était devenu primordial.

Ils ont vite compris.

L'objectif de la refactorisation était clair : Transformer ce labyrinthe de conditions en une architecture plus compréhensible, flexible et maintenable (tiens ça ne ressemblerait pas à la définition des principes SOLID ça ?).

Il ne s'agissait pas seulement de corriger les bugs existants mais de repenser le formulaire pour faciliter l'intégration future de nouvelles étapes et conditions, sans perturber l'expérience utilisateur. En d'autres termes, nous voulions que notre travail en coulisses soit invisible pour les utilisateurs, tout en posant des fondations solides (😏) pour un avenir évolutif et sans tracas. Simple non ?

C'est à ce moment qu'on a relancé, pour la énième fois, le débat sur la gem wicked.
TL;DR : nous n'avons pas utilisé wicked.

Pourquoi pas wicked ?

Face à la nécessité de refactoriser notre formulaire complexe, la gem wicked s'est présentée comme une option envisageable (au cas où certain(e)s d'entre vous ne connaîtraient pas, c'est la gem la plus populaire pour gérer les formulaires ou autres systèmes à étapes).

Cependant, malgré ses avantages, nous avons décidé de ne pas l'adopter.

La raison ? La gem avait déjà été utilisée sur cette plateforme puis retirée car non adaptée. L'idée de la remettre a soulevé une divergence d'opinions au sein de notre équipe technique ; pour certains, c'est une solution qui fonctionne bien et qui peut faire l'affaire, pour d'autres ce n'est qu'ajouter une couche de complexité qui rendrait notre système plus opaque. C'était l'avis, entre autre, du dév responsable de la plateforme en question. Les décisions techniques, bien qu'avant tout pragmatiques, sont parfois aussi le reflet des dynamiques d'équipe et des préférences individuelles. Nous avons donc décidé de ne pas utiliser la gem wicked.

Après plusieurs jours de R&D sur le sujet, autour d'une table avec plusieurs développeurs, nous avons pu trouver l'architecture parfaite et ça a fonctionné du premier coup. FAUX.
J'aimerais vous dire que c'est vrai, mais vous savez tous ici que ça ne se passe jamais comme ça.

Il fallait faire au plus vite et au mieux, alors on a réfléchi un peu, on avait une piste, une petite idée de ce qu'on voulait et on a itéré. That's the real life.

Alors comment avons-nous fait ? Nous avons gardé les principes SOLID en ligne de mire et nous nous sommes lancés.

🚨 Vous trouverez ici une version simplifiée de notre système d'étapes pour bien comprendre ce qu'on a fait et appuyer les explications suivantes 🚨

S : Principe de responsabilité unique.
Chaque classe ou module dans un programme doit avoir une seule raison de changer, se concentrant sur une seule tâche ou fonctionnalité.

Il suffisait simplement de se demander 40 fois par jours "ok et ça, c'est la responsabilité de qui ?"