Dois-je dire à quelqu'un que son engagement a provoqué une régression?
Lorsque vous recherchez et corrigez une régression, c'est-à-dire. un bogue qui empêchait le code de fonctionner auparavant - le contrôle de version permet de rechercher qui a commis la modification qui l'a interrompu.
Est-ce que ça vaut le coup? Est-il constructif de le signaler à la personne qui a commis l'engagement? La nature de l'erreur (à l'échelle de la simple inattention à l'incompréhension fondamentale du code qu'ils ont changé) change-t-elle si c'est une bonne idée?
Si c'est une bonne idée de leur dire, quelles sont les bonnes façons de le faire sans provoquer d'offense ou les amener à se mettre sur la défensive?
Supposons, pour les besoins de l'argument, que le bogue est suffisamment subtil pour que les tests automatisés du serveur CI ne puissent pas le détecter.
Si vous les approchez simplement pour leur parler d'une erreur qu'ils ont commise, à moins que vous ne soyez le meilleur diplomate au monde, il sera difficile pour lui de ne pas simplement sonner "Ha! - regardez cette erreur que vous avez faite!". Nous sommes tous humains et la critique est difficile à prendre.
D'un autre côté, sauf si le changement est complètement insignifiant et évidemment mauvais, je trouve normalement bénéfique de parler à la personne qui a commis le changement d'origine dans le cadre de mon enquête juste pour m'assurer que je comprends parfaitement ce qui se passe. , par conséquent, la façon dont je finis habituellement par gérer cette situation est d'aller vers cette personne et d'avoir une conversation qui ressemble un peu à ceci:
Moi: Je travaille sur ce bug où ... résumé du bug ... et je pense que j'ai suivi le problème jusqu'à une modification que vous avez apportée. Vous rappelez-vous à quoi servait ce changement?/avez-vous le temps d'expliquer ce changement?
Alors soit:
Eux: Bien sûr, c'est à gérer ... situation dont je n'étais pas au courant ...
Ou quelque chose comme:
Eux: Non désolé, je ne me souviens pas, ça me semble mal.
En explorant ensemble le changement/bug, le committer d'origine apprend de ses erreurs sans se sentir critiqué *, et il y a aussi de fortes chances que vous appreniez aussi quelque chose.
Si le committer d'origine n'est pas là ou est occupé, vous pouvez toujours vous frayer un chemin et comprendre tout cela par vous-même, je trouve normalement que parler à la personne qui a initialement effectué le changement est plus rapide.
* Bien sûr, cela ne fonctionnera que si vous êtes vraiment intéressé par l'aide des autres personnes. Si vous utilisez simplement cela comme une méthode à peine déguisée pour raconter à quelqu'un une erreur qu'ils ont commise, c'est probablement pire que d'être simplement ouvert à ce sujet.
Soyez assuré et non agressif. Toujours privilégier le fait de dire quelque chose de semblable à "ce morceau de code ne fonctionne pas" que "votre code ne fonctionne pas". Critiquez le code, pas la personne qui a écrit le code.
Mieux encore, si vous pouvez penser à une solution, fixez-la et envoyez-leur - en supposant que vous avez un système de contrôle de version distribué. Demandez-leur ensuite si votre correction est valide pour le bogue qu'ils corrigeaient. Dans l'ensemble, essayez d'augmenter vos connaissances et leurs connaissances en programmation. Mais faites-le sans que votre ego ne vous gêne.
Bien sûr, vous devriez être prêt à écouter les autres développeurs vous rencontrer avec le même problème et à agir comme vous l'auriez souhaité.
Oui, toujours. En tant que programmeur, c'est votre travail d'apprendre des erreurs.
Leur faire savoir les erreurs qu'ils font les aidera à devenir un meilleur codeur et réduira leurs chances de faire des erreurs à l'avenir. MAIS soyez poli et n'en faites pas grand cas, nous créons tous des bugs de temps en temps. Je trouve qu'un e-mail poli est un moyen très non conflictuel de faire savoir aux gens.
La manière constructive est de trouver le bogue, de le corriger et de prendre des mesures pour éviter que des bogues similaires ne surviennent à l'avenir.
Si cela implique d'expliquer aux gens comment ne pas introduire de bugs, allez-y.
Une fois, j'ai travaillé dans une équipe où le chef de projet n'a jamais dit à un développeur particulier qu'il avait fait une erreur: il a organisé une réunion avec toute l'équipe où il a expliqué qu'une erreur avait été commise et qu'un nouveau processus avait été défini afin de supprimer ce genre d'erreurs. De cette façon, personne n'a été stigmatisé.
En général, oui.
Personne ne devrait se mettre sur la défensive si vous en faites preuve de tact. Un moyen simple de le gérer consiste à leur demander de revérifier votre modification avant de la valider dans le coffre (ou tout ce qui est pertinent pour votre système de contrôle de version). Les gens l'apprécieront si vous les enregistrez quelques minutes en corrigeant des erreurs évidentes, mais ils ne l'apprécieront pas si vous corrigez quelque chose qui n'a pas été cassé et finissez par casser leur code. En leur donnant la possibilité d'examiner votre changement, vous leur dites que vous ne voulez pas marcher sur leurs pieds et leur donne la possibilité de s'opposer à vos changements.
Si c'est un grand changement plutôt qu'une simple faute de frappe, c'est une bonne idée de donner à l'auteur un avertissement avant de creuser pour essayer de le réparer. "Joe, je fusionnais mes propres trucs hier et j'ai trouvé quelque chose que je ne suis pas sûr de comprendre. Cela ressemble à un bogue, mais je voulais l'exécuter par vous avant d'aller jouer avec votre code. moi?"
Votre relation avec l'auteur est un facteur important. Si cela ne vous dérange pas que l'auteur répare votre code sans vous le dire, et si vous êtes presque sûr que le sentiment est réciproque, cela ne vaut peut-être pas la peine d'être mentionné. Si c'est quelqu'un avec plus d'expérience/d'ancienneté/de statut, vous voudrez lui faire savoir que vous allez changer son code. Si c'est quelqu'un avec moins, alors demandez-vous si c'est le genre de chose qu'il faut entendre pour éviter de répéter l'erreur ou cela pourrait les embarrasser inutilement.
Rappelez-vous toujours que si vous pouvez découvrir qui a vérifié le "bug", ils peuvent aussi facilement découvrir qui a "corrigé" leur code. Si vous pensez qu'ils seraient contrariés/ennuyés/embarrassés de découvrir votre changement après coup, dites-le-leur à l'avance.
De plus, la correction du bogue n'est pas votre seule option. Vous pouvez toujours simplement signaler le bogue dans votre outil de suivi des problèmes. Tact est à nouveau requis ici - signaler le bogue le rend plus visible pour toute l'équipe, mais cela donne également à l'auteur une chance de corriger sa propre erreur. Le signalement est la meilleure option si vous n'êtes pas certain de la meilleure façon de résoudre le problème ou si vous n'avez tout simplement pas le temps de le résoudre.
Si je fais un commit qui inclut un bug, vous feriez mieux de me le dire. Si je trouve un commit de votre part qui inclut un bug, je vous le dirai sûrement.
Nous ne nous améliorons que lorsque nous comprenons nos erreurs. C'est ainsi que nous produirons un meilleur code à l'avenir.
Vous obtenez d'excellentes réponses ici.
Je ne pouvais ajouter qu'une technique que j'avais apprise d'un manager une fois quand je faisais une erreur.
J'étais consultant d'âge moyen avec le doctorat. et elle était la jeune manager sans, donc il aurait pu y avoir un gradient de prestige perçu. Quoi qu'il en soit, elle avait clairement l'expérience de cette situation et savait comment y faire face.
Elle m'a mentionné d'un ton presque apologétique qu'il semblait y avoir un problème, et aurais-je le temps de l'examiner?
Souvent, l'erreur était la mienne et elle le savait. C'est ça l'habileté.
Je pense qu'il y a un problème plus profond sous-jacent à cette question. Oui, le demandeur doit certainement être mis au courant des conséquences de son changement, afin qu'il puisse comprendre ce qui s'est passé et ne pas refaire la même chose. Cependant, le contexte de votre question indique que vous avez préparé et soumis un correctif à l'insu de l'expéditeur d'origine qu'il a même causé un problème. C'est là que réside le problème le plus profond: pourquoi le demandeur ne connaît-il pas déjà la régression et pourquoi ne l'ont-ils pas corrigé eux-mêmes? La situation que vous avez décrite peut indiquer un manque de la responsabilité ou la vigilance de la part du soumissionnaire d'origine, ce qui est une préoccupation potentielle en ce qui concerne sa performance globale et sa motivation.
Mon expérience en génie logiciel m'a appris à maîtriser toutes mes modifications de code, pas seulement les projets dont je suis responsable, jusqu'à la production, ce qui comprend la conscience de leur impact, y compris sur votre système de construction et (évidemment) le comportement du produit.
Si le changement de quelqu'un a causé un problème, cela ne signifie pas que la personne est un mauvais ingénieur, mais généralement, elle devrait être responsable et impliquée dans la réparation de tout ce qui a mal tourné. Même s'ils ne sont pas "en faute", par exemple leur code a révélé un bogue sous-jacent qui existe dans la base de code depuis des années, ils devraient être l'une des premières personnes à être au courant d'un problème avec leur modification. Même si le demandeur d'origine n'est pas la bonne personne pour corriger le bogue, il doit être étroitement lié au cycle de vie de son changement.
Bonne traction sur votre question! Tout le monde vous a dit quoi faire. Dois-tu le dire? OUI! Chaque fois que la question demande "devrais-je communiquer plus?", La réponse est presque toujours OUI!
Mais pour ajouter quelque chose de différent: votre prémisse est défectueuse.
Un collègue a fait un commit qui n'a pas cassé CI, mais vous a amené à découvrir un problème.
Félicitations! Vous avez trouvé un nouveau bug, pas une régression. Sérieusement, testez-vous manuellement chaque scénario et chaque ligne de code non couverts par des tests automatisés (ou manuels standardisés) lorsque vous vous engagez?
Par tous les moyens, impliquez votre collègue dans le correctif, avec des tests pour vous assurer qu'il ne peut plus se reproduire. Vous êtes tous les deux des héros! Mais si vous laissez échapper un blâme dans Word ou dans l'action, vous êtes responsable de perpétuer l'une des pires maladies organisationnelles: la responsabilité sans responsabilité.
Si vous avez vraiment besoin de trouver un méchant, pensez au gars qui a commis le code original qui s'est cassé et a laissé un piège à votre copain sans méfiance (évidemment sans couverture de test suffisante). J'espère que ce n'était pas toi!
En plus de ce que les autres ont dit, assurez-vous que c'est réellement leur commit qui a causé un bug. Ne blâmez certainement pas quelqu'un d'autre pour votre propre erreur. Quelle que soit la tactique avec laquelle vous les approchez, vous allez toujours les énerver si vous les avez blâmés pour quelque chose qu'ils n'ont pas fait. (Parlant comme quelqu'un qui a été blâmé pour les bugs des autres constamment; une fois, quelqu'un est venu vers moi et a dit que j'avais fait quelque chose de complètement stupide et j'ai fait apparaître le journal de validation et j'ai constaté que la dernière personne à toucher cette ligne de code était la personne qui me blâmait. D'une manière ou d'une autre, il semblait toujours penser que c'était de ma faute parce que j'avais écrit la ligne à l'origine.)
Oui. Demandez à la personne d'examiner le correctif que vous avez apporté au code. Parfois, j'ai trouvé que le bogue de quelqu'un d'autre était en fait une partie délicate du code avec d'autres conséquences invisibles si le bogue était simplement corrigé.
Réponse simple: oui.
Réponse plus longue: Mon dernier emploi était dans une entreprise Agile qui utilisait TDD avec des outils CI pour s'assurer que ce qui était dans notre référentiel SVN était bon et fonctionnait à tout moment. Quand quelque chose a été commis, notre serveur TeamCity a obtenu une copie, compilé et exécuté des tests unitaires. Il a également effectué des tests d'intégration toutes les heures. Si quelque chose a été commis qui a provoqué l'échec de l'IC, tout le monde a reçu un e-mail indiquant que la version avait été interrompue sur la base d'une validation par une personne particulière.
Cela n'a pas toujours tout saisi; malheur à nous, nous n'avons pas appliqué la couverture du code, et même si quelque chose a été couvert par des tests unitaires ou d'intégration, ils pourraient ne pas exercice ce code suffisamment. Lorsque cela s'est produit, celui qui a eu la tâche de résoudre le problème connu (si QA l'a détecté) ou le défaut (si, dun-dun-dun, les clients l'ont fait), lancerait un "blâme" (montre qui a modifié en dernier chaque ligne d'un fichier de code) et déterminer le coupable.
Appeler quelqu'un pour vérifier le code cassé n'est pas nécessairement une mauvaise chose. Ils n'ont pas fait leur travail correctement, et eux ou quelqu'un d'autre ont dû revenir en arrière et corriger l'erreur. Ça arrive tout le temps; la taille d'une affaire dépend de la facilité avec laquelle la correction a été effectuée, si l'erreur indique que la personne n'a même pas compilé ou exécuté le code en question, et la culture d'entreprise globale. Ce qui est important dans tout cela, c'est que quelque chose est appris par la personne qui a fait l'erreur; si la construction se brise à cause du même gars encore et encore, il y a un problème plus profond avec cette personne qui doit être résolu. Les constructions qui se cassent tout le temps indiquent un problème avec la communication de l'équipe ou la connaissance du processus.
Considérez toujours l'autre personne comme quelqu'un de meilleur que vous, voyez toujours les autres bonnes caractéristiques et sachez toujours que je peux aussi faire des erreurs.
Dites-leur quand ce n'est que vous deux.
Si quelqu'un est offensé lorsque vous lui dites qu'il a fait une erreur, cela signifie qu'il pense qu'il est le plus sage du monde et qu'il ne se trompe pas, et lorsqu'il est critiqué, il a le sentiment, comme nous l'avons dit en Pologne, que `` la couronne tombe de sa tête'.
Il ne faut donc pas hésiter à dire que quelqu'un a fait une erreur. C'est normal. Tout le monde fait des erreurs, même les meilleures! Seuls ceux qui ne font rien ne se trompent pas;)
Pourquoi ne vois-je pas ici une seule réponse qui reflète le commentaire le plus voté sur la question?
Oui, parlez-en absolument, mais ne le faites pas devant toute l'équipe
Approchez le développeur 1: 1 et signalez le bug. Ne vous en faites pas trop. J'ai toujours pensé que signaler l'erreur devant toute l'équipe était une mauvaise idée. Cela peut fonctionner pour certains développeurs, mais ce n'est pas pour tout le monde et peut avoir un effet négatif. Rappelez-vous, nous avons tous été à leur place à un moment ou à un autre, et comme le dit la deuxième réponse la plus votée, vous apprenez de vos erreurs
Je trouve généralement que cela fonctionne mieux lorsque vous commencez avec un compliment et que vous obtenez l'erreur ... quelque chose comme "le correctif que vous avez implémenté fonctionne très bien, MAIS il semble avoir cassé x, y, z" ou "merci d'avoir fait un , b, c, MAIS cela semble causer x, y, z "
Il y a beaucoup de facteurs en jeu.
- Quelle est la gravité du bug?
- Quelle est la relation d'ancienneté entre vous et le briseur?
- À quel point l'équipe est-elle occupée/stressée?
- Le disjoncteur fonctionnait-il dans sa partie de la base de code ou dans la vôtre?
- Dans quelle mesure êtes-vous certain que c'était un vrai bug et dans quelle mesure êtes-vous certain que votre correction est correcte?
Si le problème était mineur - un bug typo/thinko/couper-coller - et que le briseur est un pair occupé, et que vous êtes confiant dans votre évaluation du problème, vous n'avez probablement pas besoin de le porter à leur attention. (par exemple. foo.x = bar.x; foo.y = bar.y, foo.z = bar.y).
Dans la plupart des autres cas, c'est une bonne idée de mentionner le problème. Dans les cas non graves, vous n'avez pas besoin d'interrompre ce qu'ils font; attendez et faites-le pendant le déjeuner ou lorsque vous les rencontrez dans la salle de pause.
Si la nature de l'erreur indique un grave malentendu (de la plate-forme de mise en œuvre, des politiques locales ou des spécifications du projet), signalez-le dès que possible.
Si vous n'êtes pas certain de votre évaluation, demandez-leur de revoir votre correctif, surtout si ce n'est pas dans le code que vous connaissez bien. (Je recommande fortement à votre équipe de développement d'adopter une politique de `` copain de code '' dans laquelle tous les changements sont examinés par une autre personne avant l'enregistrement, de toute façon.)
Que se passe-t-il si vous ne leur dites pas?
Les inconvénients
Ils peuvent faire la même erreur dans d'autres endroits parce qu'ils ne comprennent pas que cela cause un problème. Non seulement cela, mais il y aura du temps supplémentaire inutile pour corriger à plusieurs reprises la même erreur. Vous ne pouvez pas apprendre des erreurs que vous ignorez.
Deuxièmement, ils pensent qu'ils font un meilleur travail qu'eux. Lorsque les gens ne sont pas informés de leurs problèmes, on peut difficilement leur reprocher de penser qu'ils se portent bien lorsqu'ils ne le sont pas. Même lorsque le problème est une erreur imprudente, les gens en font moins lorsqu'ils sont conscients que les erreurs sont constatées.
Ensuite, si quelqu'un ne recherche pas qui l'a fait, comment saurez-vous si vous avez un employé à problème particulier qui est toujours négligent ou a des malentendus de base sur le produit? Une personne responsable voudrait-elle que cela continue dans une équipe à laquelle elle est associée?
Si vous réparez et continuez sans en discuter, êtes-vous sûr, vous l'avez corrigé correctement? Parfois, ce sont des tests qui doivent changer quand une exigence change. Si c'est autre chose qu'une faute de frappe assez mineure, pouvez-vous vraiment être sûr que l'un de vous a la bonne solution? Vous pourriez casser son code en retour sans consulter.
Les avantages
Les gens ne sont pas gênés ou ennuyés avec vous pour avoir souligné leurs erreurs.
Je suppose que je suis fortement du côté de leur dire mais de le faire gentiment et en privé. Il n'y a pas besoin d'humiliation publique. Si la personne fait à plusieurs reprises les mêmes erreurs ou commet des erreurs critiques qui montrent un manque de compréhension, le superviseur doit également en être informé.