Discussion :

[seeme]

Bonjour,

Je suis actuellement stagiaire dans une très grosse entreprise.

Une partie de mon travail consiste à améliorer/corriger des applications existantes.

J'ai un problème pour l'une d'elle.

En gros, l'entreprise gère 4 machines distinctes. Chaque pièce composant ces machines est détaillée dans un fichier Excel (un par machine), dans lequel on stocke aussi le prix moyen à l'achat fixé une fois par an.

Il faut plusieurs mois pour réunir toutes les pièces nécessaires, et le but de l'application est de permettre mensuellement de comparer le prix effectivement payé au prix prévu (variation du dollar, sous-traitance...).

C'est ce que fait un fichier excel. Il trie les pièces, retire les doublons (bref, nettoie tout ça) et stocke tout de manière à générer un tableau synthétique (par secteur etc..).

Le problème c'est que ce procédé est incroyablement lent (entre 20 et 40 000 pièces par machines, 4 machines, avec les calculs et les recopies, après 4 heures excel moulinait encore...).

J'ai deux options: recoder entièrement la macro (codée par un non informaticien, pas mal de boucles inutiles, des cC des fonctions -> 4 fois plus de fonctions qui font la même chose, volume de données énorme pour un debug efficace..), ou parser les fichiers excel, les traiters et générer une feuille excel qui sera mise en forme par excel dans un joli tableau..

Ma question: est-ce pertinent d'utiliser un outil intermédiaire plus rapide (je pensais à quelque chose comme c++ ou java), ou le gain risque d'être minime?

Pour la mémoire, est-ce que je ne vais pas perdre un temps trop grand à manager la mémoire comme il faut par rapport au gain de temps d'execution?

Quelle politique de mémoire serait le plus pertinent (je vais faire quelques tests en Java pour me faire une idée)?

Et enfin, est-ce la meilleur des solutions, ou tout recoder pourrait faire l'affaire?

Finalement, plus généralement, je suis réellement blasé de voir que l'ensemble des données sont traitées par excel, les possibilités d'évolutions sont proches du néant, personne ne respecte les formats standards (ce qui m'éviterais de perdre 3 jours à refaire de la mise en forme...), bref c'est vraiment la galère.

De votre expérience, c'est partout pareil? Est-ce normal que je ne sente pas mon cursus/expérience valorisée pour ce stage de 4eme année d'ingénieur (ouais, c'est la déprime là...)?

Merci d'avance.
Seeme

[el_slapper]

C'est classique là ou on a pas de programmeurs dédiés. Quand j'ai commençé, je me suis retrouvé dans une équipe d'homologation(c'est très formateur), mais il y avait parfois des besoins de traitements un peu exotiques. Comme je savais faire, on m'a demander de rajouter 3 lignes à un tableau EXCEL, et de les gérer dans la macro. le code était du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11

for i = 18 to 20
(...traitement alpha au complet...)
next i
for i = 21 to 22
(...traitement numérique au complet...)
next i
for i = 23 to 23
(...traitement alpha au complet...)
next i

Le tout jusqu'à la ligne 110. Evidemment, ça marchait, mais je me suis permis de tout reprendre, en ajoutant une colonne "numerique/alpha" au tableau, et en faisant des boucles propres. Mais codé par des non-programmeurs, faut pas être surpris.

Celà étant, ton appli risque d'être reprise par un non-programmeur. et tu dois donc, tout en faisant des choses propres, t'assurer que le non-programmeur puisse reprendre ton boulot. C'est parfois compliqué. A ce titre, faire une appli externe me semble une fausse bonne idée. Certes ça marchera(et encore, au niveau des tests, tu vas t'amuser), mais au final, ils ne pourront plus rien en faire.

Sur mon exemple ci-dessus, j'ai voulu être plus royaliste que le roi, et j'ai fait plusieurs encapsulations au lieu d'une seule( if numerique then call traitement-numerique else call traitement-alphanumérique aurait suffi). En voulant faire "mieux", j'ai fait "mal" car moins lisible pour le béotien amené à reprendre tout ça. Ton cas est plus complexe, car ta spec est autrement plus fouillée, mais la problématique reste la même : garder un système qui marche(et pour celà, tu sera amené à comparer les résultats de l'ancienne moulinette avec ceux de la nouvelle à fin de validation de tes améliorations), et surtout qui soit lisible pour moins informaticien que toi.

D'une manière plus générale, le travail en entreprise est souvent frustrant car on est dépendant de contraintes non abordées au cours des études : la pesanteur de l'existant. Mais on est payé pour résoudre ce genre de problèmes, pas des problèmes universitaires de page blanche.

[seeme]

Bonjour,

Merci beaucoup pour ta réponse pleine d'enseignements!

Un point crucial auquel je n'avais absolument pas pensé est qu'un non initié pourrait devoir reprendre l'outil, et là effectivement, ça poserais de graves problèmes (et le gars va probablement devoir tout refaire en VBA...)


Merci beaucoup pour le retour d'expérience!

@+

[el_slapper]

Bonjour,

Merci beaucoup pour ta réponse pleine d'enseignements!

Un point crucial auquel je n'avais absolument pas pensé est qu'un non initié pourrait devoir reprendre l'outil, et là effectivement, ça poserais de graves problèmes (et le gars va probablement devoir tout refaire en VBA...)


Merci beaucoup pour le retour d'expérience!

@+

De rien. "Certains apprennent avec leur expériences, moi je préfère apprendre avec l'expérience des autres", disait Bismarck. Internet multiplie cet effet, pour qui est assez sage pour écouter les vieux et leurs expériences pleines de poussière.

Juste, fais bien gaffe à la validation : un bon test vaut mieux que 2 semaines de déboggage 6 mois plus tard.....(là aussi, j'ai vu, j'ai vécu, et j'ai pas apprécié, et en plus c'était de ma faute).