Salut !
Dans ma boîte, je suis depuis le 2 septembre sur un nouveau projet (quasiment à temps plein sauf peut-être 2 jours). Il consiste à récupérer des infos depuis la BDD d’un Prestashop (infos concernant les produits, les features, les groupes d’attributs, les attributs, les product_attributes (= des produits déclinés d’un produit originel en fonction de certains groupes d’attributs), catégories, et avec un ou 2 petits points relativement critiques) et à les écrire dans un CSV, pour les exporter vers une autre système. Le CSV doit respecter le format imposé par cet "autre système".
Le "respect du format" peut prendre diverses formes : certes il s’agit d’avoir les bons noms de colonnes (exemple : pour exporter une catégorie, il faut avoir au minimum une colonne "ID de la catégorie", "Nom de la catégorie", ce genre de choses), mais le truc peut aller un peu plus loin : pour importer un product_attribute, il faut s’assurer que certaines affirmations soient vraies concernant le product originel (les groupes d’attributs utilisés par le product_attribute doivent bien sûr être les mêmes que ceux du product originel par exemple). Bref ça paraît simple et logique et rapide à faire expliqué comme ça, mais il y a pas mal de conditions à vérifier quand on exporte certaines données.
En plus de ces conditions qui, si elles ne sont pas vérifiées, engendreront des warnings ou des bugs lorsqu’exportées vers "cet autre système", il y a aussi des problèmes au sein même des données Prestashop (encodages, incohérences de données, références de produits vides, produits déclinés d’un même produit originel mais qui ne partagent pas les mêmes groupes d’attributs, gros WTF !!).
Au final cette partie "export des données de PS vers cet autre système top secret" devait durer 1 à 2 semaines (projet avec crédit temps), j’en ai fait le double voire un peu plus du double. Et j’ai l’impression qu’on m’en fait un petit peu le reproche (mon chef de projet est aussi dev senior). Pourtant, les jointures SQL que j’ai mises en place dès la première semaine (et qui permettent de récupérer les données à exporter) n’ont que relativement peu changé, ce qui témoigne du fait que dès le début j’ai correctement su quelles données exporter et comment ; les seuls problèmes que j’ai rencontrés sont les problèmes de formats et leurs conditions qui doivent être vérifiées et autres soucis que j’ai expliqués ci-dessus. Il y avait finalement beaucoup de petits problèmes par-ci par-là donc.
N’ayant pas eu l’impression d’être confronté à de gros problèmes (en tout cas aucun ne m’a marqué), mais plutôt à plein de "petits" problèmes, je suis assez triste qu’on me fasse le reproche d’avoir doublé ou un peu plus que doublé le crédit temps… Mon chef de projet dit que ça fait 2 semaines qu’il argumente en disant lui-même au client que j’ai été confronté à plein de petits soucis qui ont retardé la livraison, mais je sens qu’il pense comme le client que j’ai juste eu du retard et que c’est quasiment justifiable par le fait que je serais quelqu’un de lent.
Ma question est : vous qui avez travaillé en entreprise, avez-vous été confronté à pareil problème ? Cela vous semble-t-il totalement injustifiable de passer beaucoup de temps sur des exports de données d’un service à un autre, sachant qu’il faut donc prendre uniquement les données valides, les trier (where/jointures), les mettre dans un CSV au bon format pour le système top secret, s’assurer que toutes les conditions imposées par le système top secret soient vérifiées (autre exemple : il y a 1 ou 2 fonctionnalités de ce système top secret non-présentes dans PrestaShop, et qu’il fallait activer en exportant les product et product_attributes PrestaShop correctement couplés et correctement couplés aussi avec les attributes_groups, et mine de rien ça peut prendre du temps pour peu que certaines données PS soient incohérentes entre elles et donc engendrer des alertes dans le système top secret) ?
PS : quand je dis "top secret" c’est juste un moyen pour attiser votre curiosité et faciliter la mémorisation post-lecture…