---
# System prepended metadata

title: Untitled

---

- Vouloir créer du générique alors que l'existant ne l'est pas est une source de complexité. Le générique mis en place ne permet pas de faire plus que la solution qui existait déjà, au contraire.
- Ensemble RegEx encombrant et trop complexe => lireTag par exemple et tous les niveaux d'abstraction utilisés pour lire le fichier avant de le traiter en tant que flux (appels de regex en cascade pour retrouver le bloc, le tag, l'info dans le tag...). Une solution open source en license appache propose de parser tout le SWIFT.
- Le système de RegEx mis en place ne permet pas de faire de contrôles syntaxiques correctes, avec des erreurs pertinentes. Si une regex ne match pas, impossible de savoir pourquoi sans en lancer des sous-portions ou d'autres REGEX.
- Le temps perdu à complexifier l'ensemble (concrétiserMessageErreur par exemple qui fait juste un replace) se resent maintenant puisque des tâches simples ne sont pas réalisées correctement : exemple d'un defect au 02/07/2020 : impossible de récupérer les donneurs d'ordre dans une transmission multi remises.
- La complexité du code nous a poussé à passer plus de temps à en comprendre le sens qu'à essayer de le corriger / corriger des defects, le sujet n'est encore pas facilement abordable.
- Exemple de regex inutile : "(?:\\/)?((?>[A-Z0-9]){14,34}|(?>^.*)" match n'importe quoi
- L'architecture mise en place est source de problèmes. Trop d'abstracts pour faire de l'abstract, trop d'implémentations. Ne s'appuye pas sur l'existant. Traitement d'EJB douteux, apparemment déjà reproduits sur les VCOM. Cette architecture a demandé beaucoup trop de temps à des sachants pour être fonctionnelle alors qu'une solution existait déjà.
- Travail solitaire au sein d'une équipe : beaucoup de réunions sur le sujet en solitaire, très peu de retombées ou de compte rendus, tu n'as pas assez donné de vision aux autres personnes, que ce soit au sein du sujet ou dans la chefferie.
- Demande de support seulement quand c'est trop tard (problèmes EJB par exemple) et difficulté à suivre les conseils / préconnisations données par le tech lead (exemple des PST par exemple)
- La log erreur SEVERE "Vous ne passerez pas !!!" qui peut être remontée 5 fois par transaction. On s'est contenté de l'enlever mais ça aurait pu remonter beaucoup plus haut et te causer des problèmes, il est très fortement déconseillé d'utiliser un code qui partira en production pour y glisser des blagues.
- Produire du code de qualité n'implique pas refaire de l'existant, il faut adapter son propos en fonction du contexte, le mieux est l'ennemi du bien et tu essayes de faire mieux avant de faire bien. 
- Assemblage réalisé vraissemblablement avec un seul exemple de fichier passant