Discussion :

[Saverok]

Je partage ton avis sur la relecture du code systématique
Je n'effectue cela que lorsque je dois former un débutant et quand un nouveau membre arrive dans l'équipe pour évaluer son niveau
Cependant, arriver à un moment, il faut que le travail avance et on doit se faire confiance dans une équipe

Peut-être la solution serait de travailler sur deux postes, un même sujet mais côté-à-côté (voir coude-à-coude). La discussion se fait d'abord sur l'approche du problème et ensuite sur les quelques détails de l'implémentation qui permettent de partager la façon de concevoir un algorithme et la connaissance de la base de code existante. Par exemple, utiliser telle classe utilitaire déjà mise au point pour réaliser telle ou telle tâche. Et faire ensuite le pissage de code chacun de son côté ; quitte à jeter un petit coup d’œil au travail du voisin.
Et enfin faire des "points de synchro" régulièrement (à la fin de chaque méthode ?, toutes les xx minutes, etc.) afin de faire une petite relecture de code, réorienter le travail, etc.
Est-ce une bonne idée d'après vous ?

Les risques de collusion sont très (trop ?) important
A chaque synchro, les merges sur les mêmes fonctions et classes peuvent devenir imbuvables même s'ils sont fait fréquemment

Je pense qu'il est bon également de responsabiliser les gens et qu'on ne peut pas être toujours derrière eux.
La confiance est un élément indispensable à l'esprit d'équipe.

Ce que je pratique dans mon équipe c'est le correctif croisé
C'est à dire que lors de la recette (bien évidemment, les développeurs ne testent pas leur dev mais celui d'un autre s'il n'y a pas d'équipes dédiée à la recette), les retours (ajustements ou bugs) ne sont pas réalisées par le développeur qui a effectué le dev initial.
C'est un peu une façon de faire de la relecture mais de manière active (et non passive à juste lire et analyser)

Le principe des réunions de conception est super
Mais comme toujours, pour des raisons de temps, elles ne peuvent être systématiques
Elles sont réalisées uniquement à la demande du développeur et/ou lorsque la fonctionnalité est jugée complexe et/ou critique.

Note :
Les outils d'analyse de code repèrent énormément de chose comme le respect des normes, la duplication de code, l'instanciation des variables, etc.
Même si un robot ne remplacera jamais la relecture par un développeur, ça permet d'éviter pas mal de problème

[MarieKisSlaJoue]

Quelqu'un as-t-il déjà essayer de travailler avec un IDE en ligne collaboratif ? Je me demande bien ce que ça peux donner en pair programming justement. de pouvoir travailler sur le même code en live sans passer par des push et pull

[jean_kevin_musclor]

Ca fonctionne très bien par skype aussi.

C'est vraiment une méthode de travail efficace quand on cherche à produire du code de qualité, ça dynamise l'équipe, ça t'oblige à faire du code lisible, propre, à ne pas taper n'importe quoi à l'arrache.

Le problème c'est que, comme le dit l'article, il y'a beaucoup d'asociaux dans l'informatique, ça n'est pas qu'ils soient incapables de bosser en équipe, c'est qu'ils n'aiment pas ça, ça les embête de devoir écouter, discuter, ils sont plus à l'aise en mode pisse-code-illisible hyper concentré sur son truc qui ne voit pas l'intérêt d'informer son équipe de ce qu'il est en train de faire et de perdre du temps à écrire des commentaires, car souvent ils ne connaissent aucune autre manière de travailler et n'ont pas envie d'en connaître d'autre.

Et le problème devient contre-productif quand on travaille avec le genre d'anti-sociaux qui piquent une crise d'hystérie à chaque fois qu'on les contredit car ils sont incapables de voir les rapports humains autrement que sous l'angle du rapport de domination primaire, ils obtiennent naturellement l'autorité sur le groupe par la peur, ça donne des équipes où plus personne ne communique afin d'éviter la baston, chacun fait un bout dans son coin sans concertation et le programme est un foutoir incohérent pourri de bugs.

Bref, le teamwork c'est bien à condition de bosser avec des gens civilisés.

[Luckyluke34]

J'instaurerais les revues de code obligatoires ailleurs si je devais bouger, sans aucune hésitation.

Instaurer... Obligatoire... Figer dans le marbre une pratique de manière arbitraire ne risque-t-il pas de frustrer les devs et d'être mal adapté ? Est-ce qu'une réflexion sur les buts à atteindre et une décision collégiale sur la mise en oeuvre concrète ne serait pas plus appropriée ?

