Discussion :

[Oparion]

@Jean-Philippe André :

D'accord, avec ces exemples je comprend où tu voulais en venir dans l'expression "atomiser le code en module".
C'est vrai que moi, je fais tout l'inverse... J'aime quand c'est tout dans le même module ! Ca m'évite de naviguer dans différent module, mais ça manque clairement de clarté etc...
Je vais appliquer ce que tu viens de me dire !

@Pierre Fauconnier :

Je n'utilise aucun UserForm dans mon fichier Excel, peut-être que cela va te réorienter sur d'autres possibilités de réponses ?

Au niveau des variables, j'ai compris que tu attribues une variable à une tâche.

Je n'ai pas de liaison ou de chemin comme celui que tu m'as présenté.
Mais j'ai des Range... est-ce que ça en fait partie ?

Concernant être systématique, je ne pratique pas sur de UserForm mais je pense l'appliquer sur mon code. Essayer de structurer mieux mon programme.

[el_slapper]

(.../...)Qu'est qu'un test unitaire ?
Je vois qu'il faut télécharger un logiciel, élément que je ne peux réaliser en entreprise à cause des protections.

Alors on oublie Rubberduck. Dommage. Mais des tests unitaires faciles à exécuter restent un point important. Alors, qu'est-ce que c'est? Mes estimés collègues ont a juste titre insisté sur la nécessite de découper ton code en entités de taille réduite. Idéalement, on ajoute un peu de code qui permet de tester les fonctions ou les procédures. Évidemment, on range les tests unitaires ailleurs, par rapport au code de production(celui qui t'est demandé).

un exemple simple, qui convient à de petites applications. C'est un exemple Access, mais il est très bien, car il insiste sur la nécéssité de sauvegarder les données modifiables par le test AVANT de faire le test, et de les restaurer après. La seule différence, c'est que tes données ne sont pas dans une base access mais dans un tableur Excel(je suppose).

[unparia]

Je vous prie d'excuser ma question, si elle est idiote, mais ...
Cette discussion a été ouverte en vue de déterminer la manière de pérenniser un CODE vba.
Je fais personnellement un distinguo important entre CODE et APPLICATION.
Je serais donc reconnaissant au demandeur de préciser ce qu'il convient de pérenniser (les deux démarches n'étant pas les mêmes).

EDIT : et s'il s'agit de l' APPLICATION, je comprends assez bien pourquoi ses tuteurs lui ont posé cette question, s'agissant de Excel.

[clementmarcotte]

Bonjour,

Comme je l'ai dit, je pense qu'il ne sert à rien de commenter ton code comme je l'ai illustré, sauf si tu souhaites générer une documentation en automatique. Il me semble que bien nommer ses fonctions et ses variables est plus important que de les nommer n'importe comment puis de les commenter pour les expliquer.

L'éternel débat, ou, comment dire, l'évolution du commentaire, du codage et de la programmation en général.

Cela ne nous rajeunit pas personne, mais je me souviens qu'avec les variables à 6 caractères du Fortran, ou même à deux caractères des premiers BASIC; l'obligation de commenter en détail les noms de variables, prenait tout son sens. Et l'omniprésence du GOTO, n'ajoutait rien à la clarté du code, et nécessitait des commentaires.

Je suis bien d'accord avec le fait que VBA, autorise, et même oblige, de morceler le code, et la possibilité d'allonger les noms de variables, rendent les commentaires beaucoup moins nécessaires.

Malgré. tout, en tenant compte de la question de unparia, que je salue au passage, il me semble que l'on ne peut pas échapper aux commentaires, surtout pour les trucs et astuces personnels, les passes géniales, ou méconnus, l'algorithme utilisé, et pourquoi.

Je dirais aussi une explication succincte du but d'une procédure. Et cela me semble aussi un bonne idée de rappeler pourquoi on rappelle tel sous-programme, surtout quand le nom du sous-programme n'est pas aussi explicite qu'il le faudrait.

[unparia]

De bon matin, donc, pour que l'on comprenne moins mal tout le sens de ma question antérieure.
S'il s'agit de pérenniser non le CODE, mais l'APPLICATION dans sa totalité, il en va comme il en va dans de nombreux autres domaines : on ne protège pas, on ne pérennise pas, on ne modifie pas, etc ... ce qui n'est pas établi. La 1ère des conditions à réunir, par exemple, pour divorcer est ... d'être marié.


