Organisation de fichiers

Airballman · Le 04/06/2010, à 15:56

Bonjour,

Je vous pose une question un peu ouverte sur un problème que j'ai depuis un moment, et qui est pire en pire avec le temps qui passe.

SI vous êtes sur ce forum c'est que vous programmez tous plus ou moins longtemps et souvent. Comment faites pour gérer la multitude de fichiers qui se créent lorsque vous codez?

Je suis en stage depuis bientôt deux mois, et j'ai engrangé à peu près 200 fichiers .m (matlab) divers et variés, à tel point que je ne sais plus quoi en faire.

J'ai bien essayé de les ranger par dossier, mais au bout d'un moment je suis toujours en train de flotter dans un flou total. L'inscription de numéros de version (essai_0.1.m) est sympa dans l'idée mais quand il y a plein de chose a faire ca devient vite essai_0.2.m, essai_0.1_ac std.m, essai_0.1_histogramme.m, essai_0.3_samedi aprem.m et c'est encore pire...

EN general quand la situation devient telle, je fais un enorme menage et je supprime 90% de mes fichierS. Et dans le tout il y a toujours des trucs importants...

La galère quoi.

MA question donc : comment faites vous pour vous organiser efficacement dans vos fichiers de programmation.

(Et c'est valable a plus grande echelle pour les fichiers en general (mais mince ou est ce que jai mis cette foto ou cette musique qui parlait de .... et dont je ne me souviens plus le nom)

Epehj · Le 04/06/2010, à 16:23

Salut,

Moi dès que je code pour un projet, j'utilise un gestionnaire de version.
Clearcase au taf, SVN chez moi.
Et tout est codé dans les fonctions, j'ai des fonctions de "test" ou je fais..mes test, donc quand j'estime que c'est devenu trop flou, hop, la fonction dégage.

yohann · Le 04/06/2010, à 16:23

salut,
pour ma part j'utilise svn, même s'il et surtout utile pour le travail en collaboration, ce n'est pas interdit de l'utiliser lorsqu'on est tout seul, donc je fait essai1, et au moment ou tu ferais enregistrer sous essai2, je fais svn commit. puis je modifie essai1.
je peux revenir ensuite à n'impore quelle version commitée de essai1.

svn est très simple a configurer et à prendre en main qd on utiliser le protocole file:// et qu'on est seul à développer, ce qui à l'air d'ête le cas pour toi.

Airballman · Le 04/06/2010, à 16:32

Merci de vos réponses rapides

J'ai testé aussi la gestion de versions. J'utilisais Git à l'époque (en grande aprtie pour la simplicité extreme).
JE trouvais que le probleme etait deplacé en fait, puisque la solution n'est plus de chercher parmi tous mes fichiers, mais parmi toutes mes versions

En fait ca me sers quand je code chez moi, c'est a dire par tranches de 2h. La que je suis a temps plein, ce devient ingérable.

Ceci dit je vais me repencher dessus (notamment svn).

yohann · Le 04/06/2010, à 17:27

ensuite lorqu'une version est particulièrement intéressante tu peux la taguer aussi.
mais de toute façon à la fin il y a toujours une grande quantité d'infos a retrouver, donc pas de solution magique à ma connaissance

Respawner · Le 04/06/2010, à 17:42

Il y a 2 ans de là j'avais effectué un stage où j'avais tout un lot de captures de flux réseaux à générer et à gérer (des fichiers de type PCAP). Le seul moyen que j'avais trouvé pour m'organiser et pas mettre 2 heures pour retrouver un fichier c'était de faire des dossiers / sous-dossiers avec des noms très précis pour savoir, dès la lecture du nom, ce qu'ils contenaient le tout calé sur des branches SVN (Bazaar aiment pas trop les fichiers binaires, dommage).

sputnick · Le 04/06/2010, à 18:29

Quitte à te pencher sur du versioning, je te recommande git ( développé par Linus Thorvald ).
Je pense m'y mettre 1 d c 4, tellement ya de bons retours dessus. ( je travaille avec svn ).

Airballman · Le 04/06/2010, à 18:35

J'ai testé aussi la gestion de versions. J'utilisais Git à l'époque (en grande aprtie pour la simplicité extreme).

Merci quand meme

Ceci dit , je te le conseille c'est vraiment le pied à utiliser!

Link31 · Le 05/06/2010, à 02:09

sputnick a écrit :

développé par Linus Thorvald

Sinon, personnellement j'ai un dossier ~/source, avec à l'intérieur un nombre incommensurable de dossiers pour chaque projet, et pour les versions de développement de certains programmes. Peu importe le nombre en fait, l'auto-complétion avec la touche tab permet de s'y retrouver facilement.

Et je trouve qu'utiliser un système de contrôle de versions pour un usage personnel est trop contraignant : comment nommer ou organiser les commits correctement quand on fait des dizaines de modifications ou des refactos un peu partout dans le code ? (courant sur des petits projet quand on est encore le seul développeur)

Souvent, des dossiers v1, v2, v3... pour garder une trace des changements majeurs peuvent être suffisants.

Le Farfadet Spatial · Le 05/06/2010, à 02:10

Salut à tous !

Pour ma part, pour gérer mes projets, tout d'abord j'essaye de bien distinguer chacun en des répertoires distincts, à l'intérieur desquels je représente l'organisation à l'aide de sous-répertoires. De plus, j'utilise un gestionnaire de version. Pour ma part, mon choix s'est porté sur Mercurial, mais tu peux utiliser Git ou Bazaar -- ce dernier, je le connais moins bien.

En revanche, dans la mesure où tu connais déjà les gestionnaires de version distribués, je te déconseille de t'orienter vers un gestionnaire centralisé comme SVN. Après tout, Linus TORVALDS a bien dit : « if you're not distributed, you're not worth using: it's that simple ». Je le prouve -- désolé, il y a du Flash :

[youtube]http://www.youtube.com/watch?v=4XpnKHJAok8[/youtube]

Je ne serais pas aussi catégorique que lui, mais, décidément, la gestion distribuée me semble à la fois plus puissante et plus simple.

À bientôt.

Le Farfadet Spatial

Airballman · Le 05/06/2010, à 22:40

Merci pour toutes vos réponses (avec des vidéos et tout je n'en demandais pas tant ). Ceci dit je suis resté collé devant ^^

Je vais essayer de me remettre à git je pense, et surtout faire mon possible pour l'utiliser correctement.

patrick L · Le 31/10/2011, à 01:10

moi je classe selon les fonctions programmes et selon les corrections de bugs...

par exemple je faisait un mat d'affichage de messages selon des criteres. j'avais souvent le protocole de dialogue à modifier. en gros une sorte de filtre.

alors j'avais le fichier interrupt.asm, decode.asm, appelauto.asm ensuite je mettais un sous dossier old avec les fichiers d'origine.

disons que je modifiais le fichier interrupt.asm je code les modifs dont j'ai besoin pour mes autres fonctions, lorsque vérifié que ca fait bien le travail alors je copie interrupt.asm dans un dossier ok01 avec peut etre un fichier indiquant ce que j'ai fait...

je vais donc dans decode. asm je fais les modifs dedans et bien sur je mets lorsque fait et testé dans ok1
je vais donc dans appel auto.asm et là probleme... je corrige alors interrupt.asm. et donc j'ai une version de interrupt et une version 2 suite à la correction. alors je dois modifier decode.asm... alors ce fichier est mis en ok3 dans la mesure ou ca puisse entrainer une modif supplementaire de interrupt.asm

là tu es sur et certain de te re retrouver quoi qu'il en soit... ensuite à un moment tu regresse.. les modifs de interrupt font que tu perds la fonction premier de la ligne série.

ensuite je mettais une signature des fichiers... en additionnant les octets du fichier... ca s'appelait crck32 bits alors le fichier interrupt.asm valait 255D878C ensuite le chef reprenait le dossier et calculait lui meme le crck32 du fichier qu'il avait.... si le code correspondait et ensuite avait la somme totale du projet. on avait meme le crck32 de la prom dans le mat et du fichier généré.

lorsque je bloquais... et bien je prenais la version ok2 de interrupt et je la testait pour voir si le conflit existe encore... et la version ok3 a le bug mais pas la deux..

je sais pas si tu as compris. mais faut organiser en fonction des bugs et des conflits qui vont arriver.... surtout à la fin du projet.

interrupt.asm
>>> ok1 interrupt.asm ---> ajout d'un flag determinant si en cours d'appel automatique pour envoyer sur un buffer de reception ou un autre.
>>>ok2 interrupt.asm ---> correction de bug de perte de reception lorsque on revenait sur le fifo par defaut.
decode.asm
>>>> ok3 fonctionnel 1 apres modif de interrupt.asm...
interrupt.asm
>>>> ok4 conflit important lorsque on demande le passage en appel auto pendant la reception de données en phase esclave du mat d'affichage. : décision prise de faire une analyse
appel auto.asm
>>> ok5 passage temporaire de la réception dans le buffer appel automatique
interrupt.asm
>>> ok6 diagramme de phase sur la demande d'appel automatique

et si tu as un collegue qui dit heu ton interrupt il me colle la me... alors tu prends l'objet (surtout pas le source) dans ok1 ou ok4 alors comme ca tu sais si le conflit vient de chez toi ou de chez lui.... tu sais à quoi t'en tenir en trois passages dans le linker.

en programmation faut toujours tout prévoir. Les autres travaillent également. au début tu as les "fichiers old des collegues". c'est pas toujours le cas que le collegue qui bosse en liaison avec toi ne soit pas en train de modifier les parametres de ses données qui te correspondent.

par exemple je faisais un protocole et je devais extraire des informations d'affichage et le collegue modifie les valeurs à envoyer. alors là ca fait des nuits blanches. faut organiser, au départ, des dossiers projets en prévision des problemes qui vont pas manquer. avis de connaisseur.

Airballman · Le 17/11/2011, à 17:43

Merci pour la réponse (un peu tardive mais intéressante ).

J'ai trouvé mon bonheur depuis dans git, ultra simple et qui permet de tracer toutes les anciennes versions.
Et pour pouvoir toujours comparer avec la derniere version ok, je bosse avec des branches.

master => code validé debuggé.
branche => pour chaque insertion de feature, modif, debuggage, . . .

Ca me permet d'avoir toujours une version stable de mon code, que je peux montrer en 2 sec aux gens, tout en ayant une version instable.

Voilou

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 04/06/2010, à 15:56

Organisation de fichiers

#2 Le 04/06/2010, à 16:23

Re : Organisation de fichiers

#3 Le 04/06/2010, à 16:23

Re : Organisation de fichiers

#4 Le 04/06/2010, à 16:32

Re : Organisation de fichiers

#5 Le 04/06/2010, à 17:27

Re : Organisation de fichiers

#6 Le 04/06/2010, à 17:42

Re : Organisation de fichiers

#7 Le 04/06/2010, à 18:29

Re : Organisation de fichiers

#8 Le 04/06/2010, à 18:35

Re : Organisation de fichiers

#9 Le 05/06/2010, à 02:09

Re : Organisation de fichiers

#10 Le 05/06/2010, à 02:10

Re : Organisation de fichiers

#11 Le 05/06/2010, à 22:40

Re : Organisation de fichiers

#12 Le 31/10/2011, à 01:10

Re : Organisation de fichiers

#13 Le 17/11/2011, à 17:43

Re : Organisation de fichiers

Pied de page des forums