Petit Guide à l'usage du développeur agile

Le Mon, 13 Aug 2007 18:12:30 +0200, 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, 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.

"J'en ai une grosse comme ça, pas besoin de savoir ce que font les autres".

On 14 août, 08:56, Laurent Pointal <laurent.poin...@limsi.fr> wrote:

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 l es
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 veu t se
mettre à Python et qui devrais y trouver un raccourci vers les façons de
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 écol es,
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, éventuellemen t 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.

"vieux de la vieille"

'ttention, hein !
C'est pas parce qu'on est vendredi qu'il faut insulter :
- moi ;
- ma femme.

Nous avons su rester jeune d'esprit (surtout moi). Et, ça, c'est ma méthode secrète pour bien (hum
?) programmer.

Non mais...



@+

Michel Claveau

"vieux de la vieille"

'ttention, hein !
C'est pas parce qu'on est vendredi qu'il faut insulter :
- moi ;

Madame s'en charge ?

- ma femme.

Là, c'est vous qui vous en occupez ?

Nous avons su rester jeune d'esprit

Vous parlez de vous à la manière de Louis XIV ?

(surtout moi).

Aie ! l'erreur est donc avérée...

--
Pierre Maurette

Moi, je vous le dis : " y'en a qui doivent faire de l'assembleur en cachette, pour avoir l'esprit
aussi tordu".

Moi, je vous le dis : " y'en a qui doivent faire de l'assembleur en cachette,
pour avoir l'esprit aussi tordu".

Mes inutiles remarques se voulaient légères, amusées. Un vendredi...

Ceci dit il y a effectivement un rapport indirect avec l'assembleur.
J'ai effectivement publié, et écrire n'était pas mon métier. J'ai été
pris de terreur, le mot est à peine exagéré, à l'idée d'être lu, ce qui
est effectivement un comble, et jugé.
J'ai eu la coquetterie de vouloir rédiger. Je juge d'ailleurs le
résultat un peu verbeux, mais peu importe. Immédiatement s'est posée la
question du temps et de la personne. Pour le temps, dans un ouvrage
technique, le présent s'impose. Pour la personne, c'est un peu plus
ouvert. J'élimine le "tu", bien entendu. Restent le "on", le "je" et le
"vous". J'ai choisi le "vous". Là se pose la question de l'accord. J'ai
décidé - et il me semble que c'est la règle - que ce "vous" s'accordait
au singulier. Comme le "Nous" royal.

J'imagine que Tarek s'est plus ou moins posé les mêmes questions...

--
Pierre Maurette

Oulà !

J'utilisais simplement le passage de paramètres par position :

"vieux de la vieille" (moi, ma femme)
vieux = "moi"
vieille = "ma femme"

Bon faudra attendre Python-3000, pour mettre une étoile, ce qui obligera à utiliser des paramètres
nommés.

Sur ce, je retourne à l'apéro...


Santé à tous !