it-swarm.com.de

Sollte ich jemandem sagen, dass sein Commit eine Regression verursacht hat?

Wenn Sie eine Regression aufspüren und korrigieren - d. H. Ein Fehler, der dazu führte, dass zuvor funktionierender Code nicht mehr funktionierte. Die Versionskontrolle ermöglicht es, nachzuschlagen, wer die Änderung begangen hat, die ihn gebrochen hat.

Lohnt es sich das zu tun? Ist es konstruktiv, die Person, die die Verpflichtung eingegangen ist, darauf hinzuweisen? Ändert sich die Art des Fehlers (auf der Skala der einfachen Unaufmerksamkeit gegenüber grundlegenden Missverständnissen des von ihnen geänderten Codes), ob es sich um eine gute Idee handelt oder nicht?

Wenn es eine gute Idee ist, ihnen zu sagen, wie kann man das tun, ohne Anstoß zu nehmen oder sie in die Defensive zu treiben?

Nehmen Sie aus Gründen der Argumentation an, dass der Fehler so subtil ist, dass die automatisierten Tests des CI-Servers ihn nicht erkennen können.

117
Scott

Wenn Sie sich nur an sie wenden, um ihnen von einem Fehler zu erzählen, den sie gemacht haben, wird es schwierig, wenn Sie nicht der beste Diplomat der Welt sind, nicht nur so zu klingen wie "Ha! - Sehen Sie sich diesen Fehler an, den Sie gemacht haben!". Wir sind alle Menschen und Kritik ist schwer zu ertragen.

Auf der anderen Seite finde ich es normalerweise nützlich, mit der Person zu sprechen, die die ursprüngliche Änderung im Rahmen meiner Untersuchung vorgenommen hat, um sicherzustellen, dass ich vollständig verstehe, was vor sich geht, es sei denn, die Änderung ist völlig trivial und offensichtlich falsch Daher gehe ich normalerweise mit dieser Situation um, indem ich zu dieser Person gehe und ein Gespräch führe, das ein wenig so verläuft:

Me : Ich arbeite an diesem Fehler, bei dem ... Zusammenfassung des Fehlers ... und ich denke, ich habe Das Problem wurde auf eine von Ihnen vorgenommene Änderung zurückgeführt. Können Sie sich erinnern, wofür diese Änderung war?/Hast du etwas Zeit, um diese Änderung zu erklären?

Dann entweder:

Them : Sicher, das ist zu handhaben ... Situation, die mir nicht bewusst war ...

Oder etwas in der Art von:

Them : Nein, tut mir leid, ich erinnere mich nicht, sieht für mich falsch aus.

Wenn der ursprüngliche Committer die Änderung/den Fehler gemeinsam untersucht, kann er aus seinen Fehlern lernen, ohne nur das Gefühl zu haben, kritisiert zu werden *, und es besteht auch eine ziemlich gute Chance, dass Sie auch etwas lernen.

Wenn der ursprüngliche Committer nicht in der Nähe ist oder beschäftigt ist, können Sie immer einfach durchgehen und alles selbst herausfinden. Normalerweise finde ich, dass das Gespräch mit der Person, die die Änderung ursprünglich vorgenommen hat, schneller ist.

* Natürlich wird dies nur funktionieren, wenn Sie wirklich an der Hilfe der anderen Personen interessiert sind. Wenn Sie dies nur als eine kaum getarnte Methode verwenden, um jemandem von einem Fehler zu erzählen, den er gemacht hat, dann ist dies wahrscheinlich schlimmer als nur offen darüber zu sein.

38
Justin

Seien Sie selbstbewusst und nicht aggressiv. Sagen Sie immer lieber etwas, das mit "Dieser Code funktioniert nicht" oder "Ihr Code funktioniert nicht" vergleichbar ist. Kritisieren Sie den Code, nicht die Person, die den Code geschrieben hat.

