Devrais-je dire à quelqu'un que leur commit a provoqué une régression?

Lorsque vous traquez et corrigez une régression, c'est-à-dire un bogue qui empêchait le code précédemment fonctionnel de fonctionner, le contrôle de version rend tout à fait possible de rechercher qui a validé le changement qui l'a cassé.

Cela vaut-il la peine? Est-ce constructif de le signaler à la personne qui a commis le crime? La nature de l'erreur (de l'ampleur de l'inattention simple à l'incompréhension fondamentale du code modifié) change-t-elle si c'est une bonne idée ou non?

Si c'est une bonne idée de leur dire, quels sont les bons moyens de le faire sans offenser ni les amener à se mettre sur la défensive?

Supposons, à des fins de discussion, que le bogue est suffisamment subtil pour que les tests automatisés du serveur CI ne puissent le détecter.

Si vous les approchez simplement pour leur parler d'une erreur qu'ils ont commise, à moins d'être le meilleur diplomate du monde, il sera difficile pour vous de ne pas sonner comme "Ha! Regardez cette erreur que vous avez commise!". Nous sommes tous humains et la critique est difficile à prendre.

D'un autre côté, à moins que le changement soit complètement trivial et manifestement faux, je trouve normalement bénéfique de parler à la personne qui a commis le changement initial dans le cadre de mon enquête, juste pour m'assurer que je comprends parfaitement ce qui se passe, d'où mon comportement habituel. En fin de compte, le problème est de contacter cette personne et d’avoir une conversation un peu comme ceci:

Moi: Je travaille sur ce bogue où ... résumé du bogue ... et je pense avoir identifié le problème pour un changement que vous avez apporté. Vous souvenez-vous à quoi servait ce changement? / avez-vous du temps pour expliquer ce changement?

Alors soit:

Eux: Bien sûr, c'est à gérer ... une situation dont je n'étais pas au courant ...

Ou quelque chose comme:

Them: Non désolé je ne me souviens pas, me semble mal.

En enquêtant ensemble sur le changement / le bogue, le commetteur original apprend de ses erreurs sans avoir le sentiment d'être critiqué *, et il y a également de bonnes chances que vous appreniez aussi quelque chose.

Si le commetteur d'origine n'est pas présent ou est occupé, vous pouvez toujours vous y glisser et vous en rendre compte 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 réellement intéressé par l'aide des autres personnes. Si vous utilisez simplement ceci comme une méthode à peine déguisée de parler à quelqu'un d'une erreur qu'ils ont commise, alors c'est probablement pire que de simplement en parler ouvertement.

Soyez assertif pas agressif. Toujours préférer dire quelque chose comme "ce morceau de code ne fonctionne pas" vs "votre code ne fonctionne pas". Critiquez le code, pas la personne qui l'a écrit.

Mieux encore, si vous pouvez penser à une solution, corrigez-la et appuyez dessus - en supposant que vous disposiez d'un système de contrôle de version distribué. Puis demandez-leur si votre solution est valide pour le bogue qu'ils corrigeaient. Dans l’ensemble, essayez d’accroître vos connaissances et celles de vos connaissances en matière de 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 qui vous abordent avec le même problème et à agir comme vous l'auriez souhaité.

Oui, toujours . En tant que programmeur, votre travail consiste à apprendre des erreurs.

Leur faire savoir les erreurs qu’ils commettent les aidera à devenir un meilleur codeur et à réduire leurs chances de faire des erreurs à l’avenir. MAIS soyez poli et n’en faites pas une grosse affaire, nous créons tous des bugs de temps en temps. Je trouve qu'un courriel poli est une façon très peu conflictuelle de faire savoir aux gens.

La méthode constructive consiste à rechercher le bogue, à le corriger et à prendre des mesures pour éviter que de tels bogues ne se reproduisent à l'avenir.

Si cela implique d'expliquer aux gens comment ne pas introduire de bugs, foncez.