Puisqu'on évoque le côté sociologique (voir sociopathique ), j'ai tendance à remarquer que des remarques à chaud sont souvent mieux prises que la même remarque à froid. Parce qu'on a changé de sujet et que cela suffit à nous contrarier.
Ensuite, la relecture de code n'invite pas à la discussion je trouve. On fait quelques échanges superficielles sur le fond et la forme. Et la méthode de travail, l'approche du problème, etc. ne sont pas discutés. On discute que du résultat pas de la démarche, ce qui est un point crucial du pair programming.

+1, c'est aussi ce que j'ai constaté.

Dans un ancien job, on a évolué vers des code review "en live" avec la personne et ça passait beaucoup mieux que des relectures asynchrones.

[Morphéo33]

Je suis d’accord avec toi, j'ai essayé l'autre jour la programmation en binôme dans mon nouveau poste et j'ai trouvé que c'était globalement une perte de temps.

Tu perds du temps en proposant une ligne de code et en la dictant par exemple avec toutes les incompréhensions qui en découlent.
Tu as une idée assez précise en tête mais tu te retiens de l'exprimer car tu l'as déjà fait pour les 3 fonctionnalités précédentes et tu ne veux pas "bouffer" le binôme.
C'est plus difficile de réfléchir à un algorithme à haute voix ou avec le binôme qui s'exprime en même temps.
C'est plus difficile de factoriser une portion de code à deux (pas forcément la même logique).

Voilà quelques exemples en vrac. Je suis d’accord avec un message plus haut qui dit qu'il vaux mieux un développeur par fonctionnalités connexes.

Après, je trouve ça bien quand il y a un grand écart de niveau du style sortie d'école / développeur sénior, et encore ne pas faire ça systématiquement mais seulement pour des portions "compliquées" par mesure de formation.

[Saverok]

Quand il m'arrive de manager une équipe, mon plus grand défi est d'impliquer les développeurs
Je trouve que la programmation en binôme déresponsabilise les gens et du coup, ils se sentent moins impliquer dans le projet

Même si les succès et les échecs d'un projet son toujours collectif, je trouve très valorisant de se dire qu'on a développé telle fonctionnalité et qu'elle a du succès / est appréciée par les utilisateurs
Le pair programming enlève de cela et je trouve ça dommage

Note :
Ensuite, il ne faut surtout pas tomber dans le sectarisme avec des domaines réservés
Un sens de la mesure reste bien évidement nécessaire et indispensable

[zsalloum]

Quand il m'arrive de manager une équipe, mon plus grand défi est d'impliquer les développeurs
Je trouve que la programmation en binôme déresponsabilise les gens et du coup, ils se sentent moins impliquer dans le projet

Même si les succès et les échecs d'un projet son toujours collectif, je trouve très valorisant de se dire qu'on a développé telle fonctionnalité et qu'elle a du succès / est appréciée par les utilisateurs
Le pair programming enlève de cela et je trouve ça dommage

Note :
Ensuite, il ne faut surtout pas tomber dans le sectarisme avec des domaines réservés
Un sens de la mesure reste bien évidement nécessaire et indispensable

Bien que je ne l'ai pas vraiment pratiqué, mais je ne vois pas bcq d'utilité !
La théorie dit que le dév le moins experimenté prendra le clavier et plus expérimenté l'assiste!
En soit c'est frustrant pour un expert de s'assoir à côté et donner de consignes, c'est très démotivant.
Et si l'inverse est appliqué, le dev junior sera rapidement déconnecter.

A mon avis le mieux est que le senior explique la tâche au junior, avec les bonnes pratiques et les potentiels pitfalls puis lui laisser le temps pour travailler, tout en restant disponible pour répondre aux questions. A la fin (une, deux heures ou bien une matinée), les deux feront un code review.
Je pense que cela est plus productif pour les deux.

[Luckyluke34]

A mon avis le mieux est que le senior explique la tâche au junior, avec les bonnes pratiques et les potentiels pitfalls puis lui laisser le temps pour travailler, tout en restant disponible pour répondre aux questions. A la fin (une, deux heures ou bien une matinée), les deux feront un code review.
Je pense que cela est plus productif pour les deux.

Pour avoir pratiqué les deux, je trouve au contraire que le pair programming est plus productif.

Avec une code review a posteriori, soit on a tendance à beaucoup moins retoucher ce code déjà existant, soit au contraire on "refait le match" ce qui est une perte de temps par rapport à un mode où les 2 développeurs auraient avancé ensemble en temps réel. On est obligé d'appliquer plus de techniques de refactoring puisque le code pondu entretemps par le junior est quelque part du code legacy, et ça prend du temps. D'un autre côté si le senior se rend vraiment "disponible pour répondre aux questions", ça revient un peu à du pair programming sauf que le senior est interrompu fréquemment, et on sait ce que vaut le task switching en termes de productivité...