Besser noch, wenn Sie sich eine Lösung vorstellen können, beheben Sie diese und drücken Sie sie an - vorausgesetzt, Sie haben ein verteiltes Versionskontrollsystem. Fragen Sie sie dann, ob Ihr Fix für den Fehler gültig ist, den sie behoben haben. Versuchen Sie insgesamt, Ihre und ihre Programmierkenntnisse zu verbessern. Aber mach es, ohne dass dein Ego in die Quere kommt.

Natürlich sollten Sie bereit sein, anderen Entwicklern zuzuhören, die mit demselben Problem zu Ihnen kommen, und so zu handeln, wie Sie es sich gewünscht hätten.

Ja, immer. Als Programmierer ist es Ihre Aufgabe, aus Fehlern zu lernen.

Wenn sie wissen, welche Fehler sie machen, werden sie zu einem besseren Programmierer und verringern die Wahrscheinlichkeit, in Zukunft Fehler zu machen. ABER Sei höflich und mache keine große Sache daraus, wir alle schaffen ab und zu Fehler. Ich finde, eine höfliche E-Mail ist eine sehr nicht konfrontative Art, die Leute zu informieren.

70
Tom Squires

Der konstruktive Weg besteht darin, den Fehler zu finden, zu beheben und Maßnahmen zu ergreifen, um zu vermeiden, dass in Zukunft ähnliche Fehler auftreten.

Wenn es darum geht, den Leuten zu erklären, wie man keine Fehler einführt, dann machen Sie es.

Einmal habe ich in einem Team gearbeitet, in dem der Projektmanager einem bestimmten Entwickler nie gesagt hat, dass er einen Fehler gemacht hat: Er hat ein Meeting mit dem gesamten Team organisiert, in dem er erklärt hat, dass ein Fehler gemacht wurde und dass ein neuer Prozess definiert wurde, um ihn zu unterdrücken diese Art von Fehlern. Auf diese Weise wurde niemand stigmatisiert.

23
mouviciel

Im Allgemeinen ja.

Niemand sollte defensiv werden, wenn Sie taktvoll sind. Eine einfache Möglichkeit, damit umzugehen, besteht darin, sie zu bitten, Ihre Änderung zu überprüfen, bevor Sie sie wieder in den Trunk übertragen (oder was auch immer für Ihr Versionskontrollsystem relevant ist). Die Leute werden es zu schätzen wissen, wenn Sie sie ein paar Minuten durch Beheben offensichtlicher Fehler speichern, aber sie werden es nicht zu schätzen wissen, wenn Sie etwas reparieren, das nicht kaputt war, und am Ende ihren Code kaputt machen. Wenn Sie ihnen die Möglichkeit geben, Ihre Änderung zu überprüfen, werden sie darauf hingewiesen, dass Sie ihnen nicht auf die Zehen treten möchten, und sie haben die Möglichkeit, Einwände gegen Ihre Änderungen zu erheben.

Wenn es sich eher um eine große Änderung als nur um einen Tippfehler handelt, ist es eine gute Idee, dem Autor einen Hinweis zu geben, bevor Sie versuchen, das Problem zu beheben. "Joe, ich habe gestern meine eigenen Sachen zusammengeführt und etwas gefunden, von dem ich nicht sicher bin, ob ich es verstehe. Es sieht aus wie ein Fehler, aber ich wollte es von dir ausführen, bevor ich mit deinem Code herumspiele. Würdest du es dir ansehen?" mir?"

Ihre Beziehung zum Autor ist ein wichtiger Faktor. Wenn es Ihnen nichts ausmacht, wenn der Autor Ihren Code repariert, ohne es Ihnen mitzuteilen, und wenn Sie sich ziemlich sicher sind, dass das Gefühl gegenseitig ist, ist es möglicherweise nicht erwähnenswert. Wenn es sich um jemanden mit mehr Erfahrung/Dienstalter/Status handelt, möchten Sie ihn wissen lassen, dass Sie seinen Code ändern werden. Wenn es jemand mit weniger ist, dann überlegen Sie, ob es die Art von Dingen ist, die sie hören müssen, um zu vermeiden, dass sich der Fehler wiederholt, oder es könnte sie unnötig in Verlegenheit bringen.