---->> nécessité n° 1, donc : --->>>

- savoir au moins à quelles spécifications fonctionnelles (à ne pas confondre, à ce niveau, avec les spécifications techniques) correspond l'appli.
Une appli dont on ne connait pas avec précision les tenants et aboutissants est une appli qui finit généralement aux oubliettes.
Ces spécifications fonctionnelles sont en général consignées sur un cahier des charges clair, précis et parfaitement rédigé (niveau M.O.A, donc)

Ce n'est là que la toute première nécessité.... (car la liste va devenir très longue, vous verrez ...)

[Oparion]

@el_slapper :

Concernant les test unitaires, ce que j'ai compris c'est qu'il faut venir tester les fonctions une à une et vérifier qu'elles fonctionnent bien toutes. Mais si ma macro globale fonctionne c'est que toutes les fonctions présentes fonctionnent... ? Peut-être que je me trompe.

@unparia :

Aucune question n'est idiote, sinon je ne serai pas là
Tu dis : Je fais personnellement un distinguo important entre CODE et APPLICATION.
Pour ma part, je ne vois pas la différence.

Pour nous permettre de nous aiguiller, voici les grandes étapes que réalise mon fichier :
1 - L'opérateur vient coller une série de données dans un onglet.
2 - Il clique sur le premier bouton qui vient :
2a - Séparer les données de l'expérimentations et les mesures
2b - Trier les mesures
2c - Réaliser les graphiques avec un nombre de graphique équivalent au nombre de sondes
2d - Créer un nombre d'onglet égal au nombre de sondes
3 - Il clique sur un deuxième bouton qui vient :
3a - Créer de nouveaux graphiques avec des tolérances, moyenne, consigne.
4 - Fin du programme.

Ce qui est à pérenniser c'est le code (je pense) faire qu'il soit explicite et qu'il puisse être repris par quelqu'un d'autre.
Ce fichier Excel sera utilisé par le service métrologie de mon entreprise, pour le moment il n'est pas étendu à d'autres services ou autre entités du groupe, il sera donc utilisé par 2 - 3 techniciens métrologues pour la vérification d'étuves, fours, bâtis...
Il n'y a pas de cahier des charges, de consignes, rien de rédigé. C'est moi qui ai pris l'initiative de ce fichier pour améliorer les PV (Procès Verbaux) lors de vérifications d'étuves, fours, bâtis.


Si je n'ai pas répondu à ta question, n'hésite pas de me demander...


@clementmarcotte :

Tout d'abord Bonjour clementmarcotte, bienvenue sur ce fil de discussion et merci de ta réponse.
D'après ce que tu as dis et des réponses des autres contributeurs, voici ce que j'en ressort :

1 - Séparer le gros code en plusieurs modules
2 - Rédiger une partie procédure expliquant ce que réalise le code du module
3 - Ne pas tout commenter, mais seulement les parties intéressantes : astuces, algorithme, formule mathématique.

[unparia]

Ce qui est à pérenniser c'est le code (je pense) faire qu'il soit explicite et qu'il puisse être repris par quelqu'un d'autre.

J'insiste donc : Pérenniser le code ne sert à rien tant que ce qui doit être fait en amont n'est pas fait.

Pour ma part, je ne vois pas la différence.

Elle est E N O R M E !

Il n'y a pas de cahier des charges, de consignes, rien de rédigé.

L'essentiel manque donc. Essentiel, car ces spécifications fonctionnelles sont la définition même de la vocation de l'application.
D'autant qu'à un moment ou à l'autre, il va en plus falloir mettre "en regard" les spécifications fonctionnelles et les spécifications techniques (au moins cela, même si l'on a fait "harakiri" de la modélisation des données).

Ta réaction fait que je n'ose même plus de parler des différentes dépendances, à divers niveau et de diverses natures (aucune pérennisation n'est possible sans les isoler et les prendre également en compte)

Crois-tu vraiment que l'intervention de ton jury était "gratuite" et "naïve" et n'avait pas un sens et une vocation très justifiés (à deviner) ?
On ne compte plus les colères de différents responsables informatiques, responsables de centre de traitement de l'information, chefs de projet etc ... causées par la découverte de la présence de nombreuses petites applications qui n'observent pas les règles nécessaires à :
- leur définition
- leur recensement
- leur suivi
Le fait est qu'elles sont la plupart du temps construites à l'aide d'applications bureautiques, dont Excel.