Toujours par rapport à mon expérience, plus la différence de niveau entre les deux devs est faible, moins la code review finale va être bien acceptée. Avec le pair programming, on fait tourner souvent le clavier et on discute au fil de l'eau, ce qui donne en général une solution plus collégiale et validée par les 2.

[Logan Mauzaize]

Bien que je ne l'ai pas vraiment pratiqué, mais je ne vois pas bcq d'utilité !

Relis ce qui a été dit précédemment ;-)

La théorie dit que le dév le moins experimenté prendra le clavier et plus expérimenté l'assiste![...]
Et si l'inverse est appliqué, le dev junior sera rapidement déconnecter.

Non, la théorie dit qu'il faut permuter régulièrement. Ca évite justement la déconnexion.
Il ne faut pas oublier qu'on a tous à apprendre des autres. Un projet c'est énormément de choses : le dev dans éventuellement plusieurs langages et paradigmes, le tooling (ex: IDE), les tests, la traçabilité, build, déploiement, etc.

En soit c'est frustrant pour un expert de s'assoir à côté et donner de consignes, c'est très démotivant.

Personnellement, je le vois pas du tout comme ça. Je trouve ça très gratifiant de partager son savoir et d'inculquer les bonnes pratiques. Ou alors je n'accepterai pas que le plus expérimenté vienne ensuite râlé sur les mauvaises pratiques de ces collègues.
Ceci dit je suis très pédant

A mon avis le mieux est que le senior explique la tâche au junior, avec les bonnes pratiques et les potentiels pitfalls puis lui laisser le temps pour travailler, tout en restant disponible pour répondre aux questions. A la fin (une, deux heures ou bien une matinée), les deux feront un code review.
Je pense que cela est plus productif pour les deux.

Le soucis c'est qu'on ne pense pas à tout. Et des fois c'est dans les petits détails qu'on a beaucoup à apprendre. Ensuite on peut également rectifier la méthode de travail, la façon de refactorer, utiliser les outils. Tout ce qui se perd avec le côté "à froid" de la revue de code, cette dernière ne s'intéresse qu'au résultat et non pas à tout ce qui y a conduit.

Voir mes remarques précédentes sur le côté "à froid" de la revue de code.

[el_slapper]

les "je crois, je pense, mon experience dit que, j'ai probablement raison", c'est bien gentil, mais une vraie étude solide, c'est quand même plus fiable.

Ca tombe bien, Alistair Cockburn en avait fait une il y a quelques années.

Conclusions :
(1)Là ou un type seul consomme 1000 heures, un binôme va consommer 1150 heures(soit 575 heures pour chaque membre du binôme) - en réalisation seule.
(2)Le binôme fait en moyenne 15% moins de bugs. La correction de bugs et leur impact support coutant plus cher que la réalisation initiale, ce simple fait suffit à rendre le pair programming rentable.
(3)Il y a tout plein de qualités additionnelles plus subjectives : satisfaction, qualité de l'architecture, revue continue, transfert de connaissance induit.
(4)J'aimerais bien avoir l'occasion d'essayer.

[zsalloum]

Relis ce qui a été dit précédemment ;-)


Non, la théorie dit qu'il faut permuter régulièrement. Ca évite justement la déconnexion.
Il ne faut pas oublier qu'on a tous à apprendre des autres. Un projet c'est énormément de choses : le dev dans éventuellement plusieurs langages et paradigmes, le tooling (ex: IDE), les tests, la traçabilité, build, déploiement, etc.


Personnellement, je le vois pas du tout comme ça. Je trouve ça très gratifiant de partager son savoir et d'inculquer les bonnes pratiques. Ou alors je n'accepterai pas que le plus expérimenté vienne ensuite râlé sur les mauvaises pratiques de ces collègues.
Ceci dit je suis très pédant


Le soucis c'est qu'on ne pense pas à tout. Et des fois c'est dans les petits détails qu'on a beaucoup à apprendre. Ensuite on peut également rectifier la méthode de travail, la façon de refactorer, utiliser les outils. Tout ce qui se perd avec le côté "à froid" de la revue de code, cette dernière ne s'intéresse qu'au résultat et non pas à tout ce qui y a conduit.

Voir mes remarques précédentes sur le côté "à froid" de la revue de code.

Comme j'ai bien mentionné que je ne l'ai pas vraiment pratiqué, et donc j'ai un certain préjugé !
du coup je vous crois sur parole et je vous donne un +1