Depuis quelques temps, je bosse chez un client sur une appli dont le code a du oublié d'avoir été pensé, sans parler des parties fonctionnelles qui reflètent d'un amoncellement de rustines posées sur une girouette.
 
En résumé, d'après ce précédent topic que j'ai posté :
http://forum.hardware.fr/hardwaref [...] 4110-1.htm
 
Vous pouvez en déduire qu'ils ont appliqué à la lettre cet article :
http://mindprod.com/unmain.html
 
Je les soupçonne même d'avoir eu quelques idées originales qui n'ont pas été mentionnées dans cet article.
 
Un peu comme le proverbe Shadock "Il vaut mieu mobiliser son intelligence sur des conneries que sa connerie sur des choses intelligente". Là ils y sont allé gaiement et se sont mobilisés en nombre !
 
Bon, depuis quelques jours, je m'étonne de vois des objets VB contenant des Collection en "Private", avec des méthodes "GetObjAt(ByVal obj, ByVal idx)", qui va attribuer "ByVal" un objet de la collection à l'index idx. Pratique. En plus il n'y a pas de "Add" ni de "Delete", donc si on veut faire une modif, faut passer par un autre objet, détruire celui-ci et le recharger. La totale. N'oublions pas les propriété "Get" aux noms divers "GetCountUsers", "GetCountUsersValide", etc. par exemple, qui font toutes un .Count de la MÊME collection privée, qui a été chargée différenement selon la méthode uitilisée pour la remplir. J'ai expliqué à ça mon chien un soir, il a vomi. Moi j'en rêve encore.
 
Bon, je dois me faire de nouveaux objets. Je décide de partir sur des bases un peu plus propres. Les collections contenant des autres objets liés, je décide de passer mes collections en Public, et simplement les utiliser ensuite par l'instruction "for each ObjItem in Obj.maCollection". Carrément plus simple à coder, plus lisible, et étant donné qu'on travaille directement sur un pointeur de l'objet qui reste à sa place, je soupçonne que ce soit infiniement plus rapide.
 
Je leur explique ce que j'ai fait. Ils semblent surpris.
Après concertation de leur part, j'obtiens la réponse qui tue :
"Nan, faut pas faire comme ça, faut garder un truc homogène".
 
Ils me parlent d'homogénéité ??? Mais ils ont fumé ça où ? Dans un objet sur deux, la collection contient un obj, et dans les autres, un tableau à une seule colonne, chaque ligne correspondant à une propriété de l'objet qui aurait dû s'y trouver ! Pour lire UNE information, on est obligé parfoit d'appeler une méthode qui prend 25 paramètres (c'est bien 25, pas une éxagération de ma part) tous en ByRef et de type Variant. Super, je vient de créer 25 objets en mémoire pour quoi ? Aller lire un pauvre booléen ?
 
T'ain, je déprime.
 
Le pire, c'est que je vais au moins passer une journée entière à bordeliser mon code.
 
Quand je pense que certains ici me trouvent crade dans ma façon de coder... J'amerais voir leurs tête ici !

J'adore le coup des 25 ByRef

Bienvenue dans la vrai vie.
J'ai déjà eu du code de merde à reprendre (en VB aussi, tiens tiens ), mais ça a eu le mérite de grandement me faire ouvrir les yeux sur l'importance de coder clean, lisible et documenté. C'est formatteur.
Bon c'est sûr que passer 1 matinée à comprendre le rôle d'une fonction de 10 lignes c'est lourd.

'tain chuis content de pas avoir ce genre de choses ici
y passeront jamais les certifs Microsoft ceux-là

Ha ben là c'est sur que si M$ les voit, y partent en courant
 
HelloWorld > Ben c'est pas trop le problème du code porc qui m'ennuie. J'y suis habitué. Mais c'est surtout le fait qu'on m'oblige à faire la même même alors que je suis conscient que c'est du total n'importe quoi !

C'est parce que tu n'as pas saisi toute la subtilité du développement logiciel. Y'a aucun intérrêt à tout bien faire du premier coup.
Dans quelques mois ton chef de projet va venir et te dire fièrement : "bon après plusieurs mois de recherche et de réflexion, j'ai trouvé pourquoi le logiciel est trop lent. Alors on va maintenant utiliser une nouvelle méthode pour la version 2 : on va recoder toutes les collections en Public, et simplement les utiliser ensuite par l'instruction "for each ObjItem in Obj.maCollection". Comme ça c'est plus simple à coder, plus lisible, et étant donné qu'on travaille directement sur un pointeur de l'objet qui reste à sa place, c'est infiniement plus rapide. Je sais vous saisissez pas trop la nuance, mais faites mois confiance c'est plus mieux bien avec ma nouvelle méthode."

Ouais, nan, là je pense que ça va donner :
"Ouais, alors là, j'ai une super idée ! On va faire 200 propriétés dans chaque objet, dans lequel on met les objets de la collection. Ben oui, parceque les collections sont pas typées, alors c'est lent. Et après, pour aller lire les objets dans les proprités, qu'on va mettre Private évidement, on n'est pas fonctionnaires quoi ! hé ben on va créer 200 méthodes pour savoir combien de ces propriétés sont remplies. Et 200 autres pour récupérer les données. Faites bien attention par contre, parceque dans les 200 qui chargent l'objet, il faut à chaque fois retourner une collection indexée par le nom de la propriété du sous-objet. Ca sera plus facile pour lire vous verrez."
 
Ouais, nan, là je vois ça arriver gros comme une maison, ça peut pas être autrement.
 
Là, le développeur qui vient de m'imposer de virer mes "for each" vient de faire chier le DBA qui a dû ajouter une colonne dans une table "historisée".
 
L'historisation se passe comme suit :
-> On a un trigger qui, sur update et delete, va faire un "insert into tabHist select *, getDate() from inserted" et coller ça dans une table qui a la même structure qui a en plus un champ date.
J'aime beaucoup le "select *". Comme ça, quand on rajoute un champ, même si on l'ajoute aussi dans la table d'historisation, vu qu'il se retrouve après le champ date en question... ben ça plante.
Et vu que la table d'historisation contient des centaines de millions de lignes, impossible de la recréer en passant par une table temporaire sans faire sauter l'espace disque du serveur.
Plutôt que de corriger son trigger DE MERDE, il vient de force le DBA à créer une nouvelle table !!! Qui n'a même pas le même ID que la table sur laquelle elle est rattachée
 
J'y crois pas ! Je rêve !
 
J'ai rien dit, parceque j'ai dû rajouter des champs sur une dizaine de table (clés composées incomplètes, je suis dans la 4° dimension !), et du coup j'ai changé autant de trigger pour les écrire proprement. Vous allez voir qu'il va me forcer à réécrire les trigger comme avant et me faire mettre mes bouts de clées composées dans de nouvelles tables !

J'ai rien dit, il vient de tilter en se disant que le select peut utiliser autrechose qu'une *.
Mais ça suffisait pas, parceque évidement, si c'est pas dans le même ordre que ce qu'il y a dans la table d'historique, ça marche pas.
 
Je viens de lui expliquer que dans la clause INSERT, on peut spécifier la liste des champ à insérer, et imposer leur ordre. Illumination totale ! Bon, y'a au moins un trigger qui sera propre dans la base
 
-- edit --
 
mouarf ! Il est en train de gromeler et hésiter à faire machine arrière : "j'aime pas quand il n'y a pas un standard pareil pour tout"
 
ouais, ben le standard, tu prends le truc propre, surtout quand ton truc crasseux marche pas !