Denken Sie immer daran, dass, wenn Sie herausfinden können, wer den "Fehler" eingecheckt hat, diese genauso leicht herausfinden können, wer ihren Code "repariert" hat. Wenn Sie glauben, dass sie verärgert/verärgert/verlegen wären, wenn sie später von Ihrer Änderung erfahren würden, sagen Sie es ihnen auf jeden Fall vorher.

Außerdem ist die Behebung des Fehlers nicht Ihre einzige Option. Sie können den Fehler jederzeit in Ihrem Issue-Tracker melden. Auch hier ist wieder Takt erforderlich - die Meldung des Fehlers macht ihn für das gesamte Team sichtbarer, gibt dem Autor aber auch die Möglichkeit, seinen eigenen Fehler zu beheben. Die Berichterstellung ist die beste Option, wenn Sie sich nicht sicher sind, wie Sie das Problem am besten beheben können, oder wenn Sie einfach keine Zeit haben, das Problem zu beheben.

19
Caleb

Wenn ich ein Commit mache, das einen Fehler enthält, sollten Sie es mir besser sagen. Wenn ich ein Commit von Ihnen finde, das einen Fehler enthält, werde ich es Ihnen sicherlich sagen.

Wir verbessern uns nur, wenn wir unsere Fehler verstehen. So produzieren wir in Zukunft besseren Code.

6
D Krueger

Hier erhalten Sie hervorragende Antworten.

Ich konnte eine Technik, die ich von einem Manager gelernt hatte, nur einmal hinzufügen, wenn ich einen Fehler machte.

Ich war der Berater mittleren Alters mit dem Ph.D. und sie war die junge Managerin ohne, also hätte es einen wahrgenommenen Prestigegradienten geben können. Auf jeden Fall hatte sie eindeutig Erfahrung mit dieser Situation und wusste, wie sie damit umgehen sollte.

Sie erwähnte mir in einem fast entschuldigenden Ton, dass es ein Problem zu geben schien, und würde ich Zeit haben, es zu untersuchen?

Oft genug war der Fehler mein Fehler und sie wusste es. Das ist Geschicklichkeit.

5
Mike Dunlavey

Ich denke, dieser Frage liegt ein tieferes Problem zugrunde. Ja, der Einreicher sollte auf jeden Fall auf die Konsequenzen seiner Änderung aufmerksam gemacht werden, damit er verstehen kann, was passiert ist, und nicht dasselbe noch einmal tun kann. Der Kontext Ihrer Frage zeigt jedoch, dass Sie einen Fix vorbereitet und eingereicht haben, ohne dass der ursprüngliche Übermittler wusste, dass er sogar ein Problem verursacht hat. Darin liegt das tiefere Problem: warum weiß der Einreicher nicht bereits über die Regression Bescheid und warum haben sie es nicht selbst behoben? Die von Ihnen beschriebene Situation kann auf einen Mangel an hinweisen Rechenschaftspflicht oder Wachsamkeit des ursprünglichen Einreichers, was ein potenzielles Problem hinsichtlich seiner Gesamtleistung und Motivation darstellt.

Meine Erfahrung in der Softwareentwicklung hat mich gelehrt, alle meine Codeänderungen zu besitzen, nicht nur Projekte, für die ich verantwortlich bin, bis hin zur Produktion, einschließlich der Kenntnis ihrer Auswirkungen, einschließlich Ihres Build-Systems und (offensichtlich) des Produktverhaltens.

