Appropriation collective du code

**toto828** · 10/01/2009, 14h11

J'étais en train de me documenter sur l'Extreme Programming et je suis tombé sur cette pratique :

Appropriation collective du code

L'équipe est collectivement responsable de l'application. Chaque développeur peut faire des modifications dans toutes les portions du code, même celles qu'il n'a pas écrites. Les tests diront si quelque chose ne fonctionne plus.

ça me fait byzare de me dire que n'importe qui peut modifier mon code et inversement que je puisse modifier le code de tout le monde. peut on vraiment connaitre les tenants et aboutissants d'un code écrit par un autre?
ça me choque un peu, je suis plus partisan d'une appropriation du code et quand on pense pouvoir améliorer quelque chose se mettre en relation avec le propriétaire du code pour exposer son idée.

Que pensez vous de cela? avez vous déjà appliqué de telles pratiques?

**souviron34** · 10/01/2009, 15h16

Envoyé par asellerin

J'étais en train de me documenter sur l'Extreme Programming et je suis tombé sur cette pratique :

ça me fait byzare de me dire que n'importe qui peut modifier mon code et inversement que je puisse modifier le code de tout le monde. peut on vraiment connaitre les tenants et aboutissants d'un code écrit par un autre?
ça me choque un peu, je suis plus partisan d'une appropriation du code et quand on pense pouvoir améliorer quelque chose se mettre en relation avec le propriétaire du code pour exposer son idée.

Que pensez vous de cela? avez vous déjà appliqué de telles pratiques?

ça ça n'est pas lié du tout à Xtreme Programming, mais à Open Source, plutôt...

En tous cas, pour ce qui est de l'appropriation, oui, cela peut faire partie de la démarche. Par contre, pour la modification, là c'est un peu n'importe quoi.

Je ne sais pas où tu as trouvé ça, mais Extreme Programming ne veut pas dire ça. C'est plutôt par rapport au cycle de vie du logiciel que par rapport à la manière de gérer l'écriture... Et surtout avoir comme ligne-guide ce que tu cites est une aberration...

**toto828** · 10/01/2009, 21h00

j'ai trouvé ça sur le site :

http://www.extremeprogramming.org/rules/collective.html

merci quand même

**yann2** · 12/01/2009, 03h59

Bonjour

Bah ! Si ! Ce que tu dis s'applique à l'extrême programming.
En gros ça veut dire que n'importe quelle personne de l'équipe peut toucher n'importe quel bout de code de l'application.

ça me fait byzare de me dire que n'importe qui peut modifier mon code et inversement que je puisse modifier le code de tout le monde. peut on vraiment connaitre les tenants et aboutissants d'un code écrit par un autre?

Dans l'idéal : oui

ça me choque un peu, je suis plus partisan d'une appropriation du code et quand on pense pouvoir améliorer quelque chose se mettre en relation avec le propriétaire du code pour exposer son idée.

Là je crois que c'est clairement répondu par :

Appropriation collective du code

Mais bon, en réalité, je trouve également qu'il est difficile (ou cavalier ?) de modifier du code sans en parler avec l'auteur original

Peut être parce que le monde idéal où on a ça :

Now you can rely on the test suite to watch dog your entire code repository. Before any code is released it must pass the entire test suite at 100%.

n'est pas toujours la réalité

(en fait, nous, on fait des débats collectifs sur : besoins -> solution -> conception -> implémentation. Donc l'équipe sait ce qu'il se passe).