Une fois, j’ai travaillé dans une équipe où le chef de projet n’avait jamais dit à un développeur qu’il avait commis une erreur: il avait organisé une réunion avec l’ensemble de l’équipe. Il avait expliqué qu’une erreur avait été commise et qu’un nouveau processus avait été défini pour supprimer ce genre d'erreurs. De cette façon, personne n'a été stigmatisé.

En général oui .

Personne ne devrait être sur la défensive si vous faites preuve de tact. Un moyen facile de le gérer consiste à leur demander de vérifier votre modification avant de la renvoyer dans le coffre (ou tout autre élément pertinent pour votre système de contrôle de version). Les gens l'apprécieront si vous leur épargnez 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 que vous finissez par casser leur code. En leur donnant une chance d'examiner votre changement, vous leur dites que vous ne voulez pas marcher sur leurs pieds et leur donne l'occasion de s'opposer à vos changements.

S'il s'agit d'un gros changement plutôt que d'une simple faute de frappe, c'est une bonne idée de prévenir l'auteur avant de creuser pour essayer de le réparer. "Joe, je fusionnais mes propres données hier et j'ai trouvé quelque chose que je ne suis pas sûr de comprendre. Cela ressemble à un bug, mais je voulais le vérifier avant que je ne me mêle de votre code. Voulez-vous jeter un coup d'oeil avec moi?"

Votre relation avec l'auteur est un facteur important. Si cela ne vous dérange pas que l'auteur corrige votre code sans vous le dire, et si vous êtes à peu près sûr que le sentiment est réciproque, il est peut-être inutile de le mentionner. S'il s'agit d'une personne ayant plus d'expérience / ancienneté / statut, vous voudrez bien lui faire savoir que vous allez modifier son code. Si c'est quelqu'un avec moins, déterminez si c'est le genre de chose qu'ils ont besoin d'entendre pour éviter de répéter l'erreur ou si cela pourrait les gêner inutilement.

Rappelez-vous toujours que si vous pouvez savoir qui a vérifié le "bogue", ils peuvent tout aussi facilement savoir qui a "corrigé" leur code. Si vous pensez qu'ils seraient bouleversés / ennuyés / embarrassés de découvrir votre changement après coup, informez-les d'avance.

En outre, la résolution du bogue n'est pas votre seule option. Vous pouvez toujours simplement signaler le bogue dans votre outil de suivi des problèmes. Le tact est à nouveau nécessaire ici - signaler le bogue le rend plus visible pour toute l'équipe, mais donne également à l'auteur une chance de réparer sa propre erreur. La création de rapports est la meilleure option si vous n'êtes pas certain du meilleur moyen de résoudre le problème ou si vous n'avez 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 avec 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 responsable une fois lorsque je commettais une erreur.

J'étais le consultant d'âge moyen avec le doctorat et elle était la jeune dirigeante sans, alors il aurait pu y avoir un gradient de prestige perçu. En tout état de cause, elle avait clairement eu l'expérience de cette situation et savait comment la gérer.

Elle m'a fait remarquer avec un ton presque désolé qu'il semblait y avoir un problème et aurais-je le temps de le vérifier?

Souvent, l'erreur était la mienne et elle le savait. C'est la compétence.

Je pense qu'il y a un problème plus profond sous-jacent à cette question. Oui, le demandeur devrait certainement être mis au courant des conséquences de son changement, afin de pouvoir comprendre ce qui s'est passé et de ne pas refaire la même chose. Toutefois, le contexte de votre question indique que vous avez préparé et soumis un correctif sans que l’auteur de l’émetteur original sache qu’ils ont même causé un problème. Le problème est plus profond: pourquoi l’émetteur n’a-t-il pas déjà connaissance de la régression et pourquoi ne l’a-t-il pas réglé lui-même? La situation que vous avez décrite peut indiquer un manque de responsabilité ou de vigilance de la part du demandeur initial, ce qui peut être une source de préoccupation pour ses performances et sa motivation.