Wenn die Änderung einer Person ein Problem verursacht hat, bedeutet dies nicht, dass die Person ein schlechter Ingenieur ist, aber normalerweise sollte sie für die Behebung von Fehlern verantwortlich und beteiligt sein. Selbst wenn sie nicht "schuld" sind, z. Ihr Code enthüllte einen zugrunde liegenden Fehler, der seit Jahren in der Codebasis besteht. Sie sollten eine der ersten Personen sein, die sich eines Problems mit ihrer Änderung bewusst sind. Auch wenn der ursprüngliche Übermittler nicht die richtige Person ist, um den Fehler zu beheben, sollte er eng mit dem Lebenszyklus seiner Änderung verbunden sein.

5

Gute Traktion auf Ihre Frage! Jeder hat dir gesagt, was zu tun ist. Solltest du sagen? JA! Immer wenn die Frage "Soll ich mehr kommunizieren?" Fragt, lautet die Antwort fast immer JA!

Aber um etwas anderes hinzuzufügen: Ihre Prämisse ist fehlerhaft.

Ein Mitarbeiter hat ein Commit durchgeführt, das CI nicht beschädigt hat, sondern Sie dazu veranlasst hat, ein Problem zu entdecken.

Glückwunsch! Sie haben einen neuen Fehler gefunden, keine Regression. Im Ernst, testen Sie manuell jedes Szenario und jede Codezeile, die nicht durch automatisierte (oder standardisierte manuelle) Tests abgedeckt sind, wenn Sie sich verpflichten?

Binden Sie auf jeden Fall Ihren Kollegen in das Update ein und testen Sie, ob es nicht wieder vorkommen kann. Ihr seid beide Helden! Wenn Sie jedoch eine Schuld in Word oder Handlung auslassen, sind Sie dafür verantwortlich, eine der schlimmsten organisatorischen Krankheiten aufrechtzuerhalten: Verantwortlichkeit ohne Verantwortung.

Wenn Sie wirklich einen Bösewicht finden müssen, denken Sie an den Mann, der den ursprünglichen Code begangen hat, der kaputt gegangen ist, und eine Falle für Ihren ahnungslosen Kumpel hinterlassen hat (offensichtlich ohne ausreichende Testabdeckung). Hoffentlich warst du das nicht!

4
tardate

Stellen Sie zusätzlich zu dem, was andere gesagt haben, sicher, dass es tatsächlich ihr Commit ist, das einen Fehler verursacht hat. Machen Sie auf keinen Fall jemand anderen für Ihren eigenen Fehler verantwortlich. Egal wie taktvoll Sie sich ihnen nähern, Sie werden sie immer noch verärgern, wenn Sie ihnen die Schuld für etwas geben, das sie nicht getan haben. (Als jemand zu sprechen, der ständig für die Fehler anderer Leute verantwortlich gemacht wurde; einmal kam jemand auf mich zu und sagte, ich hätte etwas völlig Dummes getan, und ich rief das Festschreibungsprotokoll auf und stellte fest, dass die letzte Person, die diese Codezeile berührte, die war Person, die mich beschuldigte. Irgendwie schien er immer noch zu denken, dass es meine Schuld war, weil ich die Zeile ursprünglich geschrieben hatte.)

2
fluffy

Ja. Bitten Sie die Person, die Korrektur zu überprüfen, die Sie am Code vorgenommen haben. Manchmal habe ich festgestellt, dass der Fehler eines anderen tatsächlich ein schwieriger Teil des Codes war, mit einigen anderen unsichtbaren Konsequenzen, wenn der Fehler einfach behoben wurde.

2
Stuart Woodward

Einfache Antwort: Ja.

Längere Antwort: Mein letzter Job war bei einem agilen Unternehmen, das TDD mit CI-Tools verwendete, um sicherzustellen, dass das, was in unserem SVN-Repo enthalten war, immer gut war und mit Code funktionierte. Wenn etwas festgeschrieben wurde, hat unser TeamCity-Server eine Kopie erhalten, kompiliert und Komponententests ausgeführt. Außerdem wurden stündlich Integrationstests durchgeführt. Wenn etwas festgeschrieben wurde, das zum Fehlschlagen des CI führte, erhielt jeder eine E-Mail mit der Meldung, dass der Build aufgrund eines Festschreibens einer bestimmten Person fehlerhaft war.

