Discussion :

[izguit]

Salut à tous,
On trouve beaucoup d'articles/topics sur les outils de développement et les conseils à adopter dans les projets. Malheureusement, ils sont TRES souvent plus applicables aux "gros" (ou moyens) projets : graphs uml, systeme de gestion de version style cvs, outils de gestion de projet style ms project, applis lourdes pour le travail collaboratif...
Dans le cas d'un petit projet de 2 mois maximum, seul (ou à la rigueur en groupe de 2-3 personnes), quels outils utilisez vous? quelle tactique? extreme programming? bonne planification et graphe de classes quand même? Les différentes versions? Les outils de publication? la gestion des bugs pour avoir des remontées?
Voila, questions TRES larges j'en suis concient Mais étant en train de peaufiner la v0.1 d'un petit utilitaire que je viens de terminer, ça m'intéresse pas mal de savoir comment on est "censés" faire dans ces cas là quand on est un VRAI codeur

M'sieurs dames, à vot' bon coeur, et bonne soirée

[koala01]

Salut,

Connais tu ce principe du "qui peut le plus peut le moins"

Pourquoi ne pas tout simplement l'utiliser, quitte à ne pas utiliser toutes les possibilités

Au niveau de la modélisation en elle-même, que tu travailles sur un projet important ou non, l'analyse des besoins, les différents diagrammes (de classes, de séquence, ...) seront de toutes manières utilisés

Au niveau du travail collaboratif (gestion de version et autre) ou des outils de publication utilise ce qui se fait si tu en a besoin, mais, si tu n'en a pas besoin, ben... laisse les de côté

Avoir une "road map" peut s'avérer utile si tu veux t'inciter à tout faire pour sortir ta version pour une date donnée, mais tu peux te contenter de la faire très simple (une date et un "état souhaité"), comme tu peux le faire de manière bien plus "pro"

Pour ce qui est de la gestion de bug, peut-être peux tu envisager de ne pas y avoir recours ... Mais, peut être souhaite tu au contraire, en disposer Encore une fois, c'est à toi de voir

Pour ce qui est, enfin, des conventions de codage, garde surtout en tête le fait que, un code que tu auras écrit aujourd'hui, et qui te paraît donc limpide aujourd'hui, risque de te sembler bien plus nébuleux dans quelques jours ou dans quelques semaines

Bref: utilise ce qui te semble intéressant, sans pour autant te forcer à utiliser quelque chose dont tu n'a pas usage

[Nip]

Il y a effectivement beaucoup a discuter la dessus; pour commencer, un outil de gestion de sources me parait indispensable si tu ne veux pas t'ouvrir les veines pour cause de crash de disque dur.
Si tu es tout seul un simple backup une fois par jour suffira; si vous etes 2-3 alors un outil plus evolue (VSS - c'est pas terrible mais a 2/3 c'est suffisant ou SVN) sera utile.
Pour les outils de gestion de projet, si tu veux mon avis, rien a taper; meme pour les gros projets c'est pas vraiment utile, un simple fichier excel suffira et tu trouveras des tas d'exemples sur le web.
UML c'est comme tout tu prends ce dont tu as besoin et tu ne te focalises surtout pas dessus. Le premier jour tes UCs et ton diagramme de classe doivent avoir ete discutes et etre boucles pour commencer a coder; de toute facon tu reviendras obligatoirement dessus plus tard: UML a le gros avantage de donner des diagrammes simples et lisibles rapidement, beaucoup plus que des milliers de lignes de code.

Pour ce qui est *vraiment* important, le code; essaye d'appliquer les regles XP concernant les cycles de developpement court. Tu codes les premieres fonctionnalites essentielles et l'interface qui permet d'exploiter tout ca et toutes les semaines et demi/2semaines tu envoies une build au client/testeur pour un feedback: il est content, il voit que ca avance et toi tu evites les commentaires tres desagreables du genre "c'est pas du tout ce que j'avais demande!" a la fin du projet.
Pour les conventions de code, ben tu fais au mieux en utilisant a bon escient la notation Pascal ou camel (et t'evites la notation hongroise), une classe <-> une reponsabilite... tout ce qui fait un code facile a lire et maintenable. T'evites aussi les commentaires inutiles, le nommage des variables et methodes devraient se suffir a eux meme.

Enfin pour la gestion de bug: plutot que de passer du temps en deboggage, je te conseille de regarder du cote des tests unitaires, c'est equivalent en temps d'ecriture au debogue et a la phase de test et nettement plus efficace en ce qui concerne la retro compatibilite. Une excellente introduction ici: http://bruno-orsier.developpez.com/t...inos/index.php

[izguit]

merci de vos réponses les gars

Je vois que j'aurais peut être du sortir mon tool uml avant de commencer M'enfin bon, tant pis...

Je met pas le topic en résolu, pour que ca ne ferme pas les autres réponses.