Salut,
* parce que ne compter que sur sa mémoire, c'est prendre le risque
d'oublier tout ou parti des spécification de départ si à un moment donné
on délaisse momentannément le projet;
Je suis à la fois d'accord et pas d'accord. ON oublie facilement, c'est
très juste. Mais en même temps les bonnes idées qui sont vraiment bonnes
ne se'envolent pas comme ça, elles restent; et en plus, elles mûrissent
avec le temps, si on arrive à maîtriser sa précipitation (ce qui n'est
pas toujours facile, je me suis déjà souvent réveillé à 4h du matin avec
la super idée de la mort qui tue, me dépêcher de la coder pour me rendre
compte à 6h que c'était soit une idée de con, soit plutôt irréalisable)
Pour plusieurs jeux sur le Salon, il m'est arrivé que j'y réfléchisse
tout doucement pendant quelques mois, avant de coder le truc en 3 jours
à peine; et sans jamais avoir rien écrit.
Je suis peut-être un fou, c'est pour ça ?
* parce que sacrifier une heure pour définir les détails de son projet
c'est au final un gain en temps quand on passe à la phase de codage;
Pour un projet pro je suis d'accord, mais pour un projet perso/amateur
je ne suis pas totalement convaincu
* parce que tenir un cahier des fonctionnalités c'est la base de la
création et de la mise à jour d'un fichier changelog fiable;
OK... c'est à cause de ma super méthode que tu as pu découvrir mes
talents de rédacteur de changelogs... j'admets
* parce que tout projet sérieux étant amené à grossir peut faire
intervenir des programmeurs externes qui auront besoin de rapidement
comprendre les buts et particularités du programme.
C'est pour ça que j'ai bien précisé que ça peut être la bonne méthode
pour les projets perso/amateur, mais certainement pas pour les projets pro.
Faut pas trop m'en vouloir, je n'ai jamais réellement fait de projet en
groupe, en-dehors du travail et c'est récent.
* parce que cette phase de conception peut nous permettre de nous rendre
compte de certaines limites ou contraintes en terme de technologie, de
connaissances ou de matériel qu'il faudra résoudre avant de se lancer
proprement dit dans la phase de codage.
C'est juste. Mais il y a aussi beaucoup de choses dont on ne peut
vraiment se rendre compte qu'en ayant commencé à coder.
En tout cas c'est mon cas !
> Pour ceux qui sont rebutés par les méthodes de conceptualisation
classique, il y a le Xtrem programming qui préconise de se servir des
commentaires à l'intérieur du code comme sa véritable documentation.
Oui. OU même encore mieux que les commentaires, le code qui parle de
lui-même avec des noms de classes, de méthodes et de variables
suffisament explicites.
JE suis convaincu qu'on peut presque toujours se passer de commentaires
en nommant les choses de la bonne manière. Garder les commentaires
seulement pours expliquer les choses très spéciales / inhabituelles /
pas si évidentes que ça.
Principe que je n'applique évidemment pas... pas besoin de me le faire
remarquer, je le sais
Progliste :
Pour se d�sinscrire de la liste :
mailto:[email protected]?subject=unsubscribe
Pour voir les archives de la liste :
http://www.mail-archive.com/[email protected]/
Je vous rappelle que les pi�ces jointe sont activ�s leur taille est limit� � 2 MO
Pour acc�der aux fichiers de la liste
http://outils.archive-host.com/partage.php?id=2Qar9Hy6ftzr
Ou en utilisant la nouvelle page de partage :
http://outils-n.archive-host.com/partage-fm0m7b947vglikp9Efpso94gt
Pour y ajouter des fichiers demandez-moi le ou sur la liste ou en priv�, je
vous r�pondrez en priv�.