Das hat nicht immer alles erfasst; Wehe uns, wir haben die Codeabdeckung nicht erzwungen, und selbst wenn etwas durch Unit- oder Integrationstests abgedeckt wurde, wird dieser Code möglicherweise nicht ausreichend ausgeübt. Wenn dies geschah, würde jeder, der die Aufgabe hatte, das bekannte Problem (wenn die Qualitätssicherung es abfing) oder den Defekt (wenn, dun-dun-dun, die Kunden dies taten) zu beheben, eine "Schuld" tragen (zeigt, wer zuletzt jede Zeile von a geändert hat Codedatei) und bestimmen den Täter.

Es ist nicht unbedingt schlecht, jemanden zum Einchecken von fehlerhaftem Code anzurufen. Sie haben ihre Arbeit nicht richtig gemacht, und entweder sie oder jemand anderes mussten zurückgehen und den Fehler beheben. Das passiert die ganze Zeit; Wie groß das Geschäft sein sollte, hängt davon ab, wie einfach die Korrektur war, ob der Fehler darauf hinweist, dass die Person den betreffenden Code nicht einmal kompiliert oder ausgeführt hat, und von der gesamten Unternehmenskultur. Was bei der ganzen Sache wichtig ist, ist, dass etwas von der Person gelernt wird, die den Fehler gemacht hat; Wenn der Build aufgrund des gleichen Typen immer wieder unterbrochen wird, gibt es ein tieferes Problem mit dieser Person, das behoben werden muss. Builds, die ständig unterbrochen werden, weisen auf ein Problem mit der Kommunikation oder dem Wissen des Teams über den Prozess hin.

2
KeithS

Betrachten Sie die andere Person immer als jemanden, der besser ist als Sie, sehen Sie immer andere gute Eigenschaften und wissen Sie immer, dass ich auch Fehler machen kann.

Sagen Sie ihnen, wann es nur Sie beide sind.

2

Wenn jemand beleidigt ist, als Sie ihm sagten, er habe einen Fehler gemacht, bedeutet dies, dass er denkt, er sei der weiseste auf der Erde und macht keinen Fehler. Wenn er kritisiert wird, hat er, wie wir in Polen sagten, das Gefühl, dass die Krone abfällt sein Kopf'.

Sie sollten also nicht zögern zu sagen, dass jemand einen Fehler gemacht hat. Es ist normal. Jeder macht Fehler, auch die Besten! Nur wer nichts macht, macht keine Fehler;)

2
Danubian Sailor

Warum sehe ich hier keine einzige Antwort, die den am besten bewerteten Kommentar zu der Frage widerspiegelt?

Ja, erzähl ihnen unbedingt davon, aber mach es nicht vor dem gesamten Team

Sprechen Sie den Entwickler 1: 1 an und weisen Sie auf den Fehler hin. Mach keine große Sache daraus. Ich habe immer gedacht, dass es eine schlechte Idee ist, vor dem gesamten Team auf den Fehler hinzuweisen. Es könnte für einige Entwickler funktionieren, aber es ist nicht für alle und kann sich negativ auswirken. Denken Sie daran, wir waren alle irgendwann in ihren Schuhen und wie die zweitbeste Antwort sagt, lernen Sie aus Ihren Fehlern

Ich finde es normalerweise am besten, wenn Sie mit einem Kompliment beginnen und dann zum Fehler kommen ... so etwas wie "Das Update, das Sie implementiert haben, funktioniert großartig, ABER es scheint x, y, z gebrochen zu haben" oder "Danke, dass Sie a gemacht haben , b, c, ABER es scheint x, y, z zu verursachen. "

2
Rachel