[Oparion]

@unparia :

Qu'est-ce qui doit-être réalisé en Amont ?

Donc il faut que je réalise mon propre cahier des charges ? Qui en plus ne sera pas lu ?

Tu as dit : Ta réaction fait que je n'ose même plus de parler des différentes dépendances, à divers niveau et de diverses natures (aucune pérennisation n'est possible sans les isoler et les prendre également en compte) => Quelle réaction ? Et je ne comprend pas tout ce que tu expliques, m'enfin.

Tu as dit : Crois-tu vraiment que l'intervention de ton jury était "gratuite" et "naïve" et n'avait pas un sens et une vocation très justifiés (à deviner) ? Si je pensai que cette intervention était gratuite et naïve, je n'aurai pas créé cette discussion et je ne serai pas actuellement à la recherche de solutions. Ca me paraît évident...

Je suis d'accord sur ton dernier point, mais ça c'est à moi de voir ça en interne.
Si d'abord, c'est nécessaire ? Et si ça vaut le coup.

[Pierre Fauconnier]

Oparion,

J'ai deux questions: En quoi es-tu étudiant et quel est le sujet du travail que tu présentes au jury?

[Oparion]

@Pierre Fauconnier :

Je suis étudiant en Sciences.
Pour ma deuxième soutenance je vais leur présenter mes travaux sur les incertitudes liés à des bancs d'essais.
Concernant Excel, je ne vais plus rien présenter (normalement).
Comme je l'avais noté je n'ai plus de comptes à rendre au jury sur ce point.
Mais pouvoir laisser un code documenté, c'est ce que m'a demandé mon maître d'apprentissage.

[unparia]

pouvoir laisser un code documenté, c'est ce que m'a demandé mon maître d'apprentissage.

J'imagine (c'est un minimum).
Ce n'est cependant pas l'objet de la discussion que tu as ouverte, ni (au vu de ses réactions, que tu rapportes toi-même) la réponse qu'attendait ton jury, hein ...

[Oparion]

@unparia :

En effet, un professeur m'a dit : Ce n'est pas suffisant.
Donc me voila à la recherche de solutions

[Invité]

Bonjour,