Mon expérience en génie logiciel m'a appris à maîtriser tous mes changements de code, pas seulement les projets dont je suis responsable, jusqu'à la production, ce qui implique d'être conscient de leur impact, y compris sur votre système de construction et (évidemment) sur 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 de la résolution de tout ce qui a mal tourné. Même s'ils ne sont pas "fautifs", leur code exposant par exemple un bogue sous-jacent qui existe dans la base de code depuis des années, ils devraient être parmi les premiers à être conscients d'un problème lié à leur modification. Même si l'émetteur d'origine n'est pas la bonne personne pour résoudre le bogue, il doit être étroitement lié au cycle de vie de son changement.

Bonne réponse à votre question! Tout le monde vous a dit quoi faire. Devriez-vous dire? OUI! Chaque fois que la question demande "dois-je communiquer plus?", La réponse est presque toujours OUI!

Mais pour ajouter quelque chose de différent: votre prémisse est imparfaite.

Un collègue a fait un commit qui n'a pas cassé l'IC, mais vous a conduit à découvrir un problème.

Félicitations! Vous avez trouvé un nouveau bogue, 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 normalisés) lors de la validation?

Bien sûr, impliquez votre collègue dans le correctif, avec des tests pour vous assurer que cela ne se reproduira plus. Vous êtes les deux héros! Mais si vous laissez échapper tout blâme en paroles ou en actes, vous êtes responsable de la perpétuation d’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 a cassé, et a laissé un piège à votre ami sans méfiance (évidemment sans couverture de test suffisante). Espérons que ce n'était pas vous!

Considérez toujours votre interlocuteur comme quelqu'un de meilleur que vous, considérez toujours les autres comme de bonnes caractéristiques et sachez toujours que je peux aussi faire des erreurs.

Dites-leur que ce n'est que vous deux.

Si quelqu'un s'offusque quand vous lui dites qu'il a commis une erreur, cela signifie qu'il pense qu'il est le plus sage de la planète et ne commet aucune erreur. Lorsqu'il est critiqué, il a le sentiment, comme nous l'avons dit en Pologne, que "la couronne tombe de sa tête'.

Donc, vous ne devriez pas hésiter à dire que quelqu'un a commis une erreur. C'est normal. Tout le monde fait des erreurs, même les meilleurs! Seuls ceux qui ne font rien ne font aucune erreur;)

En plus de ce que d’autres ont dit, assurez-vous que c’est réellement leur commit qui a provoqué un bogue. Certainement, ne blâmez pas quelqu'un d'autre pour votre propre erreur. Peu importe avec quelle tactique 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 en tant que quelqu'un qui a été constamment blâmé pour les bugs d'autrui; une fois, quelqu'un est venu me dire que j'avais fait quelque chose de complètement stupide et j'ai évoqué le journal de commit et découvert que la dernière personne à avoir touché cette ligne de code était le personne qui me blâmait. Il semblait toujours penser que c’était de ma faute parce que j’avais écrit la phrase à

Pourquoi ne vois-je pas une seule réponse ici qui reflète le commentaire le plus voté sur la question?

Oui, absolument, parlez-leur de cela, mais ne le faites pas devant toute l'équipe

Approchez le développeur 1: 1 et signalez le bogue. Ne faites pas une grosse affaire. 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 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 ensuite 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 de faire une , b, c, MAIS cela semble causer x, y, z "

Réponse simple: oui.

Réponse plus longue: Mon dernier emploi concernait une société agile qui utilisait TDD avec des outils CI pour s’assurer que le contenu de notre référentiel SVN était correct et que le code fonctionnait à tout moment. Lorsque quelque chose était commis, notre serveur TeamCity en avait une copie, compilée et exécuté des tests unitaires. Il a également exécuté des tests d'intégration toutes les heures. Si quelque chose a été commis qui a causé l'échec de l'EC, tout le monde a reçu un courrier électronique indiquant que la construction avait échoué sur la base d'un commit commis par une personne en particulier.

