Journal de bord

[NerOcrO]

Journal de bord pour historiser tout ce qui est arrivé d'intéressant sur la mission pour en faire un REX plus tard.

• été 24 : réduction de la facture de 600 euros sur Clever Cloud en éteignant des containers inutilisés et en scalant vers le bas d'autres
• 26/09/24 : mise en place de assert qui ne fonctionne pas en production...
• 27/09/24 : les Server Action de Nextjs fonctionnent comme une API donc il faut les sécuriser et valider leurs entrées utilisateur
• 27/09/24 : on s'est aperçu que les dialog étaient mal géré dans Vitest
  • getByText ou getByLabelText vont chercher dans la dialog alors qu’elle est fermée
  • getByRole(’dialog’) n’est pas trouvé par contre
  • getByRole(’button’) n’est pas trouvé par contre
  • en ajoutant aria-hidden, le comportement est inchangé
  • en ajoutant aria-labelledby, le comportement est inchangé
  • @meha-octo : peux tu ajouter le lien dont tu parlais ?
• 30/09/24 : les variables (ex: $desc) dans un test paramétré ne s’affichent pas complètement alors que %s fonctionne correctement
• 09/10/24 : l'utilisation de window.location.href pour avoir des searchParams n'est pas bonne car ça ne donne pas la bonne information en production (appli buildée) et génère le log suivant ReferenceError: window is not defined côté back (ce qui est vrai !)
  • la solution est d'utiliser useSearchParams et une variable d’environnement représentant le host
• 14/10/24 : l'équipe passe de deux devs à cinq devs : on va pouvoir plus faire du refactoring
• 14/10/24 : l'utilisation des hooks useSearchParams et useRouter à travers les composants apportent une certaine complexité dans les tests, on est obligé de modifier des tests qui n'utilisent pas vraiment ces derniers.
  • la solution a été d'injecter ces deux hooks dans notre context et nos tests controllent plus facilement ce context
• 16/10/24 : mise en place de règles eslint pour éviter d'importer des fichiers au mauvais endroit
  • ça a permi de faire remonter quelques petits problèmes qu'on a refactoré facilement
• 22/10/24 : des filtres du use case fuitaient dans le controller. Il a suffit de mettre des valeurs par défaut à ces filtres pour corriger ce problème et ainsi les filtres n'étaient plus tous obligatoires et si le domaine change, le controller ne change pas
• 30/10/24 : le fait d'avoir regarder mes tests de mutation m'a fait découvrir que j'avais un spy fait main qui ne détectait pas l'ajout de paramètre dans une méthode parce que typescript est comme ça
• 30/10/24 : je m'aperçois que c'est le nombre de mutant qui fait que c'est long à se lancer donc il est intéressant de diminuer le nombre de mutant (ce qui est antinomique vu que l'on ajoute des fonctionnalités donc de l'algorhymie). Voici un exemple de simplification d'algo.
• 30/10/24 : extraire dans une constante pour nommer une chose ajoute des mutants

const isDebutDePagination = pageCourante < 3 // 4 mutants

if (isDebutDePagination) { // 3 mutants dont 2 identiques à ceux plus haut
  return page < 6
}

• 04/11/24 : cela fait plusieurs missions que je fais des factories pour les tests et je commence par les faire en local pour ensuite les recentrer parce qu'elles sont évidemment appelées un peu partout donc autant les centraliser du premier coup
• 18/11/24 : mise en place du tableau de vélocité pour nous améliorer
• 25/11/24 : Ajout d'un commentaire stryker disable all dans les fichiers qui vont bien plutôt que dans la configuration pour que ça soit autoportant #209
• 28/11/24 : Composition de composant à la place d'une condition
  • une condition/indentation/complexité en moins
  • des mutants en moins
  • les informations d'une couche ne leak plus avec une autre couche
• 29/11/24 : le fait d'avoir des couches isolées permet qu'un développeur peut être sur chaque couche et que par conséquent on peut avoir une WIP limit à 1 et par conséquent la notion de dépendance entre ticket n'existe plus
• 29/11/24 : le fait d'avoir des composants les plus bête possible et de mettre un maximum de logique dans les presenter voir les server component permet de limiter le poids des js envoyé au client
  • exemple : si tu mets une condition dans un composant client, cette dernière sera téléchargée et interprétée par le client alors que si elle est côté presenter, elle sera juste exécutée côté serveur
• 04/12/24 : on a tester d'utiliser Maybe et Either mais on s'aperçoit que c'est un trop gros pas
• 12/12/24 : quand tu changes la date de ton ordinateur alorss new Date() change aussi donc il faut avoir ça en tête