Je dirai en réalité que le langage de programmation Vba; dot.net (Framework qui pour le coup n'a rien à voire avec le web), n'importe peut dans un premier temps et bon nombre de décideurs n'y comprennent rien!


Ce n'est pas pour autant qu'ils n'ont pas besoin d savoir quoi il en retourne.

Si le projet n'est pas assujetti à un cahier des charges nous aurons à cœur de le rédiger afin de formalise et borner le périmètre de l'application! Nous le soumettrons aux demandeur pour éviter tous malentendus par la suite.

Nous établirons un cahier de faisabilités afin de définir les prérequis; les doutes que tel ou tel partie ne soit réalisable.

Nous développeront des méthodes sommaire pour valider que nous savons envoyer du texte sur le port série par exemple!

Nous traceront la trame du cahier de spécificité, en d'autre terme nous découperons notre application en fonctionnalités ce qui nous permettra de chiffrer notre intervention.

Et ce que tu nous à présenté plus haut ressemble plus a un cahier embryonnaire qu'à un truc aboutit.

Nous élaborerons un planning comprenant l'étude,manuel utilisateur,les échéances des livrables etc...

Une fois ces informations validé par les décideurs nous pouvons entrer dans le vif du sujet!


Nous reprenons notre cahier de spécificités et nous retravaillons chaque rubrique en couches de détails de plus en plus fin. Jusqu'à obtenir un niveau de détails du genre si alor si non! On reste dans un niveau de langage neutre de toutes programmation!
en oublient pas qu'il s'agit de descriptif! Avec un dictionnaire des terme technique, pourquoi tel méthode présentation d'exemple.

Si l'analyse fonctionnel par certaines aspects est très similaire elle s'adresse avant tout aux professionnels et aux développeurs en charge de code et/ou de la maintenance!

Le cahier de spécifié doit pourvoir être lue par un quidam de la rue!

Ont détermine quelle plateforme de programmations est la plus approprié! Un environnement de développement;de test etc..

Le versionning...


Notes qu'il est habituel de formater ses documents en rubriques avec présentation; développe conclusion!

Et on ce retrouve avec des présentations en cascade et on ce tape tous le texte qui ne concerne pas notre niveau de compréhension avant le conclusion en cascade!

Nous placerons le conclusion après les présentations afin de permettre au lecteur de passer le détail le cas échéant

En ce qui me concerne j'utilise un helpeur html!

Indépendamment de ça ta note était convenable? C'est rare ce genre de question! Parfois les examinateur posent ces questions pour donner l'occasion a l'élève de ce justifier et améliorer sa note!

C'est plus une perche qu'une sanction!

Il est de notoriété publique qu'un stagiaire n'est pas des plus expérimenté et qu'il a des lacunes! Sen compter que parfois son maître de stage est un baltringue!

J'ai coaché pendant 6 mois sur ce forum un jeune dans ce cas là!

[Oparion]

Bonjour dysorthographie et merci de ta réponse.

Concernant tes remarques, voici ce qui en ressort de mon côté :

- Je n'ai jamais rédigé un cahier des charges, cela peut être l'occasion, aurais-tu une trame ou quelque chose comme cela ?
- Idem pour le cahier de spécificité
- Qu'entends-tu par chiffre notre intervention ? Le coût (euros) ? Le temps ? Le gain (euros) ? Ou autre ?
- Je vais essayer de me renseigner sur le helpeur html, peux-tu m'en toucher 2 mots ?

Oui au delà de cette remarque, ma soutenance c'est très bien passé, j'ai eu environ 15 et je me place 3ième de promotion au Semestre.
Il est de notoriété publique qu'un stagiaire n'est pas des plus expérimenté et qu'il a des lacunes => En effet !
Sen compter que parfois son maître de stage est un baltringue ! => Ce n'est pas le cas ^^

[el_slapper]

Concernant les test unitaires, ce que j'ai compris c'est qu'il faut venir tester les fonctions une à une et vérifier qu'elles fonctionnent bien toutes. Mais si ma macro globale fonctionne c'est que toutes les fonctions présentes fonctionnent... ? Peut-être que je me trompe.(.../...)

Le cycle de vie d'une application, c'est 20/30% en développement, et 70/80% en maintenance. Enfin, une application pérenne. Or, ta question porte sur la pérennité. Donc il faut que tu sois fiable dans le temps, facile à maintenir. Quand tu reviens sur une appli un peu vieille, tu ne sais plus très bien quoi fait quoi. Les tests unitaires servent en partie à ça : tu regarde comment ça appelle la fonction, et tu comprends comment ça marche.

Mais le vrai plus, c'est quand tu dois changer ta fonction/procédure/méthode/propriété. Les vieux tests unitaires que tu as écrit dans une autre vie doivent toujours tous passer OK. Sauf, évidemment, là ou tu as spécifiquement changé ton comportement. Exemple : on gère des payements pour un tas de trucs. On a une fonction centralisée un peu compliquée qui ramène le type de payement, et qui est appelée partout. Ca marche. On est contents. Bon, dedans, il y a une règle un peu relou qui veut qu'un paiement par TIP se fasse en fait par chèque si le montant dépasse un million d'euros. tout simplement parce-que les TIP pré imprimés n'ont que six cases avant la virgule.

Bon, le temps passe, et puis le fournisseur de pré imprimés ajoute deux cases. Cool. Mais il faut changer la fonction(d'ou l'intérêt d'avoir fait des petits bouts, si tu faisais la décision pour chacun de tes 23 produits, tu serais chocolat - mes collègues avaient raison de t'inciter à faire des petits morceaux). Une fois. Puis la tester.

Si tu as fait correctement ton test unitaire, dans le temps, tu as juste à adapter au nouveau comportement : un payement prévu par TIP qui dépasse le million se fait toujours par TIP, il faut qu'il dépasse les 100 millions pour forcer le paiement en chèque. Tout le reste, les virements de toutes sortes, ne change pas. Et tu en as pour 10 minutes à valider ton changement. Si tu n'as pas fait de tests unitaires automatisés, par contre, le risque de régression est grand. Une régression, c'est quand on corrige un truc à droite, et qu'on casse un truc à gauche. Ca arrive tout le temps. Et, avec des tests unitaires bien pensés, ça se détecte tout de suite, on répare, et on évite de transformer un virement en paiement par chèque, ou vice-versa.

En bref : les tests unitaires automatisés sont modérément utiles lors du développement initial - pas inutiles, pas transcendants non plus - mais ils deviennent essentiels quelques mois après leur écriture. Une appli, ça vit, et il faut des outils pour vérifier qu'on ne casse pas tout à chaque maintenance.

[Oparion]

@el_slapper :

Grâce à ta définition du test unitaire et de ton exemple j'ai compris ce que c'est.

Mais il me vient plusieurs questions :

- Je dois disloquer mon code en plusieurs modules. Sauf que si je le fais, dans chaque module je vais devoir créer un nouveau

Code :

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

Sub

.
Au lieu d'avoir (comme actuellement) :

Code :

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

1
2
3
4
5
Sub Manger une pomme
Acheter la pomme
Rincer la pomme
Éplucher la pomme
Manger la pomme

J'aurai :

Code :

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

1
2
Sub Manger une pomme
Acheter la pomme

Code :

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

1
2
Sub Manger une pomme2
Rincer la pomme

Code :

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

1
2
Sub Manger une pomme3
Éplucher la pomme

Code :

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

1
2
Sub Manger une pomme4
Manger la pomme

Comment je peux intégrer tous ces codes sur un seul bouton ?
Si il y a une technique ou autre je ne l'a connais pas, je veux bien que quelqu'un me l'indique


- Comment mettre en place des tests unitaires dans mon code VBA, sachant que je ne connais pas RubberDuck... ?

[Jean-Philippe André]

Salut,

pour les tests unitaires, que je mets dans le meme sac des tests de non regression (s'assurer que le fait de modifier un bout de code ne fait pas tomber un autre domino ailleurs dans ton outil.

Une solution pratique est de passer dans la mesure du possible par des fonctions a la place des procedures, ce afin de pouvoir recuperer une valeur en sortie.

Une fonction de retour booleen suffit a faire ensuite des tests.

Cote manipulation de cette info tu pourras travailler avec par exemple

Code :

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

1
2
3
Sub Piou()
 
End Sub

qui deviendra

Code :

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

1
2
3
4
5
6
Function Piou() as Boolean
'code qui plante
Piou = False
'code qui marche
Piou = True
End Function

et cote tests automatises :

Code :

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

Debug.Print Piou = True

Des que tu as un False sur tes egalites => pb de regression

[Oparion]

@Jean-Philippe André :

Bonjour Jean-Philippe André

Avec ton exemple je vois comment mettre en place un test unitaire (régression).
Via une fonction booléenne, ça me paraît plutôt "facile", je pense essayer cela rapidement.

Mais ce que je cherche maintenant à savoir faire avant de réaliser ces tests unitaires c'est :

Augmenter le nombre de module (= atomiser mon code en plusieurs codes dans plusieurs modules) sans pour autant augmenter le nombre de boutons.
Les futurs utilisateurs ne connaissent rien en VBA et surtout plus il y a de boutons, plus le risque qu'ils se trompent (même si il y a une procédure etc etc) est grand.
Je suis actuellement avec 3 boutons sur mon fichier (Remise à zéro du fichier / Création des graphiques / Création des graphiques ciblés) et j'aimerai ne pas dépasser ce nombre.

[Jean-Philippe André]

Hum,

pour les boutons, as-tu cree un userform ? si tu veux proposer une plus-value graphique, cree un ruban personnalise

[Pierre Fauconnier]

Salut.

Si tes utilisateurs doivent manger une pomme et que ton appli doit leur préparer la pomme, tu auras un seul bouton manger une pomme.

Mais toi, tu sais que pour qu'ils mangent la pomme, il faut la rincer, l'éplucher, ... Donc tu vas découper ton code en fonction de la responsabilitéde chaque fonction dans le traitement. La fonction de nettoyage doit rincer la pomme et l'essuyer, pas l'éplucher... Et la fonction Manger la pomme à la responsabilité de chaîner les actions qui permettront à l'utilisateur de la manger.

Ton code va donc avoir le look suivant et tu stockeras ces procédures dans le module Pomme:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
sub MangerLaPomme() ' Procédure appelée par clic sur le bouton
RincerLaPomme
EplucherLaPomme
OffirLaPomme
End Sub
 
Sub RincerLaPomme()
...
End Sub
 
sub EplucherLaPomme()
...
...
End Sub
 
Sub OffrirLaPomme()
...
...
End Sub