- Améliorer le temps de génération du jeu de données de développement
Va être pris en charge par Bastien à partir de la semaine prochaine.

- Rendre le process de merge plus agréable en reprenant le bot qui permet de générer le jeu de données SQL.
C'est quoi le soucis : A chaque merge d'une PR, nous devons re-générer le dump si une autre PR touche à celui-ci.
Comment régler le souci : Plusieurs solutions ici: ne plus avoir de dump en serait une mais c'est actuellement impossible au vu de notre fonctionnement actuel (la génération des Orders est bien trop longue pour être lancée à chaque reset de base de données). Une solution plus viable serait de reprendre le bot et faire en sorte qu'il fasse le dump à notre place pour libérer du temps humain.
Temps à prévoir : Je dirais au moins 2 jours pour bien finir et stabiliser le bot, sans doute un peu plus si on veut une intégration avec les tags github (les actions github permettent de faire ça de façon assez simple, ~2j de plus à prévoir).

- Améliorer la durée des tests.
C'est quoi le soucis : Les tests sur l'API sont très longs (~22min au moment où j'écris cet email).
Comment améliorer : Je n'ai pas de solution magique de ce côté, il faudrait découper les tests et isoler ce qui prend le plus de temps pour ensuite l'améliorer. Utiliser des outils tel que Blackfire peuvent grandement aider.
Temps que ça prendrais: Je pense que 2/3 jours sont suffisant de ce côté.

- Rendre les tests indépendants
C'est quoi le soucis : Lorsque l'on lance un test, parfois celui-ci se base sur le fait qu'il est lancé après d'autres tests et se base sur leurs résultats, ce qui fait que lancer le test seul sans ces tests précédents le rends non-fonctionnel.
Comment améliorer : Reprendre les tests et voir ceux qui ne sont pas indépendants et les corriger au cas par cas.
Temps à prévoir: Cela dépend du nombre de tests qui ont ce souci. Nous avions planifié 9 jours sur le sujet avec Suzanne pour commencer à nettoyer cela, mais ils ont été retirés. Récupérer ces jours nous permettrais de bien nettoyer l'existant.

- Clean le "legacy" sur le process des commandes et les tests liés à ce legacy
C'est quoi le soucis : C'est du code fourre-tout dans une seule classe: OrderFactory et les tests qui sont liés à cette classe, on a déjà commencé à clean ~50% du code de cette classe il y a longtemps (il y a un an peut-être ?) mais il reste encore un peu de travail
Comment améliorer : Split les méthodes dans des actions de workflow, dégager les tests dégueux et faire des tests plus unitaires par action de workflow
Temps à prévoir : Je dirais 4/5 jours nous permettraient de dégager tout ce qui reste, passer tout dans des actions de workflow et revoir les tests.

- Clean du code récupéré d'un ancien projet
C'est quoi le soucis : Lors de la création du projet nous avons beaucoup récupéré du code d'un ancien projet pour "aller plus vite", par exemple sur les modes de livraisons, les paiements, les commandes ... Ce code nous a permis d'aller vite au début du projet mais aujourd'hui ne correspond pas forcément au besoin de Sézane ou alors n'est tout simplement pas utilisé.
Comment améliorer : Supprimer ce qui n'est pas utilisé et revoir quand c'est mal utilisé parce que le besoin n'est pas adapté.
Temps à prévoir : Par exemple, la partie paiements est assez simple et peut être réglée en 1/2 journée.

- Modèle des pages CMS
C'est quoi le soucis :
Pour les blocs des page versions tous les champs qui dépendent du type de bloc sont définis dans des sous-classes de la classe abstraite LocalizedAttributeBlockList qui fonctionne avec de l'héritage Doctrine. Problème : cette feature impose la présence sur la classe d'un champ type qui sert de discriminant. Le type de bloc n'est donc pas porté par le bloc lui-même mais par ses localizedAttrbuteBlockLists. On ne peut pas connaitre le type d'un bloc sans creuser en profondeur.
De plus, les localizedAttributeBlockLists portent deux responsabilités à la fois : ils déterminent le type et donc les champs spécifiques au bloc auquel ils appartiennent ET ils portent en plus une locale qui permet de déterminer la langue des champs type label, description, etc.
On a donc un double problème :
- il est impossible de connaître le type d'un bloc en tant que tel, il faut creuser dans ses attributs
- certains champs qui n'ont pas vocation à être traduits (un média par exemple) le sont par défaut puisqu'ils appartiennent à des localizedAttributeBlockLists qui dépendent de la locale.
Concernant les dévelopements BO, cela est très impactant, il suffit de prendre en exemple le ticket "changer le type d'un bloc" qui serait l'affaire de quelques lignes de code si le bloc portait son type, mais qui est beaucoup plus complexe en l'état.
On a en plus un pb de cohérence des données, il est théoriquement possible en l'état qu'on bloc contiennent des localizedAttributeBlockLists de types différents, ce qui n'a aucun sens en termes métier.
Si l'on veut pouvoir changer le média d'un bloc, il faut développer des champs qui répercutent automatiquement le choix du média sur toutes les locales (i.e. tous les localizedAttributeBlockLists), de même si on ajoute une locale sur un bloc, il faudra penser à rajouter le média présent dans les autres localizedAttributeBlockLists, tout ça alors que le média devrait simplement être une propriété du bloc lui-même.
Il existe certainement d'autres problèmes inhérents au modèle actuel mais ceux-là sont les premiers qui me viennent à l'esprit.
Comment améliorer:
L'héritage utilisé actuellement est de type single_table => il existe une seule table pour tous les types de localizedAtttributeBlockLists, chaque ligne de la table contient TOUS les champs de TOUS les types, et l'immense majorité de ces champs sont vides. Il n'y a donc aucune plus-value à utiliser cet héritage en termes de volume de stockage consommé.
La solution consiste à supprimer tous les LocalizedAttributeBlockLists, à déplacer tous leurs champs au niveau de l'entité Block, à ajouter éventuellement une entité BlockTranslation qui contient les champs vraiment traduisibles, et à transformer la validation de chaque LocalizedBlockAttributeLists en une validation group sequence. Le reste du refacto consiste simplement à supprimer les quantités de hacks qui ont été ajoutés pour faire fonctionner tout ça.
Temps à prévoir:
Le modèle est bien connu par au moins Laurent et Suzanne, les tests sont relativement complets et les solutions évoquées plus haut ont toutes déjà été mises en place à de multiples endroits du projet. Je ne vois aucune grosse difficulté ou inconnue particulière. Le refacto devrait durer environ 3 jours.