Pensons modulaire, pensons states-machine

Flattr this!

Cet article traînait dans les brouillons depuis près d'un an. Je le publie en l'état.

Dans notre métier de développeur, il nous est souvent nécessaire de construire un ou plusieurs systèmes basés sur un "processus utilisateur".

Il y a plus d'un an, j'ai dû remettre à neuf toute l'implémentation d'un processus clé pour mon entreprise. Un processus très lourd et très complexe permettant de bien cibler le besoin et pouvoir y répondre au mieux. Il est constitué de 3 étapes clés dont deux sont sensiblement les mêmes mais séparées par l'autre.

Au démarrage du projet, j'ai imaginé un système sur deux contrôleurs pouvant gérer autant d'instances d'eux mêmes sans multiplication des objets réels. Je n'avais donc pas besoin d'un troisième contrôleur pour la troisième étape, juste d'une autre instance.

Le processus ayant été défini clairement dès le début du projet, j'ai commis une erreur de débutant qui a été de déléguer la création de ces instances, la gestion de leurs états et des transitions inter-contrôleurs aux contrôleurs eux mêmes.

En soit ce n'est pas grave si le processus est fixé dans le béton et ne pouvant être altéré. Hors ici nous parlons d'un processus marketing soumis aux aléas du temps et du soucis de taux de transformation. Il sera donc régulièrement modifié, aussi bien dans les questions elles mêmes que dans l'ordre d'affichage des états. C'est le destin normal de toute application.

En plus d'un an, j'ai donc eu à appliquer un certain nombre de changements clés et j'ai pu être confronter au problème le plus récurrent d'un architecte. La maintenabilité d'une application. Et c'est là que mon erreur m'a sauté au nez.

La façon de transiter d'un état à l'autre dépendait de chaque état. Et non d'un super contrôleur qui déterminait la suite en fonction du statut de l'état courant.

J'ai pu corriger l'essentiel du problème de façon assez propre, perdant la moitié de mes cheveux en cours de route. Mais je n'aurais pas eu à le faire si je n'avais pas commis cette erreur au démarrage.

L'utilisation des patterns ne doit pas se faire de façon déraisonnable mais ne doit pas être oubliée non plus. J'en ai la preuve par l'expérience désormais.

Découpler, la gestion interne de mes états de la gestion de l'ordre de mes états, m'aurait permis de modifier l'ordre de mes états en quelques minutes. Plutôt que les 2 jours que ça m'a pris initialement plus les heures de correction de régression non détectées sur le moment.

Déclencher des évènements à chaque fin "d'état" pour assurer la transition est bien plus pertinente que d'appeler un module depuis un autre. En plus pour la ré-utilisabilité, on change carrément de gamme de capacité.

J'espère que le récit de cette mésaventure vous évitera de tomber bêtement comme moi dans ce piège. Cette rétrospective m'a été très utile pour mieux formuler mon erreur, mieux la comprendre et donc éviter de la commettre à nouveau. Je m'en jette la pierre, c'est une très grosse erreur de débutant. Mais après tout, si tant est que la durée de l'expérience soit un critère objectif, je suis plus proche du débutant que de l'expert confirmé (ça fait environ 6 ans que je bosse seulement). Ce qui est d'autant plus affligeant à titre personnel, c'est qu'on n'est pas loin du cas d'école.

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans Dev. Web, avec comme mot(s)-clef(s) , . Vous pouvez la mettre en favoris avec ce permalien.

Articles liés