Cela n'a pas toujours attrapé tout; malheur à nous, nous n'avons pas imposé la couverture de code, et même si quelque chose était couvert par des tests unitaires ou d'intégration, ils pourraient ne pas exercer suffisamment ce code. Lorsque cela se produisait, quiconque était chargé de résoudre le problème connu (si QA l’avait capturé) ou le défaut (si, dun-dun-dun, les clients l’avaient fait), exécutait un "blâme" (montre qui a modifié en dernier chaque ligne d’un message). fichier de code) et déterminez le coupable.

Demander à quelqu'un de vérifier si le code est cassé n'est pas nécessairement une mauvaise chose. Ils ont échoué à faire leur travail correctement, et soit eux-mêmes, soit quelqu'un d'autre ont dû revenir en arrière et réparer l'erreur. Ça arrive tout le temps; L'ampleur du problème dépend de la facilité avec laquelle le correctif a été trouvé, si l'erreur indique que la personne n'a même pas compilé ou exécuté le code en question, ainsi que de la culture d'entreprise globale. Ce qui est important, c’est que la personne qui a commis l’erreur ait appris quelque chose; si la construction se casse encore et encore à cause du même gars, il faut régler un problème plus profond avec cette personne. Les mises à jour régulières indiquent un problème avec la communication de l'équipe ou sa connaissance du processus.

Oui. Demandez à la personne d'examiner le correctif que vous avez apporté au code. Parfois, j'ai découvert que le bogue de quelqu'un d'autre était en réalité une partie délicate du code, avec d'autres conséquences invisibles si le bogue était simplement corrigé.

Il y a beaucoup de facteurs en jeu.

• Quelle est la gravité du bogue?
• Quelle est la relation d'ancienneté entre vous et le disjoncteur?
• A quel point l'équipe est-elle occupée / stressée?
• Le disjoncteur fonctionnait-il dans leur partie de la base de code ou dans la vôtre?
• Dans quelle mesure êtes-vous certain qu'il s'agissait d'un véritable bogue et que votre correctif est correct?

Si le problème était mineur - une erreur de typo / thinko / couper-coller - et que le disjoncteur est un peer occupé et que vous avez confiance en votre évaluation du problème, vous n'avez probablement pas besoin de le signaler à 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 repos.

Si la nature de l'erreur indique un malentendu grave (de la plate-forme de mise en œuvre, des règles locales ou des spécifications du projet), affichez-la dès que possible.

Si vous n'êtes pas certain de votre évaluation, demandez-leur de réviser votre correctif, en particulier s'il ne s'agit pas de code avec lequel vous êtes très familier. (Je recommande fortement à votre équipe de développement d'adopter une politique de "copain code" dans laquelle tous les changements sont examinés par une autre personne avant l'enregistrement, de toute façon.)

Qu'est-ce qui se passe si vous ne leur dites pas?

Les inconvénients

Ils peuvent faire la même erreur ailleurs car ils ne comprennent pas que cela cause un problème. Non seulement cela, mais il y aura un temps supplémentaire inutile pour réparer à 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 ne peut leur reprocher de penser qu'ils vont bien alors qu'ils ne le sont pas. Même lorsque le problème est une erreur imprudente, les gens en font moins quand ils sont conscients que les erreurs sont remarquées.

Ensuite, si quelqu'un ne cherche pas qui l'a fait, comment saurez-vous si vous avez un employé qui a un problème particulier qui est toujours négligent ou qui a des malentendus élémentaires du produit? Une personne responsable voudrait-elle que cela continue dans une équipe à laquelle il est associé?

Si vous corrigez et passez à autre chose sans en discuter, êtes-vous sûr que vous l'avez corrigé correctement? Parfois, ce sont les 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 être briser son code en retour sans consulter.

Les pros

Les gens ne sont pas gênés ou agacés par vous pour avoir souligné leurs erreurs.

Je suppose que je suis fortement découragé de le leur dire mais de le faire gentiment et en privé. Il n'y a pas besoin d'humiliation publique. Si la personne commet de manière répétée les mêmes erreurs ou commet des erreurs critiques qui montrent un manque de compréhension, le superviseur doit également en être informé.