Es spielen viele Faktoren eine Rolle.

  • Wie schwer ist der Fehler?
  • Wie ist das Dienstalter zwischen Ihnen und dem Breaker?
  • Wie beschäftigt/gestresst ist das Team?
  • Funktionierte der Breaker in ihrem oder Ihrem Teil der Codebasis?
  • Wie sicher sind Sie, dass es sich wirklich um einen Fehler handelte, und wie sicher sind Sie, dass Ihr Fix korrekt ist?

Wenn das Problem geringfügig war - ein Tippfehler/Thinko/Cut & Paste-Fehler - und der Breaker ein vielbeschäftigter Peer ist und Sie sich auf Ihre Einschätzung des Problems sicher sind, müssen Sie ihn wahrscheinlich nicht darauf aufmerksam machen. (z.B. foo.x = bar.x; foo.y = bar.y, foo.z = bar.y).

In den meisten anderen Fällen ist es eine gute Idee, das Problem zu erwähnen. In nicht schwerwiegenden Fällen müssen Sie nicht unterbrechen, was sie tun. Warten Sie und tun Sie es beim Mittagessen oder wenn Sie ihnen im Pausenraum begegnen.

Wenn die Art des Fehlers auf ein schwerwiegendes Missverständnis (der Implementierungsplattform, der lokalen Richtlinien oder der Projektspezifikation) hinweist, rufen Sie ihn so schnell wie möglich auf.

Wenn Sie sich Ihrer Einschätzung nicht sicher sind, bitten Sie sie, Ihr Update zu überprüfen, insbesondere wenn es sich nicht um Code handelt, mit dem Sie sehr vertraut sind. (Ich empfehle Ihrem Entwicklerteam dringend, eine "Code Buddy" -Richtlinie einzuführen, bei der alle Änderungen ohnehin vor dem Einchecken von einer anderen Person überprüft werden.)

1

Was passiert, wenn du es ihnen nicht sagst?

Die Nachteile

Sie können an anderen Stellen denselben Fehler machen, weil sie nicht verstehen, dass dies ein Problem verursacht. Darüber hinaus bleibt zusätzliche unnötige Zeit, um denselben Fehler wiederholt zu beheben. Sie können nicht aus Fehlern lernen, von denen Sie nicht wissen, dass Sie nade sind.

Zweitens denken sie, dass sie einen besseren Job machen als sie. Wenn Menschen nicht auf ihre Probleme aufmerksam gemacht werden, können sie kaum dafür verantwortlich gemacht werden, dass sie denken, dass es ihnen gut geht, wenn sie es nicht sind. Selbst wenn das Problem ein nachlässiger Fehler ist, machen die Leute weniger davon, wenn sie sich bewusst sind, dass die Fehler bemerkt werden.

Wenn jemand nicht nachschaut, wer es getan hat, woher wissen Sie dann, ob Sie einen bestimmten Problemmitarbeiter haben, der entweder immer nachlässig ist oder grundlegende Missverständnisse über das Produkt hat? Würde eine verantwortliche Person wollen, dass das in einem Team fortgesetzt wird, mit dem sie verbunden ist?

Wenn Sie das Problem beheben und weitermachen, ohne es zu diskutieren, sind Sie sicher, dass Sie es richtig behoben haben? Manchmal müssen sich Tests ändern, wenn sich eine Anforderung ändert. Können Sie wirklich sicher sein, dass einer von Ihnen die richtige Lösung hat, wenn es sich nicht um einen kleinen Tippfehler handelt? Möglicherweise brechen Sie seinen Code im Gegenzug ohne Rücksprache.

Die Profis

Die Leute schämen sich nicht für Sie, wenn Sie auf ihre Fehler hinweisen.

Ich schätze, ich bin stark auf der Seite, es ihnen zu sagen, aber ich mache es nett und privat. Es besteht keine Notwendigkeit für öffentliche Demütigung. Wenn die Person wiederholt dieselben Fehler macht oder kritische Fehler macht, die ein Unverständnis zeigen, muss auch der Vorgesetzte darauf aufmerksam gemacht werden.

1
HLGEM