Discussion :

[Polygos]

Bonjour
j'ai un souci que vous devez tous avoir eu un jour ou l'autre.
J'ai une base de données vivante à laquelle sont attachés des codes qui traitent les données.
Bien sur ces codes vivent en permanence, j'y fais des modifications.
Le nombre de caractères possibles pour nommer un code étant limité, c'est deja pas simple de savoir ce qu'il fait, j'en ai environ une vingtaine sur ce même fichier de basee de données.
Evoluant tous les jours, la BDD change de nom (réf = nom + date + heure).
Parfois ej fais des modifs adaptées aux nouveaux besoin, avecplu sou moins de succès, ce qui fait que j'ai bien du mal parfois à retrouver quelle version du code est ds tel ou telle BDD.
Du coup, pas évident de savoir ce qui a évolué à chaque version de la BDD.
Comment gérez vous ça au mieux ?
1/ existe t il un log qui édite un logigramme en lisant le code ?
2/ peut on augmenter la longueur du titre du code ?
3/ comment, a part à la mano, éditer une liste des écarts de code de telel ou telle version, sachant que ces versions d'un même code peuvent évoluer de telle ou telle version de l aBDD ?
Ex: la BDD 1008 2200 du 10 aout 22h a un code d'édition d'un ficher d'export de données pour telle application.
Je l'ai faite évoluer sur la version du 1508 1600 par exemple.
Je voudrais pouvoir retrouver simplement les contenus différents de ces deux codes sans avoir à me peler la lecture de l'ensemble, parce que des fois des solutions antérieures fonctionnent mieux que la dernière (récente), mais pas l'ensemble, tout est affaire de compromis.
Qu'en pensez vous ?
Des fois ça concerne la logique d'où le besoin de voir rapidement le logigramme, des fois la manière de coder ou des fonctions particulières, par ex. ds telle version je ferme sans sauvegarder tel fichier créé, dans telle autre je laisse ouvert et je ne sauvegarde pas, je nomme le résultat (le fichier exportable) de tel code dans un répertoire, dans un autre dans telle autre version ( et est donc duplicable pour telle autre fichier cible), tout ceci correspond à une phase de développement bien sûr car il y ade nombreuses et utiles évolutions et tant mieux, surtout que cette BDD permet de créer de nombreux fichiers d'export des données, propres à différentes utilisations et que certaines smodifications (évolutions) sont parfaitement reproductibles pour tel ou tel usage, tel ou tel fichier d'export généré pour telle ou telle application.

J'espère que vous m'avez compris, je ne doute pas que vous ayez des astuces dont je me ferais volontiers l'écho par ce post !
Merci d'avance je suis curieux de savoir comment vous gérez ça !

[Patrice740]

Bonjour,

- Il faut séparer les données (la BDD) de la gestion des données (les macros) dans des fichiers séparés.
- Le fichier BDD ne doit pas changer de nom, c'est LA référence qui est par définition toujours considérée comme à jour.
- Ce sont uniquement les différentes sauvegardes qu'il faut identifier temporellement (pour pouvoir revenir à un état précédent) car ellesl représentent toujours le fichier à un instant passé, que ce soit pour la BDD ou pour les macros.
- Pour ce qui est de suivre l'évolution des macros, il suffit d'être méthodique et d'attribuer à chaque procédure un numéro adapté au suivi.

Par exemple, j'utilise un numéro de suivi composé de 3 élément (Par Ex. V1-0-00) :

• Le numéro de version : pour chaque évolution majeure ou refonte complète de l'application
• Le numéro de modification : pour chaque modification importante du fonctionnement d'un ou plusieurs modules
• le numéro de "build" : pour chaque évolution mineure ou débogage dans un ou plusieurs modules

- Avant chaque modification de macro, même mineure, j'enregistre une sauvegarde avec son numéro de suivi dans le nom du fichier (pas besoin de la date, c'est pas assez parlant).
- A chaque modification, qu'elle soit majeure ou mineure j'utilise un numéro supérieur au précédent quel que soit le module où se situe la modification
- En-tête de chaque procédure modifiée j'historise (sur une nouvelle ligne) la date le n° de suivi et une explication sommaire de la modification.
- En-tête de chaque module modifié, j'historise la date le n° de suivi et le nom des procédures modifiées.
- Dans Thisworkbook, j'historise la date, le numéro de suivi et le nom du ou des modules concernés.

Quand le code est correctement architecturé, les procédures et fonctions sont élémentaires et donc relativement courtes : il n'y a jamais besoin de comparer 2 codes ligne à ligne.

Autrement, pour comparer, ligne à ligne, 2 fichiers textes (par exemple deux codes VBA très mal architecturés, relativement longs) j'utilise npp++.