Pour changer, voici un topic dédié aux process de développement utilisés dans les projets en entreprise qui marchent ou pas.  
Vous pratiquez la programmation par paires, le développement de tests avant le code ? Venez partager votre expérience, c'est ici que ça se passe.
 
Au cours des nombreuses missions que j'ai faites chez divers clients, il y en a un chez qui le process de développement de produit m'a paru particulièrement rigoureux. Cette rigueur était rendue obligatoire étant donné que les produits, des systèmes médicaux, étaient soumis aux exigences très précises de la Food & Drugs Administration américaine, en particulier pour ce qui concerne la documentation (systématiquement lue et signée par plusieurs personnes, dont au moins une extérieure à l'équipe) de toutes les étapes du développement et de l'évolution du produit.
 
Pour les développeurs, les documents maîtres étaient une spécification détaillée constamment remise à jour, et une description des tests la plus exacte possible et en phase avec la spec détaillée, sur laquelle se basait la campagne de test système qui précédait toute nouvelle version du produit.
 
Parmis les process utilisés, il y avait le build quotidien (nocturne, sans être toutefois de l'intégration continue), le test systématique par une équipe dédiée, et la remise à jour de la doc systématique.
 
Et surtout, le code d'un développeur était systématiquement relu et approuvé par le chef de projet technique  avant intégration dans la branche de développement principale.
Le résultat est que le produit était le plus abouti que j'ai vu chez un client, à la fois en terme de robustesse que de performances. Et le seul dans lequel je n'ai pas vu de code ahurissant.
 
En effet, le développeur, qui sait que son code va être relu, prend soin de le commenter, et évite de coder "à l'arrache". Il bénéficie en outre des commentaires de gens plus expérimentés et son style s'améliore avec le temps, ce qui est particulièrement bénéfique pour des débutants.(Attention à l'écueil numéro 1: en aucun cas une revue de code doit être une évaluation du développeur. Les commentaires désagreables sont le plus sûr moyen de mener a l'échec du processus, stressant inutilement les développeurs dont le code est relu. Ca doit être une pratique comprise et voulue par les développeurs et pas simplement imposée par le chef.)
 
A l'issue de cette expérience, l'inspection du code me paraît être une pratique tout aussi indispensable que le test.  
C'est ce que dit aussi Steve Mc Donnell dans "Code complete". Des études montrent que statistiquement l'inspection systématique et formelle du design et du code détecte 70-85% des défauts, soit plus que toutes les autres méthodes de détection, test système compris, et ce, avec un coût supplémentaire de 10-15% (qui est largement amorti par le fait qu'il y a moins de corrections tardives).  
Ces études ont été abondamment confirmées par de nombreuses organisations dans lesquelles elle est pratiquée. La Nasa indique que la relecture permet de détecter 3,3 défauts/heure, le test seulement 1,8/heure.
 
Malgré cela, je suis étonné de voir à quel point la revue de code/design est peu pratiquée. Ca me rappelle le temps où les entreprises ne prévoyaient pas de budget pour le test de leurs produits (considérant que cette activité fait partie du dev) avant qu'elles finissent par comprendre après pertes et fracas que c'est une étape indispensable du cycle de développement. Quelle est votre avis ?
 
http://www.possibility.com/epowiki [...] odeReviews

L'été dernier j'ai travaillé dans une boite qui est le leader dans son domaine. On developpait une webapp Java d'une taille assez monstreuse (ils en étaient ~a 3milions de lignes de code).
Le problème était que le test/debug n'était pas réellement pris en compte .. C'était plutot du style "hé, mec, y a un bug dans la page XY , tu veux pas aller voir ou ça plante?", du coups je te racconte pas le retour de flammes des clients.
J'en ai parlé un peu avec le chef du dev et le bigboss , et les 2 m'ont répondu qu'effectivement c'était un gros problème, mais que vu qu'ils avaient du retard sur la feuille de route,ils pouvaient pas se permettre de faire autrement.
Et bien ... voila ... Je pense que c'est très souvent comme ça ... Mais je suis pas sur que pondre un code crade et devoir le debugger 6mois apres alors qu'on sait plus comment ça marche (parceque bien entendu aucune doc/commentaire n'était présente), soit beaucoup plus rapide que de faire les choses proprement avec qqn qui relit et teste derrière...

Tout pareil que esox_ch, mais avec du code C.
 
Pas de relecture du code. Je m'estime pas trop mauvais (peut-être à tort) mais, malgré tout, je sais que quoiqu'il arrive je fais des erreurs.
 
Et quand je relis parfois le code de certains de mes collègues... /o\

Alors qu'avec une relecture de code systématique, non seulement le produit serait plus robuste, mais les collègues en question seraient obligés de progresser, d'où une qualité générale en augmentation.
Au bout d'un moment, les revues sont plus rapides à mettre en oeuvre, quand  la qualité est relevée.

Même si ce n'est pas vriament de la prog, au niveau HTML et CSS ya une énorme importance, et quand le code n'a pas été relu c'est hyper chiant.
Exemple simple, j'ai passer 2 semaines à réparer les merdes de la boite en régie.
 
Et en JS c'est pas mieux. Moi qui ai l'habitude de faire des fonctions génériques qui marchent toutes seules quand tu fais appels à elles dans la page, derrière je fais des contrôles sur les objets et on me dit que mon code est longs
Là je soulève un autre point, avoir un code qui va faire 3 ou 4 lignes de plus mais avoir des points de control : if (monobj) alors fait ça sur cet objet
Ca evite de se prendre des erreurs dans la gueule.
Mais dans cette boite ils s'en branlent un peu eperdument /o\

Ma boîte pratique le développement en binôme... sauf que j'attends toujours d'avoir un binôme.

Jamais.  
 
J'avais la demande il y a quelques temps (relecture aléatoire par un tiers), mais refusée par la direction, alors qu'on a une équipe de chiens fous

En fait, je crois qu'il y a une constante dans le dev : si une appli est grosse, alors c'est qu'elle est mal foutue.
 
l'appli sur laquelle je suis arrivé en  décembre fait 200 000 lignes de code, quand elle sera reprise en main, je pense qu'elle en fera moins de 100 000.
 

bucheron et hache !

(piqué sur http://implosions.net/blogue/?p=23 )
 
 
 
l'un des problèmes de la relecture tient à la mobilité de l'application. Un dev prend un bout de code et le modifie, il tente de l'améliorer, mais ne peut pas rendre nickelle l'appli en une demi-journée, et la définition de "nickel" est variable. le relecteur devra donc comprendre dans quel axe de refactorisation voulait bosser le dev et quelle distance il voulait parcourir sur cet axe pour apprécier le code.
 
 
 
 
nous on tente l'XP, donc pas de relecture systématique, par contre on matte de temps en temps les commits des autres pour se tenir au courant. Pas de documents de conception et pas de javadoc inutiles.
 
slash33 > les binômes doivent changer très souvent pour l'homogénéité de l'appli et de l'équipe, ce qui implique et sous-tend la propriété collective du code.

merde, comment on starise un topic déjà ?

http://forum.hardware.fr/user/addf [...] subcat=388

Excellente la fable des bucherons !

J'aime aussi.

Et combien vaut la constante à laquelle se raporte "grosse" ?
 

 
En lisant la suite, je ne comprends pas
 

On m'a dit que la définition de "nickel" était le fruit d'un processus social. Je ne suis pas sur de savoir ce que c'est exactement, mais j'y crois.
 

On s'approche de l'évaluation non ?
 

Agreed

ouais, là ça va, mais nous le boss nous l'a sortie en meeting scrum et je peux te dire que le repas (on le fait juste avant de bouffer) a été silencieux ...

la constante c'est très exactement le service rendu au client / nombre de lignes de code.
 
en général, y'a un heuristique : si quelqu'un se vante du nombre de lignes de code, c'est qu'il y en a trop
 
 
prenez l'esprit de pico container en exemple : ils se vantent de ne faire que 100ko de jar, toutes les fonctions de jacky ont été sorties en un autre projet (nanocontainer), dans un des anti-patterns montrés, la solution consiste à virer le produit de la boucle (plus exactement, le pb est la présence de leur produit dans la boucle). c'est un bon esprit à mon sens.

allez, on relance de 3ct :  
qui fait un scrum metting (réunion quotidienne de moins de 10 min) ?
 
- comment vous contrôllez sa longueur ?
- que dites-vous là-dedans ?

Nous on en a eu 3-4 en 3 mois. Les 3 big-boss, la comptable et le chef du dev parlent dans les 2-5 min chaqu'un. Apres on peut poser les questions mais en general personne en pose

oui, c'est pas de ça dont je parle, ça doit êtr eun meeting technique de l'équipe de dev.

Moi, à peu près tous les quarts d'heure, le café à la main.
 
Sinon, non, pas vraiment.

 
Chez nous, ce sont les traditionnels "points d'avancement", en gros ça dure quelques minutes, entre MOE et souvent avec la MOA aussi, et soit on fixe des priorités entre plein de taches, soit on en profite pour prendre du recul sur un boulot en particulier pour mieux apprécier où on en est, et pour mettre à plat ce qu'il reste à faire.
Pas de rond de jambe, aucun formalisme, rien de novateur non plus ; par contre c'est efficace voire essentiel, sinon ce serait vite le bordel.

vous avez conbien de styles de tests chez vous ? nous on est en pleine mutation, on doit en être à notre 6 ème style de tests (en éliminant certains autre quand des nouveaux arrivent) : les tests sur des modèles des clients (intégration lourde on va dire, ils ont été éliminés), des tests de non-régression (par rapport aux bug rapportés, éliminés aussi), des test d'intégration (ils se font lentement éliminer), des tests unitaires (qui se font lifter pour devenir plus unitaires pour tourner plus vite et diminuer la maintenance), des tests de validation (dont je péfère ne pas parler, je vais ménerver, ils viennent d'être créé), et des tests d'acceptation qui servent juste à savoir si une fonctionalité a été développée (ils sont en fitnesse)
 
Bref, ça tatonne.

Chez nous, on n'a théoriquement pas le droit à l'erreur. Les impacts sont importants.
 
Donc les tests, pour un projet "normal" (donc on exclut les petites mises à jour comme les modifications majeures, l'une comme l'autre particulières, et on exclut les trucs à l'arrache), on fait : tests unitaire, côté MOE, pour valider que ça plante pas. Tests de non-régression (notre gros problème en ce moment se situe au niveau des performances ), MOE/MOA. Puis validation fonctionnelle, côté MOA/utilisateurs.
 
Tout par mail pour conserver des traces écrites (on m'a des fois demandé des comptes sur des machins passés en production trois ou quatre mois avant, au détour d'un effet de bord vicieux par exemple ).
 
edit : on va appliquer aussi une phase de "qualification", en gros une prod bis sur un serveur à part, et on y mettra nos modifs à tourner quelques jours avant de poser ça en production pour de vrai.

ces tests sont automatisés ?

Pas tous. Les tests unitaires et fonctionnels ne sont évidemment pas automatisables.
Les tests de non-régression sont lancés manuellement, mais l'enchaînement des processus est automatique (on fonctionne par chaînes de traitements en fait)
Et la qualification n'a évidemment rien de manuel.

y'a rien d'évident dans ce que tu dis.
pourquoi vos tests U ne sont pas automatisables ?
tu est dans quel secteur ?

Finances. Et ce n'est pas automatisable dans la mesure où il s'agit le plus souvent de tester l'aspect fonctionnel. Le côté technique n'a que trop peu d'importance. Pour te donner une idée, on essaie de mettre en place un gestionnaire de sources, là.  
 
Le point bloquant : essayer de convaincre les chefs que c'est utile, et donc qu'on doit ouvrir une ligne budgétaire.
 
Difficulté supplémentaire : les chefs jouent avec leurs blackberry durant les réunions sur le sujet.

Nous on essaye d'utiliser cppunit pour automatiser ces tests unitaires, mais on a pas ce temps quand on est chez le client (mon équipe le déplore, bien entendu), et on a toujours du mal à justifier autant de temps passer à tester (c'est vraiment dingue). On fait de la revue de code quasi systématique, un peu de pair programming quand le besoin s'en fait sentir, et pas mal de tests fonctionnels.
 
Edit: et on s'arrange pour qu'au final, le produit soit nickel. On a eu qu'un gros bug vicieux il y a quelques mois. Donc au final ça marche plutôt pas mal, mais ca pourrait être bien mieux, en terme de confort.

ouais, je comprends vos pbs.
 
C'est vrai que je les ai résolu en changeant de boite. Et encore, ma boite actuelle ne s'est ressaisie que parce que les clients ont fait des menaces. Le PDG est pour XP, il a participé à XP game (avec le boss des commerciaux), il a bien compris nos besoins, il nous soutient. Mais on a encore un boss qui promet n'importe quoi aux client et qui balourde encore des stagiaires sur des projets qu'il juge improtants.
 
 
 
l'argument pour l'automatisation des tests, c'est qu'on passe moins de temps en debug, mais pas la peine de mentir, ça prend au moins un an de passer de rien à des bénéfices (le temps de former le personnel, d'introduire les points de test dans l'application etc.).
 
Elmo > on me conseille de te conseiller d'aller poser ton CV sur monster.fr

Enfin écrire les tests tu veux dire, parce que les tests une fois écrits tu les lances à la demande de manière automatisée.

Signale-leur que c'était la même chose chez crosoft quand ils se sont lancés dans le marché des serveurs, et qu'à cause de ça ils ont perdu au moins 3-4 ans.
 
Et même l'aspect fonctionnel est automatisable, du moins sur NT/XP, avec des produits adhoc comme Rational Robot (un peu merdique et sans doute cher). Ca prend bcp de temps au départ, c'est clair. Par la suite, on y gagne. Sous unix, c'est plus compliqué, il faut quasiment développer son outil de test d'interface et c'est pas gagné. Mais on peut secouer la bête toute la nuit avec le test du "clic aléatoire" et trouver des bugs qu'on n'aurait pas pu trouver autrement.

  Vous faites partie des projets relativement bien gérés du coté de la qualité du produit, on dirait.

 
On a des gens à temps complet pour ça (2 quoi), on devrait être ISO je sais pas quoi dans les mois qui suivent... Donc des choses se mettent en place, côté décideurs et développeurs en même temps, je pense pas que j'aie à me plaindre, j'ai connu bien bien pire
 
En même temps, certains client demandent des certifications particulières, ce qui n'est pas étranger à la situation. Encore une fois, je vais pas m'en plaindre.

il faut bien compprendre que certaines choses sont incompatibles, par exemple CMMI n'est pas compatible avec XP, pour cause de documents.  
 
quand on change le processus toutes les semaines pour faire des essais ou des améliorations, on peut pas s'amuser avec des flux de documents et de réunions barbantes.

bon, je relance d'un centime.
 
quelques points de Lam's sur XP (qui est à la fois expérimenté et multiculturel).
http://forum.hardware.fr/forum2.ph [...] 0#t1417048
 
Lam's > je réitère ma question de MP :
 
Comment as-tu forgé ton avis sur les différentes critiques d'XP ? Quel est l'évènement qui t'a fait tirer le bilan en te disant "en fait ce truc c'est pas top" ? Tu as testé les différents trucs sur combien de temps ?
 
 
Sinon, j'ai pris des photos de notre bureau, je les poste dès que possible.

Topic of the year \o/
 
Je suis un peu admiratif de voir tout ce beau monde s'être converti de gré ou de force à l'XP.
 
P'tite question : en j.h (puisqu'il faut bien une échelle), quels sont la taille des projets en XP que vous réalisez (mini-maxi-moyenne) ?

nous on développe un produit, donc ça compte pas.

par contre, le projet sera petit quand j'aurai fini de le passer au mixer

Ma question était de savoir si l'XP sur des gros projets chez vous ça marchait bien, moyen, ou bien mais en faisant quelques adaptations...

ben le premier projet de Ken Beck était énorme autant que je sache, mais c'est difficile de faire du changement sur une grosse équipe à moins d'avoir un charisme de dingue.