Attention au décalage…
ou bien préparez-vous à devoir vous sortir d’un trou de refactor.

Par Juan Martinez
Jeudi le 10 septembre 2020

Nous en sommes à la moitié de 2019, l’équipe Boost de chez district m est en train de développer une application Web: React pour l’interface avant et Symfony pour l’arrière. L’application fait le pont entre un ad exchange complexe et les Éditeurs, lesquels l’utilisent pour régler ou mettre à jour des configurations, revoir des paramètres et générer des rapports.

Cependant, les fonctionnalités futures son plutôt ambitieuses. L’équipe Boost décide donc de:
  • Télécharger la nouvelle version de Symfony
  • Utiliser la structure complète de Symfony plutôt que certaines de ses composantes
  • Avoir recours à Scheduled Jobs
  • Utiliser un ORM
  • Refactoriser la structure des données pour se conformer aux standards de l’industrie
  • Refactoriser le code des interfaces avant et arrière pour utiliser la nouvelle structure de données et schéma de nomenclature

Une nouvelle version est donc construite à partir de la précédente ainsi qu’une nouvelle base de données. Cette nouvelle base de données est gardée à jour grâce à des «Sync Jobs» cédulées à l’heure ce qui permet de garder une synchronicité entre la nouvelle version et la version précédente. C’est un hybride. Un mutant! Heureusement qu’il est dans une cage. Mais tout cela n’est que temporaire, n’est-ce pas?

L’équipe Boost est maintenant coincée dans le processus de migration des tableaux, ce qui créer des entitées Doctrines, de nouveaux Controllers, Services et Repositories. Il y aura beaucoup de refactorisation à faire.
Le processus est plus long que prévu. Un sprint après l’autre, la nouvelle version n’est pas lancée. 

Décembre arrive et la situation est critique: L’application en développement est entretenue mais aucune amélioration n’y est apporté. De nouvelles fonctionnalités sont ajoutées dans la version en développement. Malheureusement, personne ne peut les utiliser. Es-ce que le refactor est terminé? La réponse est difficile à déterminer et encore plus difficile à communiquer: «nous n’en sommes pas certains, mais pas tout de suite».  De plus, les membres de l’équipe savent que la refactorisation est ennuyante, cela les déprime un peu. À quelque part, quelque chose n’a pas bien fonctionné. Le mutant s’est échappé de sa cage.

En janvier, avec l’aide d’un des développeurs les plus anciens chez District M, un plan est ébauché. Il n’est pas parfait, mais cela devrais fonctionner. Voici les grandes lignes:

1

La nouvelle version de l’application devra être déployée le plus tôt possible et pour un usage interne seulement.

2

De nouveaux paramètres de Controller devront communiquer avec les deux bases de données, d’abord en appelant aux 2 nouveaux services, puis en transformant les données et finalement en appelant les services de la version précédente.

3

Les «Sync Jobs» seront délaissés, pendant que la nouvelle version sera déployée pour un usage externe.

À la fin de février 2020, le plan ayant été exécuté, un chemin sans embûche apparait. Aujourd’hui l’équipe refactorise toujours, mais en arrière plan. Cependant, il est maintenant possible d’ajouter de nouvelles fonctionnalités. Le mutant, bien qu’en cavale, a été maîtrisé. En rétrospective, l’équipe Boost réalise que le travail fait comportais 2 différents refactor:
1
Ils ont mis à jour Symfony et intégré un ORM.
2
Ils ont refactorisé le modèle de données.

Qu’auraient pu-t-ils faire différemment?

L’équipe reconnaît qu’elle aurait pu prioriser un seul refactor. Par exemple, elle aurait pu utiliser le premier lors d’un seul sprint, et sortir immédiatement une nouvelle version avec Symfony, ORM, Job Scheduler mis à jour et bien d’autres subtilités.

Ensuite, dresser la carte des entités Doctrine vers leurs tableaux existants, sans créer une deuxième base de données. À partir de cela, de nouveaux tableaux se seraient conformés aux standards de l’industrie. Puis, à l’arrière plan, le vieux modèle de données aurait été refactorisé ce qui permet d’effectué des migrations simples. Tout cela sans aucune «Sync Jobs» à l’heure qui bouge des données de la première base à la deuxième.

Cette approche n’aurait pas fait disparaître tout le travail de refactorisation. Mais elle aurait donné à l’équipe tout le pouvoir d’une mise à jour et d’une structure complète de Symfony, tout en lui permettant de refactoriser les données à l’arrière plan dès le premier jour. 

Check out our solutions in action

Get in touch to schedule a live demo of our platforms with one of our dedicated experts.

Get in touch with one of our experts

If you’re interested in learning more about how we can help your business, reach out to us!