Avantage :
* Toute l'équipe a une vue d'ensemble de l'applications
* Sans cette appropriation collective : Si Jean Baptiste Dupond (qui s'occupe du module de facturation via l'API XFACTUREv3.4 qui n'est connue que de lui) se casse chez le concurrent pour gagner plus de sous, l'équipe l'a dans le <beep>

Yann

**pseudocode** · 12/01/2009, 11h17

L'appropriation collective du code cela ne veut pas dire que tout le monde modifie n'importe quoi, n'importe quand, n'importe comment.

Cela permet d'avoir une meilleure réactivité et une meilleur homogénéité du code:

- En cas de correction/refactor, tout le monde participe et pas seulement l'auteur originel du fichier. Cela évite de devoir attendre le retour de vacances de machin pour faire le refactor du fichier truc.

- Si au cours du codage d'un module A, il y a besoin de modifier une signature/structure de donnée d'un module B, alors le développeur du module A peut aller directement modifier le module B. Et cela sans devoir passer par une demande et un accord d'un autre dev.

Le développement en XP est un développement en équipe. Il n'y a pas de chasse gardée sur certaines parties du code.

**Patriarch24** · 12/01/2009, 11h37

Le développement en XP est un développement en équipe. Il n'y a pas de chasse gardée sur certaines parties du code.

D'autant que le développement se fait en binôme, et qu'on change de binôme fréquemment. On touche ainsi à tout le code, qui est simple, et qui suit les conventions de codage préétablies donc compréhensible par tous, d'où la notion d'appropriation collective. Une modification de code peut intervenir dans le cadre de refactoring : normalement, tout le monde dans l'équipe peut modifier tout (du moins une grande partie) le code car il le connaît déjà.
Je ne vois pas en quoi c'est aberrant !

**nanomag** · 15/02/2009, 00h03

Effectivement, comme le dit patriache, l'essentiel est que au fur et à mesure de l'avancement du projet, chaque développeur connaisse un minimum chacune des classes, des fonctionnalités, etc. du projet.

Si les équipes sont changeantes, tournantes, les collègues qui ont fait la 1ère livraison ne sont pas forcement disponibles.
De plus, la norme de codage respectée, les éventuels commentaires, et surtout les précédentes user stories qui doivent correspondre au code qui a été implémenté, sont normalement largement suffisante pour comprendre de quoi il retourne.

S'il 'agit de refactoring, il peut y avoir 2 raisons
- ajouter une nouvelle fonction dans une fonctionnalité ou module (peut importe le nom) déjà existante
- une optimisation : gain en terme de temps, de mémoire utilisée, de compréhension du code, regroupement de fonctions similaires...

Dans tous les cas, les tests unitaires permettront de vérifier que la fonctionnalité implémentée en 1er fonctionne toujours.

Ensuite, 2 des 4 valeurs XP sont la communication et le courage, la modification du code d'autrui demande du courage et de la confiance en soi.
Le "filet de sécurité" étant les Tests (indispensables) et la communication intensive ! avec les autres membres de l'équipe.

**jogrey** · 26/02/2009, 13h05

La aussi je suis convaincu des bénéfices d'XP à la qualité de réalisation d'un projet info. mais :

Auriez-vous des études sérieuses sur les coûts de correction d'un bug dans une phase lointaine, ou tout autre document qui vous aurez permis de vendre une double charge a votre hiérarchie/client ?

Vous n'avez j'espère pas appliqué le ratio on est 2 sur la tâche on va donc 2 fois plus vite ?

En gros, comment l'avez-vous vendu votre XP

**souviron34** · 26/02/2009, 13h15

Envoyé par jogrey

En gros, comment l'avez-vous vendu votre XP

ça marche alors qu'avec les autres méthodes ça marche pas

**pseudocode** · 26/02/2009, 15h06

Envoyé par jogrey

En gros, comment l'avez-vous vendu votre XP

Comment vendre XP:

- Vous n'avez pas de zone d'ombre dans votre cahier des charges ?
- Vous n'allez pas modifier le cahier des charges pendant le développement ?
- Vous n'avez pas besoin d'avoir des "beta" fonctionnelles ?

Vous avez répondu "non" a toutes les questions : bravo, on va pouvoir appliquer le modèle waterfall et faire la gestion du projet avec MS-Project.

Vous avez répondu "heu... si !" à l'une des questions : pas de chance, le modèle waterfall ne s'applique pas. Vous avez besoin de xxxxxx [inserer ici un avantage de XP] => utilisez XP.

**jogrey** · 26/02/2009, 15h25

Je m'excuse, je voulais écrire, "le développement en binômes d'XP".

**David Gimelle** · 02/03/2009, 11h21

Envoyé par asellerin

J'étais en train de me documenter sur l'Extreme Programming et je suis tombé sur cette pratique :

ça me fait byzare de me dire que n'importe qui peut modifier mon code et inversement que je puisse modifier le code de tout le monde. peut on vraiment connaitre les tenants et aboutissants d'un code écrit par un autre?
ça me choque un peu, je suis plus partisan d'une appropriation du code et quand on pense pouvoir améliorer quelque chose se mettre en relation avec le propriétaire du code pour exposer son idée.

Que pensez vous de cela? avez vous déjà appliqué de telles pratiques?

Bonjour Ascellerin,

L appropriation collective du code fait bien partie des Pratiques XP.
Ca signifie que tous les membres de l equipe peut modifier m importe quelle partie du code de l application.

Les avantages de cette pratique :
- Le depart d un membre de l equipe (Demission, Vacances, Maladie) ne pose plus de probleme car n importe qu elle autre membre de l equipe peut s occuper de le remplacer.
- Quand on ecrit un code qui sera relu par d autre, on ecrit svt un code meilleurs et plus lisible donc plus fiable et plus maintenable.
- Ca evite d avoir la situation de Pierre qui fait rien pendant 2 jours alors que Jacques est deborder depuis 3 jours sur des bugs sur ca partie!
-Ca permet une meilleurs communications, car les developpeurs qui font la couche acces aux donnes font aussi de la couche GUI et donc comprennent mieux les besoins des 2 couches.
-Ca ouvre la voie au refactoring et a un code toujours meilleurs

C est different du pair programming qui est de programmer a 2 sur un meme poste de travail. On peut faire l appropriation collective de code sans faire de pair programming. L inverse n est pas vraie.

Les conditions pour mettre en place cette pratique
- Avoir une equipe de 8 developpeurs maximum
- Avoir un serveur de version type CVS, SVN etc
- Utiliser des test automatiser Junit etc ...
- Avoir une liste des taches a faire (Backlog, Jira, Tableau de post it avec Colonnes : Afaire, En cours, Fait)

Mon experience perso avec l appropriation collective du code
Actuellement, je travaille dans une equipe de 4 developpeurs, nous avons toujours en cours un nouveau projet en developpement + la maintenance d une dizaine d applications. Nous ne faisons quasiment pas de pair programming.

Avant de mettre en place l appropriation collective du code, quand arrivaient 5 bug d un coup sur une meme application. On disait c est l application de Paul, et il faisait des heures sup pendant que nous on partait a 4h de l apres midi. Tous seul il mettait 3 jours a tous faire, donc 5 bug qui arrivaient le mercredi etaient corrigés et en prod le mardi matin.

Avec l appropriation collective on est bien plus reactif, on s y met a 4 en une journee c est fait et le vendredi matin les bugs sont corrigés et en prod.

Voila pourquoi notre chef de projet est pour l appropriation collective du code!

PS: Le 30 Mars c est le XP Day de Geneve http://xpday.agile-swiss.org/

Appropriation collective du code

Méthodes Agiles

Discussions similaires

Partager

Partager