Affichage des résultats du sondage: Que pensez-vous de l'idée de faire des examens de son code par des collègues ?

Votants
28. Vous ne pouvez pas participer à ce sondage.
  • Bonne initiative, elle serait très utile en entreprise

    25 89,29%
  • Difficilement applicable, je ne saurais la recommander

    1 3,57%
  • Je ne peux pas me prononcer, il me manque des éléments pour le faire

    2 7,14%
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    3 124
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 3 124
    Points : 70 937
    Points
    70 937

    Par défaut Le contrôle de son code par un collègue permettrait d'en améliorer la qualité

    Le contrôle de son code par un collègue permettrait d'en améliorer la qualité
    et de respecter les délais de livraison d'un projet, d'après un consultant

    Jonathan Hassel, consultant technique, estime qu’implémenter une méthode de contrôle de qualité de son code par des collègues constitue un excellent moyen d’en améliorer la qualité tout en minimisant le temps passé à la recherche et la correction de bugs et de rester dans les délais impartis.

    Comment voit-il la chose ? Pour lui, un développeur pourrait s’associer à un collègue, et chacun d’entre eux scrutera le code de l’autre à la recherche de meilleures façon de faire, mais également pour éliminer les répétitions et des lignes de code superflues. Le développeur parcourt le code, explique sa logique, montre comment il a développé le concept sur lequel il a travaillé. Son confrère suggère où peuvent se trouver les erreurs, l’aide à résoudre quelques problèmes et, d’une façon plus générale, travaille à améliorer la qualité de son code.

    Hassel reconnait que si l’examen fait par les paires constitue un élément essentiel dans le monde scientifique mais également dans l’académie de publication, ce n’est que récemment qu’il a connu un certain essor dans le développement logiciel ; dans un monde où même de modestes applications peuvent avoir des milliers de lignes de code (avec des possibilités d’erreur qui vont crescendo), il va sans dire que l’enthousiasme n’est pas forcément au rendez-vous.

    Il estime que des examens par les pairs réussis sont des indicateurs significatifs de qualité. Il va même plus loin dans les éloges de cette méthode en avançant que, s’ils sont sollicités régulièrement, les contrôles de qualité par les pairs peuvent permettre d’économiser beaucoup de temps et d’argent. « Si les erreurs sont identifiées et corrigées avant qu’elles ne soient intégrées dans de nouvelles builds, il y aura moins de défauts et les projets seront livrés plus rapidement », estime-t-il. En guise d’illustration, il cite le livre CODE COMPLETE qui indique qu’après avoir instauré l’examen par les paires, « Aetna insurance Company a trouvé 82 pour cent des erreurs dans un programme en utilisant des inspections et a été en mesure de faire décroître ses ressources de développement de 20 pour cent ».

    Bien sûr une méthode ne saurait faire l’unanimité. Aussi il a cité les cinq plaintes qui reviennent le plus souvent sur ce type de procédé ainsi que les solutions pouvant les rendre caduc :

    • l’examen par les pairs est une perte de temps : malheureusement, certains des membres de votre équipe sont fatigués de la bureaucratie et vont d’abord repousser énergiquement ce procédé. Il y a de grandes chances que ce soient également les développeurs les plus faibles, ceux à qui les examens par les pairs profiteraient le plus. Pour lutter contre cela, Hassel recommande d’expliquer que beaucoup de paires d’yeux valent mieux qu'une, qu’en résultat vous obtiendrez une amélioration de la qualité du code permettra et de rappeler que les mesures de qualité sont importantes pour tout le monde en entreprise.

    • je ne gère pas bien la critique : intrinsèquement, l’examen par les pairs signifie une critique du code et certains développeurs auront certainement du mal à faire une critique du code sans que cela ne devienne personnel. Pour rendre ces sessions plus productives, envisager de commencer l’examen par les pairs plus tôt dans le processus afin que le code actuel ne soit pas le seul élément qui soit examiné pour permettre à vos équipes de développer un certain niveau de confort.

    • je ne suis pas assez bon pour faire un examen par les pairs avec une autre personne dans mon équipe : il est vrai que, tandis que l’examen par les pairs débute, certaines personnes n’y mettront pas vraiment du leur tandis que d’autres feront un excès de zèle. Ce déséquilibre pourrait même durer plus d’un an et apportera une facilitation des rapports de performance comme bonus. Le travail du manager qui identifie les meilleurs et les plus brillants en sera plus facile dans la mesure où il sera beaucoup plus aisé de repérer qui est capable d’apporter un plus à votre équipe et qui pourrait avoir besoin d'être réaffecté ou mis à la porte.

    • je n’ai pas de temps pour un examen par les pairs - nous avons un calendrier serré à respecter et nos délais ne nous donnent pas le temps de faire ce genre de revue systématique : une partie de votre culture doit vous souffler que des délais serrés ne sont pas une raison de ne pas procéder à des examens. Techniquement, il y aura toujours un examen – mais qui pourrait être effectué à un moment inopportun. Les meilleurs moments sont le plus tôt et le plus souvent possible, et en général, si les examens de code par les pairs sont effectués de cette façon, les projets sont souvent livrés plus tôt.

    • je ne sais pas avec qui m’associer : ceci est un type de problème que vos rapports directs devraient sans aucun doute résoudre, mais laisse la porte ouverte aux développeurs pour qu’ils puissent régler directement la question entre eux. En cas de doute, constituez des équipes de professionnels chevronnés et de débutants … pour des raisons évidentes.


    Hassel reconnaît que cette méthode prendra du temps mais souligne clairement que cela pourrait profiter à tous : « vos meilleurs développeurs vont apprécier le fait qu'un code de bonne qualité soit l’objectif de l’exercice. Vos développeurs juniors vont se parfaire et améliorer leurs compétences en regardant comment s’y prennent des développeurs plus expérimentés. Vous pourrez épargner du temps et de l’argent ».

    Source : CIO

    Et vous ?

    Partagez-vous son point de vue ? Pour quelles raisons ?

    Votre entreprise a-t-elle déjà adopté cette culture (de façon implicite ou explicite) ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 744
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 744
    Points : 5 441
    Points
    5 441

    Par défaut

    A vrai dire pour moi c'est le rôle du manager : gérer l'équipe, contrôler le travail accompli, vérifier la tenue des normes et pratiques mises en place. Et si un membre est faible on le fait travailler en binôme avec quelqu'un de plus doué.

    Évidemment ça ne fonctionnera avec un petit chef incapable de faire la différence entre "moi j'aurais fait comme ça" et "ceci est une mauvaise pratique reconnue".

  3. #3
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 840
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 840
    Points : 40 643
    Points
    40 643

    Par défaut

    Mouais, je vois pas ce qu'il y a de très nouveau là-dedans... le concept de code review existe depuis longtemps et est déjà appliqué dans beaucoup d'entreprises.

    L'utilité n'est plus à démontrer. Dans ma boite, on s'est mis depuis quelques mois à le faire de façon systématique, et il est rare qu'une code review ne permette pas de détecter quelques bugs ou améliorations possibles. Même quand ce n'est pas le relecteur qui voit le problème, le fait d'expliquer son code à un collègue permet souvent de détecter ses propres erreurs. Pour moi, l'impact positif sur la qualité du code ne fait aucun doute.

  4. #4
    Inactif

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 381
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 381
    Points : 0
    Points
    0
    Billets dans le blog
    8

    Par défaut

    malheureusement, certains des membres de votre équipe sont fatigués de la bureaucratie
    Oui, j'ai horreur de remplire/signer des papiers, surtout pour des conne****

    Cela dit, l'inspection du code par un compère, ne nécessite pas de paperasse, pas chez moi en tous cas . C'est en générale l'affaire de 15-30 minutes.

    L'avantage aussi, c'est que l'autre personne a une façon de penser différente, ce qui permet de tester le logiciel sous un autre angle, et de détecter de potentiel bug, auquel ont aurais pas pensé.

    Dans ma boite c'est même devenue un jeu, faire planter le logiciel/bout de code de l'autre. En utilisant des procédés parfois vicieux, (insertion de caractère bizarre dans un champ de texte...), depuis, nos logiciels n'ont jamais été aussi stable
    =>Comment jouer sur xbox one à moindre coût ?
    Achetez un notebook de 2010 à 50€ sur leboncoin, installez steam, connectez le pc à un écran, branchez une manette xbox au pc
    Enjoy

  5. #5
    Membre régulier
    Homme Profil pro
    Consultant ERP
    Inscrit en
    juillet 2011
    Messages
    29
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Industrie

    Informations forums :
    Inscription : juillet 2011
    Messages : 29
    Points : 111
    Points
    111

    Par défaut

    Je pense que c'est une pratique qui vient naturellement avec la pratique, ça fait partie du métier de se remettre en question, on est tellement la tête dans le guidon qu'on perd en objectivité et on passe à côté de choses importantes, c'est là que le coup d'oeil extérieur intervient pour faire avancer une situation. Par contre, si on est tout seul ou si on a un manager qui brille par son incompétence et/ou sa connerie, c'est pas gagné...

  6. #6
    Membre éprouvé
    Avatar de fenkys
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    361
    Détails du profil
    Informations personnelles :
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 361
    Points : 1 003
    Points
    1 003

    Par défaut

    Je ne crois pas qu'il parle ici du code review tel qu'on le pratique généralement, mais d'un échange de bons procédés entre deux développeurs : je relis ton code, tu relis le mien. C'est souvent fait de façon informelle et non systématique. Il préconise juste de le systématiser.

    C'est une opération gagnant/gagnant, non seulement pour le rédacteur du programme que pour le relecteur qui pourrait aussi apprendre quelque chose de nouveau.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 759
    Points : 20 082
    Points
    20 082

    Par défaut

    Citation Envoyé par sazearte Voir le message
    (.../...)Dans ma boite c'est même devenue un jeu, faire planter le logiciel/bout de code de l'autre. En utilisant des procédés parfois vicieux, (insertion de caractère bizarre dans un champ de texte...), depuis, nos logiciels n'ont jamais été aussi stable
    100% d'accord avec toi. Sauf que je n'ai jamais eu l'autorisation de le faire(à une exception près, un peu particulière, l'architecte qui vérifie tout systématiquement). Pourtant, je suis sur que c'est aussi un moyen de faire passer de bonnes pratiques, en plus de la chasse aux bugs. Et aussi de diffuser la connaissance(technique ou fonctionnelle) à travers l'équipe. Celui qui lit sera bien mieux à même de reprendre le code plus tard - ça lui sera familier.

    Mais bon, le chef qui hurle en permanence "tu est en retard sur tes objectifs" n'aide pas - alors même que je sais très bien depuis plus d'un mois que je vais les louper et ne pas avoir de prime(forcément, j'ai chiffré pour 30 composants en ayant les specs pour 12... Et les cas les plus difficiles arrivaient à partir de numéro 15). Le truc, c'est que mon collègue(qui trouve que je me "complique la vie pour rien" quand je fais des fonctions - voire, Dieu nous préserve, des classes - pour encapsuler le code) n'ose pas rentrer dans mon code quand je suis absent et que ça plante. Et ça, à mon avis, ça coute beaucoup plus cher qu'une putain de revue de code par semaine.
    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.

  8. #8
    Membre habitué
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2012
    Messages
    87
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juin 2012
    Messages : 87
    Points : 179
    Points
    179

    Par défaut

    Cette pratique, pour l'avoir expérimenté est nettement profitable à la qualité et stabilité d'une application.

    Après comme dit plus haut reste encore à convaincre ses supérieurs,collègues et autres guignols du bénéfice de la chose.

    Je me suis retrouvé dans un service info où nous étions deux développeurs qui s'entendaient pas trop mal.
    J'ai soumis l'idée au DSI qui ma copieusement envoyer paître en me soutenant que si je ne savais pas faire mon travail correctement j'avais rien à faire ici.
    J'ai donc soumis l'idée au 2eme développeur qui ma copieusement envoyer paître en me soutenant que si je me pensais meilleur que lui je n'avais qu'à faire son boulot à sa place.

    Devant tant de bon sens et d'ouverture d'esprit je les ai copieusement envoyé paître également.
    Un seul des 3 s'est vu infligé une sanction...

    Je dois probablement manquer de diplomatie...
    Les questions ne sont pas obligées d'avoir du sens. Mais les réponses, si.
    Terry Pratchett (Procrastination)

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

    Informations forums :
    Inscription : janvier 2011
    Messages : 676
    Points : 2 397
    Points
    2 397

    Par défaut

    Citation Envoyé par DonQuiche Voir le message
    A vrai dire pour moi c'est le rôle du manager : gérer l'équipe, contrôler le travail accompli, vérifier la tenue des normes et pratiques mises en place. Et si un membre est faible on le fait travailler en binôme avec quelqu'un de plus doué.

    Évidemment ça ne fonctionnera avec un petit chef incapable de faire la différence entre "moi j'aurais fait comme ça" et "ceci est une mauvaise pratique reconnue".
    Je ne suis pas sûr que ça soit vraiment l'esprit du peer review. On ne cherche pas un système arborescent où la raison du plus haut placé l'emporte mais un graphe complet où chaque individu peut être force de proposition envers tous les autres et où la connaissance circule dans toutes les directions.

    Maintenant, si le manager est bon techniquement, code régulièrement, qu'il se met en mode "simple collègue un peu plus expérimenté" lors de la code review et qu'il accepte que son propre code soit revu de la même manière, pourquoi pas.

    Quand à savoir si "le contrôle de son code par un collègue permettrait d'en améliorer la qualité", ça me paraît presque une lapalissade.

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

    Informations forums :
    Inscription : janvier 2011
    Messages : 676
    Points : 2 397
    Points
    2 397

    Par défaut

    Citation Envoyé par MvK0610 Voir le message
    J'ai donc soumis l'idée au 2eme développeur qui ma copieusement envoyer paître en me soutenant que si je me pensais meilleur que lui je n'avais qu'à faire son boulot à sa place.
    Réponse à chaque fois que le mec te demande de l'aide par la suite : "je ne suis pas meilleur que toi"

  11. #11
    Membre habitué
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2012
    Messages
    87
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juin 2012
    Messages : 87
    Points : 179
    Points
    179

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    Réponse à chaque fois que le mec te demande de l'aide par la suite : "je ne suis pas meilleur que toi"
    Encore faut-il que la fille, en l'occurence et je n'ai rien contre, en question ait assez de recul et de jugeote pour demander de l'aide avant de foncer dans le mur avec la vélocité d'un angry bird sous amphet.

    Ce qui n'était malheureusement pas le cas à l'époque et je ne suis fort heureusement plus là-bas pour le constater à l'heure actuelle
    Les questions ne sont pas obligées d'avoir du sens. Mais les réponses, si.
    Terry Pratchett (Procrastination)

  12. #12
    En attente de confirmation mail

    Profil pro
    Inscrit en
    septembre 2013
    Messages
    642
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 642
    Points : 2 277
    Points
    2 277

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    (...) On ne cherche pas un système arborescent où la raison du plus haut placé l'emporte mais un graphe complet où chaque individu peut être force de proposition envers tous les autres et où la connaissance circule dans toutes les directions.(...)
    Ca c'est la théorie, et c'est peut-être le discours qu'on t'a vendu ou que tu vends toi-même...

    Mais la réalité c'est que, comme dans n'importe quelle équipe de plus d'une personne, les plus grandes gueules imposent leurs points de vue aux autres.

    Une des raisons pour lesquelles je ne travaille que seul ; et pour lesquelles celui qui prétendra m'apprendre à coder prendra directement ma main dans la figure.

  13. #13
    Inactif

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 381
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 381
    Points : 0
    Points
    0
    Billets dans le blog
    8

    Par défaut

    Je me suis retrouvé dans un service info où nous étions deux développeurs qui s'entendaient pas trop mal.
    J'ai soumis l'idée au DSI qui ma copieusement envoyer paître en me soutenant que si je ne savais pas faire mon travail correctement j'avais rien à faire ici.
    J'ai donc soumis l'idée au 2eme développeur qui ma copieusement envoyer paître en me soutenant que si je me pensais meilleur que lui je n'avais qu'à faire son boulot à sa place.
    Dans ma boite actuel, c'est tout l'inverse !

    On est 4 ingénieurs dans l'équipe ou je travail, y'a pas vraiment de chef, tant qu'on fournie du code stable et performant, on a limite carte blanche sur nos méthodes de travail, la DSI nous laisse tranquille.

    Pour le dev on utilise la méthode Scrum, ou chaque matin, on se prend 1H max, pour discuter d’éventuel problème rencontrer, et pour tester nos sprint de la vielle.

    Comme le client c'est la boite ou je travail, on est directement en contacte avec le client. On a presque crée une communauté avec les salariés, chaque jour, on publie une build "instable" de notre logiciel, a disposition de tous les salariés de la boite, qui peuvent la tester et nous remonter les bugs, et proposé des améliorations/nouvelle fonctionnalité. Gra ce a une mini application que j'ai créé et intégrer au logiciel, qui permet de nous envoyer des messages avec des pièces jointe en plus.
    =>Comment jouer sur xbox one à moindre coût ?
    Achetez un notebook de 2010 à 50€ sur leboncoin, installez steam, connectez le pc à un écran, branchez une manette xbox au pc
    Enjoy

  14. #14
    Membre averti Avatar de a028762
    Homme Profil pro
    Retraité
    Inscrit en
    décembre 2003
    Messages
    392
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : décembre 2003
    Messages : 392
    Points : 439
    Points
    439

    Par défaut

    Eh bien, ce n'est pas gagné !
    Ce n'est pas un élément des méthodes agiles ? Le code review ... ou c'est encore plus invasif, un jour sur deux, tu codes devant moi , le lendemain c'est l'inverse
    Ol

  15. #15
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 128
    Points
    2 128

    Par défaut

    Citation Envoyé par a028762 Voir le message
    Eh bien, ce n'est pas gagné !
    Ce n'est pas un élément des méthodes agiles ? Le code review ... ou c'est encore plus invasif, un jour sur deux, tu codes devant moi , le lendemain c'est l'inverse
    Ol
    Tu confonds avec le Pair Programming où en effet, tu développes à 2 (un au clavier, l'autre en relecture).
    C'est 2 techniques différentes mais qui vont dans le même sens: avoir du code "juste" écris au plus tôt.

  16. #16
    Inactif

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 381
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 381
    Points : 0
    Points
    0
    Billets dans le blog
    8

    Par défaut

    Tu confonds avec le Pair Programming où en effet, tu développes à 2 (un au clavier, l'autre en relecture).
    Qui utilise cette méthode ?

    Pour ma part j'ai jamais pu l'utiliser concrètement, j'avais essayer une fois, mais n'aime pas trop, car soit l'un code et l'autre glande, soit l'un code et l'autre critique chacune de tes lignes.

    C'est très difficile a mettre en place je trouve.
    =>Comment jouer sur xbox one à moindre coût ?
    Achetez un notebook de 2010 à 50€ sur leboncoin, installez steam, connectez le pc à un écran, branchez une manette xbox au pc
    Enjoy

  17. #17
    Membre confirmé
    Homme Profil pro
    Inscrit en
    octobre 2010
    Messages
    74
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : octobre 2010
    Messages : 74
    Points : 459
    Points
    459

    Par défaut

    Citation Envoyé par sazearte Voir le message
    soit l'un code et l'autre critique chacune de tes lignes.
    C'est le but, sinon ça sert à rien.
    les algorithmes qui oublient leur histoire sont condamnés à la répéter

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

    Informations forums :
    Inscription : janvier 2011
    Messages : 676
    Points : 2 397
    Points
    2 397

    Par défaut

    Citation Envoyé par CodeurPlusPlus Voir le message
    Ca c'est la théorie, et c'est peut-être le discours qu'on t'a vendu ou que tu vends toi-même...
    On l'a mis en pratique dans mon équipe actuelle et dans la précédente et ça marche pas trop mal : moins de bugs, connaissance plus complète de la base de code par chacun, meilleure implication et satisfaction des membres de l'équipe.

    Citation Envoyé par CodeurPlusPlus Voir le message
    Une des raisons pour lesquelles je ne travaille que seul ; et pour lesquelles celui qui prétendra m'apprendre à coder prendra directement ma main dans la figure.
    Il ne s'agit pas d'apprendre à quelqu'un à coder mais de mettre une deuxième paire d'yeux sur le coup pour détecter les fautes d'étourderie qui arrivent à tout le monde, et apporter des idées de meilleur design. Si grande gueule et désaccord il y a, d'autres membres de l'équipe sont consultés. On a toujours trouvé un terrain d'entente, et si ce n'était pas le cas, je pense que le problème nous exploserait à la face d'une manière ou d'une autre, code review ou non. Ne serait-ce que quand on essaierait d'intégrer ensemble le code de deux personnes ayant des visions opposées.

    Attention, je ne parle pas de code review par écrit a posteriori (qui peut effectivement être génératrice de malentendus et non-dits) mais en conversation directe avec la personne.

  19. #19
    Nouveau membre du Club
    Homme Profil pro
    Ingénieur en Informatique
    Inscrit en
    octobre 2010
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur en Informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : octobre 2010
    Messages : 3
    Points : 25
    Points
    25

    Par défaut

    Contrôler le code par des collègues ? Ca s'appelle le code review. Avec UpSource etc... Je le pratique. Le code devient nettement plus propre, le programme plus stable, et partage de connaissances etc...

    Que du positif à mon avis, le petit bémol c'est que certaine fois ça peut retarder les mises en production. Mais c'est rare, et moi ça m'est jamais arrivé.

  20. #20
    Expert éminent
    Avatar de cchatelain
    Homme Profil pro
    Analyste décisionnel marketing
    Inscrit en
    janvier 2003
    Messages
    4 135
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Analyste décisionnel marketing
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2003
    Messages : 4 135
    Points : 7 334
    Points
    7 334

    Par défaut

    Citation Envoyé par DonQuiche Voir le message
    Évidemment ça ne fonctionnera avec un petit chef incapable de faire la différence entre "moi j'aurais fait comme ça" et "ceci est une mauvaise pratique reconnue".
    Tu as juste décrit mon chef...

    Sinon, je pense que c'est évident : une autre personne détectera plus facilement des erreurs que le codeur lui-même.
    Grave urgent : Vous êtes nouveau sur développez.com ? Bienvenue à vous. Mes meilleurs conseils sont ceux-ci :
    1 : lisez bien ceci http://club.developpez.com/aidenouveaux/
    2 : lisez aussi ceci http://general.developpez.com/cours/


    Mes News

Discussions similaires

  1. Réponses: 18
    Dernier message: 10/02/2012, 02h21
  2. Insérer caractère par son code ASCII
    Par Ange44 dans le forum Mise en forme
    Réponses: 2
    Dernier message: 10/04/2007, 13h04
  3. indentifacation d'un client par son numero et son code
    Par abdou karim diagne dans le forum C
    Réponses: 3
    Dernier message: 19/03/2007, 10h20
  4. Réponses: 2
    Dernier message: 15/09/2006, 13h07
  5. [XSLT ]remplacement d un caractere par son code
    Par luta dans le forum XSL/XSLT/XPATH
    Réponses: 3
    Dernier message: 02/09/2005, 17h26

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