PHWinfo - Afficher un message - Petit Guide à l'usage du développeur agile

17/08/2007, 11h15

On 14 août, 08:56, Laurent Pointal <laurent.poin...@limsi.fr> wrote:
> Méta-MCI (MVP) a écrit :
>
> > Bonjour !
>
> >> "bonnes pratiques" ?
>
> > J'avoue que je me hérisse un peu, dès qu'on veut me dire combien de
> > glaçons je dois mettre dans mon pastis, de quelle façon il faut
> > développer, ce que je (ne) dois (pas) manger, comment discuter avec les
> > utilisateurs, etc.
>
> Mais toi tu as de l'expérience... combien de temps ça a pris ?
> J'ai eu des cours de sur ce genre de chose intéressant certaines fois,
> lourd d'autres fois (les comptages de lignes de codes... le COCOMO &
> co). Avec certaines techniques adaptées à certains cas (les grosses
> usines à gaz par exemple), d'autres pas.
> Le tout c'est de réussir à trier ce qui est utile/pratique et qui peut
> faire gagner du temps de ce qui est superflu/lourd/dépassé et qui en
> fera finalement perdre. Et d'avoir les outils ad-hoc (dans certains cas
> le coût des outils est très prohibitif).
>
> De ce que j'ai pu voir du sommaire du livre de Tarek, ça ne m'a pas trop
> choqué. Ca peut bien servie à un étudiant ou à un amateur qui veut se
> mettre à Python et qui devrais y trouver un raccourci vers les façonsde
> faires considérées généralement comme meilleurs.
>

Bonjour,

Merci pour la réponse Laurent, c'est exactement l'optique du livre.
Ce n'est pas un guide qui tente d'imposer telle ou telle méthodologie
de programmation ou d'analyse.
Mais simplement une synthèse, une introspection de mon expérience, mon
vécu dans la programmation de
petites et de grosses applications (zope, cps par exemple). Tout ce
que je me suis pris dans "les dents" en quelques sorte,
pendant 10 ans: pourquoi les tests unitaires servent vraiment,
pourquoi un outil comme subversion
est incontournable, des principes de base pour la conception (sans
prôner telle ou telle méthode),
les techniques Python qui marchent, comment écrire de la documentation
efficace sans
se noyer dedans, etc.

Je n'ai pas la prétention de dire que mon expérience est meilleure que
d'autres mais elle offre un
bon apercu de ce que peut vivre un développeur Python, et de ce qu'il
retient, comme le dit Laurent,
de toutes les techniques de programmation et d'analyse, pour son
travail de tous les jours.
A mon sens le développeur qui arrive à appliquer 100% de merise ou
d'UML sur un projet est un psychopathe

Puisqu'en général, un diagramme de classe couvre la plupart des
besoins de compréhension de l'archi.

Pour les "vieux de la vieille", et s'ils ne la pratique pas déjà
la partie la plus intéressante du livre est sans doute le Document
Driven Developement, qui présente
une approche originale de développement utilisée par exemple dans Zope
3.

Cdl

++

Tarek

> > Mais, je sais que la plupart des petits djeuns, frais moulus des écoles,
> > sont friands de ce genre de chose. Je crois que ça les rassure.
>
> Ouaips, même que certains ne veulent plus que faire de l'analyse,
> surtout pas mettre les mains dans le camboui des lignes de code...
>
> J'ai eu un collègue fou de la documentation et des notations UML & Co,
> qui là où j'aurais fait une petite doc synthétique, éventuellement avec
> un diagramme de classes pour expliquer un peu, pondait des pages et des
> pages de trucs verbeux qui n'apportaient AMA pas grand chose (par
> contre, il mettait les mains dans le camboui pour que le code
> correspondant tourne).
>
> A+
>
> Laurent.

17/08/2007, 11h15	#30
Tarek Messages: n/a Hébergeur:	Re: Petit Guide à l'usage du développeur agile On 14 août, 08:56, Laurent Pointal <laurent.poin...@limsi.fr> wrote: > Méta-MCI (MVP) a écrit : > > > Bonjour ! > > >> "bonnes pratiques" ? > > > J'avoue que je me hérisse un peu, dès qu'on veut me dire combien de > > glaçons je dois mettre dans mon pastis, de quelle façon il faut > > développer, ce que je (ne) dois (pas) manger, comment discuter avec les > > utilisateurs, etc. > > Mais toi tu as de l'expérience... combien de temps ça a pris ? > J'ai eu des cours de sur ce genre de chose intéressant certaines fois, > lourd d'autres fois (les comptages de lignes de codes... le COCOMO & > co). Avec certaines techniques adaptées à certains cas (les grosses > usines à gaz par exemple), d'autres pas. > Le tout c'est de réussir à trier ce qui est utile/pratique et qui peut > faire gagner du temps de ce qui est superflu/lourd/dépassé et qui en > fera finalement perdre. Et d'avoir les outils ad-hoc (dans certains cas > le coût des outils est très prohibitif). > > De ce que j'ai pu voir du sommaire du livre de Tarek, ça ne m'a pas trop > choqué. Ca peut bien servie à un étudiant ou à un amateur qui veut se > mettre à Python et qui devrais y trouver un raccourci vers les façonsde > faires considérées généralement comme meilleurs. > Bonjour, Merci pour la réponse Laurent, c'est exactement l'optique du livre. Ce n'est pas un guide qui tente d'imposer telle ou telle méthodologie de programmation ou d'analyse. Mais simplement une synthèse, une introspection de mon expérience, mon vécu dans la programmation de petites et de grosses applications (zope, cps par exemple). Tout ce que je me suis pris dans "les dents" en quelques sorte, pendant 10 ans: pourquoi les tests unitaires servent vraiment, pourquoi un outil comme subversion est incontournable, des principes de base pour la conception (sans prôner telle ou telle méthode), les techniques Python qui marchent, comment écrire de la documentation efficace sans se noyer dedans, etc. Je n'ai pas la prétention de dire que mon expérience est meilleure que d'autres mais elle offre un bon apercu de ce que peut vivre un développeur Python, et de ce qu'il retient, comme le dit Laurent, de toutes les techniques de programmation et d'analyse, pour son travail de tous les jours. A mon sens le développeur qui arrive à appliquer 100% de merise ou d'UML sur un projet est un psychopathe Puisqu'en général, un diagramme de classe couvre la plupart des besoins de compréhension de l'archi. Pour les "vieux de la vieille", et s'ils ne la pratique pas déjà la partie la plus intéressante du livre est sans doute le Document Driven Developement, qui présente une approche originale de développement utilisée par exemple dans Zope 3. Cdl ++ Tarek > > Mais, je sais que la plupart des petits djeuns, frais moulus des écoles, > > sont friands de ce genre de chose. Je crois que ça les rassure. > > Ouaips, même que certains ne veulent plus que faire de l'analyse, > surtout pas mettre les mains dans le camboui des lignes de code... > > J'ai eu un collègue fou de la documentation et des notations UML & Co, > qui là où j'aurais fait une petite doc synthétique, éventuellement avec > un diagramme de classes pour expliquer un peu, pondait des pages et des > pages de trucs verbeux qui n'apportaient AMA pas grand chose (par > contre, il mettait les mains dans le camboui pour que le code > correspondant tourne). > > A+ > > Laurent.