IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Est-ce que la programmation en binôme convient à tous les développeurs ?


Sujet :

Débats sur le développement - Le Best Of

  1. #21
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    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

    Citation Envoyé par Nemek Voir le message
    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

  2. #22
    Membre expert
    Avatar de MarieKisSlaJoue
    Homme Profil pro
    Ingénieur Cloud
    Inscrit en
    mai 2012
    Messages
    1 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Roumanie

    Informations professionnelles :
    Activité : Ingénieur Cloud
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2012
    Messages : 1 142
    Points : 3 574
    Points
    3 574
    Billets dans le blog
    20
    Par défaut
    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
    Ce post à été écrit par un panda
    Apollo 11 - AGC revue de code
    -- qwerty keybord

  3. #23
    Inactif
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2013
    Messages : 374
    Points : 79
    Points
    79
    Par défaut
    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.
    nous devons inventer la langue de feu pour crâmer la langue de bois

  4. #24
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 912
    Points
    2 912
    Par défaut
    Citation Envoyé par dtrosset Voir le message
    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 ?

    Citation Envoyé par Nemek Voir le message
    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.

  5. #25
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    juin 2011
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : juin 2011
    Messages : 8
    Points : 8
    Points
    8
    Par défaut
    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.

  6. #26
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    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

  7. #27
    Membre du Club
    Homme Profil pro
    Développeur .NET
    Inscrit en
    mai 2014
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : mai 2014
    Messages : 50
    Points : 67
    Points
    67
    Par défaut
    Citation Envoyé par Saverok Voir le message
    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.
    Créateur de RL-Lab.com

  8. #28
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 912
    Points
    2 912
    Par défaut
    Citation Envoyé par PeterQTV Voir le message
    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.

  9. #29
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 197
    Points
    7 197
    Par défaut
    Citation Envoyé par PeterQTV Voir le message
    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 ;-)

    Citation Envoyé par PeterQTV Voir le message
    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.

    Citation Envoyé par PeterQTV Voir le message
    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

    Citation Envoyé par PeterQTV Voir le message
    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.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  10. #30
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 675
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 675
    Points : 30 964
    Points
    30 964
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  11. #31
    Membre du Club
    Homme Profil pro
    Développeur .NET
    Inscrit en
    mai 2014
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : mai 2014
    Messages : 50
    Points : 67
    Points
    67
    Par défaut
    Citation Envoyé par Nemek Voir le message
    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
    Créateur de RL-Lab.com

Discussions similaires

  1. Qu'est-ce que la programmation linéaire?
    Par Lucas Panny dans le forum Algorithmes et structures de données
    Réponses: 15
    Dernier message: 03/07/2009, 20h09
  2. Est ce que mon programme est juste ?
    Par autoin dans le forum C
    Réponses: 6
    Dernier message: 25/01/2008, 18h06
  3. Est-ce que OO +- = Programmation générique ?
    Par SlickRick dans le forum Langages de programmation
    Réponses: 2
    Dernier message: 17/11/2006, 22h26
  4. Qu'est-ce que la programmation managée?
    Par Pragmateek dans le forum C++
    Réponses: 3
    Dernier message: 27/03/2006, 16h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo