Help, comment faut-il s'organiser pour être efficace ?

Question

J'ai pris l'habitude de construire un programme en commençant par "le coeur", la routine des routines, en négligeant dans un premier temps l'icône, la couleur, etc.

Et puis cette version 1.0 évoluant, les bugs sont corrigés, de grandes modifications apparaissent, parfois il existe le besoin de rétrograder de version.

Comment faire cela sans se prendre les pieds dans le tapis ? (j'ai perdu la version précédente, ma version fonctionnait mais avec un module différent, etc).

Je travaille sous VB6. Faut-il sauvegarder chaque nouvelle version, par exemple v1.33, ".vbt, .frm .bas" dans un répertoire "version 1.33". Existe-t-il une sauvegarde t qui vient s'ajouter à une sauvegarde t-1 ?

Existe-t-il une règle, une astuce, une formation.

Merci de vos conseils.

Cordialement à tous

Emer

tmcuh · Answer

il est logique quadn on construit une maison de commencer par les murs et non par le toit. Il faut donc commencer par faire un plan.. dire je dois utiliser cà, cà , mon prog doit faire cà et cà... en clair construire sur papier ou dans sa tete, les fonctionnalité du programme de base. Déjà essayé de penser plus loin.
Créer des constantes global qui permette de modifier très facillement les valeurs et de façon lisible sans devoir aller regarder dans le code ce qui s'y passe.
essayé de créer un max de fonction, sub... afin de faciliter les futurs accès par d'autres et ainsi "optimiser" le code.
faire un maximum d'indexation (sans en abuser) pour faciliter la programmation.
Maintenant sauvegarder, cà dépend de la taille du programme, un prog qui fait 4000 lignes et un prog qui en fait 50 c'est différents... 
Le disign vient à la fin... sauf si tu veut faire des skins, à ce moment là tu dois les penser avant, mais tout cà vient dans ton schéma de base. pense à faire des ordinagramme ou organigramme (cà dépend qui le dit lol) 

Amicalement TMCUH

MoiOlivier · Answer

Salut,

En ce qui me concerne, j'ai pris l'habitude d'effectivement sauvegarder les versions successives de mes codes dans des dossiers différents. 
Un simple copier coler et je renomme le dossier...
Et, environ toutes les dix versions, je remets le compteur à zéro.

C'est probablement pas la solution la plus adéquate, mais ça fait des années que je fonctionne comme ça et je n'ai plus jamais perdu de lignes de code.

Bonne prog, @+

cs_CanisLupus · Answer

Je dirais que cela dépend de ce que tu prog.

Si tu prog pour toi ou que tu fais des essais de certaines techniques, tu peux te permettre de laisser le design de côté, quoique faut pas exagérer. J'ai vu, ici, des sources avec des forms surchargées de controles qui se cachent les uns les autres.

De plus, en VB6, on peut mettre du code un peu partout, bonjour le debuggage, donc il faut avoir un peu de rigueur.

Personnellement, comme professionnellement je développe en grande majorité des applis qui offrent une interface visible par les utilisateurs, j'ai une méthode qui marche et qui permet de ne pas perdre du temps pour rien :

1 - Analyse du problème, de la demande du client, du cahier des charges,....
2 - Si possible, voir sur le terrain comment les utilisateurs travaillent et se débrouillent sans la future appli. Avec les questions du genre "est-ce vraiment nécessaire", "n'y a-t-il pas déjà une appli, un logicel qui fait ça ?", ....
3 - Je fais un compte rendu de tout ça et demande au client de le valider ou d'apporter modif s'il y a lieu, voire de modifier son cahier des charges.
4 - Seulement après accord, je passe en phase de conception et je commence par établir DES ordinogrammes (ou organigrammes) les plus complets possible représentant les diverses fonctions de l'appli, les enchainements, enfin tout ce qui concerne l'ossature de l'appli et les bases de données.
5 - A partir de là seulement, je lance VB (ou autre) et je commence par créer toutes les forms utiles au projet (les utilisateurs disent plus souvent les écrans) et je travaille sur ce que verra l'utilisateur (menus, enchainement des forms,...). A ce point, je n'ai pratiquement pas écrit une ligne de code.
6 - Encore une fois, je retourne voir le client pour qu'il valide ou non l'aspect et l'ergonomie de la future appli.
7 - Si on est d'accord, je plonge enfin sur le clavier pour pondre le code mais je n'oublie jamais le client à qui je peux demander de valider telle ou telle partie de l'appli.
8 - J'effectue des tests en fonction des éléments fournis et affine le code s'il y a lieu.
9 - L'appli est mise en pré-production, histoire de faire des tests grandeur nature (une sorte de version BETA).
10 - Quand tous le monde est ok, l'appli est mise en production (recettée, installée, .......).

Bien évidemment, je classe et conserve tous les documents  créés ou échangés avec le client. De cette façon, je peux suivre l'historique de l'appli.

Pour le code lui-même, je mets le moins de code possible dans les événements des forms et des contrôles.
Comme j'ai découpé précemment l'appli en fonctions principales, je crée au moins un module par fonction. Par ex : un module comprendra la saisie, modif, visu des données, un autre s'occupera des statistiques, un autre de la communication, .......

Je déclare le moins de variables possibles en PUBLIC (dans un module, ou une form, toutes mes variables sont en private et seules les sub et function appelées d'une form ou d'un autre module sont en public). Pareillement, inutile de déclarer une variable dans le général si on ne s'en sert que dans une seule function ou sub.

Si j'ai des variables ou des api utilisées partout dans l'appli, je crée un module où je les range en public.
Tout ça, ça me permet d'avoir des modules réutilisables dans d'autres applis sans trop de modif. C'est un peu le principe des DLL et des controles utilisateur. Et puis, surtout, s'il y a une modif à faire, sur demande du client, ou si j'ai trouvé une meilleure méthode pour faire la même chose, ça m'évite de chercher dans tout le code.

Ha, j'allais oublier, tellement ça me parait évident ! Les COMMENTAIRES !
Si on programme en équipe, c'est OBLIGATOIRE.
Si on programme seul, on se comprend sur le moment mais dans qques mois ? et puis si un collègue doit reprendre l'appli ? Il ne s'agit pas bien sùr de coller l'aide de VB à chaque ligne mais une petite explication de ce que fait telle boucle, telle function,.... ce n'est pas inutile. Et puis, les commentaires n'alourdissent pas l'EXE.

Ca parait long et fastidieux, comme mon texte, hein ? Oui, c'est vrai. Mais si on compte le temps passé à débugger et/ou à modifier une appli après livraison (il y a des exemples célèbres mais je ne citerai pas de noms), je crois que ma méthode n'est pas si mauvaise que ça.

Cordialement, CanisLupus

Tous les glands ne deviennent pas des chênes mais tous les chênes ont été des glands

cs_CanisLupus · Answer

Pour le côté sauvegarde, je ne conserve que la version précédente, au cas où.

Cordialement, CanisLupus

Tous les glands ne deviennent pas des chênes mais tous les chênes ont été des glands

michel_renard · Answer

Merci de tous vos conseils. On se lance dans une programmation, sans formation préalable à la maintenance, ou à l'évoluyion naturelle du programme.

Je remercie encore CanisLupus qui a écrit mes premières lignes de code.

Le problème était:
Je suis médecin et mon programme professionnel multiplie les clics.
Je clique sur l'icône imprimante:
premier message: faut-il imprimer l'ordonnance en 1 ou 2 exemplaires.
ensuite fermer la fenêtre et 
deuxième message: faut-il enregistrer l'ordonnance dans le dossier.

La première version ne permettait pas le paramétrage: une volée de bois vert. Les utilisateurs voulant conserver les possibilités des messages.
La deuxième version instaure "la règle et l'exception", mais les premiers testeurs relatent un bug imparable puisque de conception (l'exception étant de maintenir la touche Ctrl enfoncé en même temps que le click).
La troisième version invente la notion de click droit sur une icône de commande (en fait on détecte le click droit, et on renvoie un click gauche, sachant que c'est un click droit, la réponse au message est l'inverse). 
Click gauche sur l'icône imprimante --> impression 2 exemplaires (le plus habituel).
Click droit sur l'icône imprimante --> impression 1 exemplaire (- utilisé).
Click droit ou gauche maintenu enfoncé --> pas d'enregistrement (+ rarement).

La greffe prend, je détecte les messages affichés, je récupère les commandes de l'utilisateur (click droit) et j'introduis les réponses en conséquence.

Et puis s'est ajouté un éditeur de posologie rapide: 1c2fjp1m=1 comprimé 2 fois par jour pendant 1 mois.
Avec les possibilités d'évolution: plusieurs mots par touche m="le matin " à la première pression m=", le midi " à la 2ème pression et m=" mois" à la troisième ...

Même si l'idée du départ est bien nette, que l'on construit les murs avant le toit, il apparaît des erreurs de conception à corriger. il apparaît qu'il faut faire un choix en fonction des possibilités et du désir des utilisateurs.
Contrairement aux fichiers .TXT qui deviennent .BAK lors de modifications. Microsoft Visual ne garde pas trace de l'évolution d'un programme.

Merci et cordialement à tous.
Emer

cs_EBArtSoft · Answer

Le conseil est simple, chaque nouvelle release doit donner lieu a un zip contenant TOUT les fichiers de l'application. Ces zip numeroté par la date du jour et le n° de version du prog peuvent etre stocké dans un repertoire "Historique" du projet.

C'est couteu en espace disque mais pour un projet professionnel il n'y a pas d'autre alternative (a part le CVS). Dans ce cas toute modification peut etre retrouvé sans aucun mal et toute les version anterieure peuvent egalement etre distribuer a nouveau a un client.

@+

E.B.

Help, comment faut-il s'organiser pour être efficace ?

6 réponses

Discussions similaires