Wie kann ich jemandem sagen, dass er meinen Code kaputt gemacht hat, und ihn bitten, ihn zu reparieren?

Ich habe kürzlich einen neuen Programmierjob begonnen und gerade meine erste Aufgabe abgeschlossen. Als Teil davon musste ich eine kritische Zeile in einer Datei von ABCin ändern XYZ.

Für meine zweite Aufgabe erwähnte ein Kollege, dass es hilfreich sein könnte, sich Code anzusehen, an dem mein Teamkollege Sam kürzlich gearbeitet hat. Er ist seit mehreren Jahren an dem Projekt beteiligt und sitzt im selben Büro wie ich. Als ich danach suchte, bemerkte ich, dass Sam kürzlich auch diese wichtige Datei aus meinem ersten Projekt bearbeitet hatte. Aus Neugier schaute ich genauer hin ... und stellte fest, dass die Bearbeitung diese Zeile auf zurücksetzteABC , um ein kleines Anzeigeproblem zu lösen.

Die ABCZeile führt in bestimmten Szenarien zum Absturz der gesamten Anwendung, weshalb ich beauftragt wurde, diese Änderung überhaupt vorzunehmen. Das muss natürlich behoben werden!

Ich möchte mit Sam darüber sprechen, weil:

  1. Ich weiß nicht, wie ich es am besten beheben kann, damit unsere beiden Probleme gelöst sind, und er hätte wahrscheinlich einige Ideen, da er erfahrener ist
  2. Ich würde mich sehr unbeholfen und unhöflich fühlen, nichts zu sagen und Sam beim Treffen nächste Woche zu überraschen, wenn ich erwähne: „Ich habe an [demselben Fehler, den er gerade ‚gefixt‘ hat] gearbeitet.“
  3. Ich möchte erklären, warum ich das getan habe, damit er in Zukunft nicht versehentlich weitere Fehler einführt. (Sam weiß, dass ich daran gearbeitet habe, also bin ich mir nicht sicher, warum ich nicht von Anfang an darauf aufmerksam gemacht wurde, aber das ist jetzt nebensächlich..)

Ich bin mir allerdings nicht sicher, wie ich Sam ansprechen soll. Normalerweise würde ich ein Gespräch wie dieses beginnen, indem ich eine Lösung vorschlage, die ich tun könnte, aber da ich neu in diesem Projekt bin, habe ich keine. Ich möchte nicht vorwurfsvoll oder besitzergreifend über meinen Code klingen. Sam scheint eine vernünftige Person zu sein, aber wenn er bedenkt, wie beschäftigt er ist, wäre er wahrscheinlich verärgert, wenn er dachte, ich würde versuchen, ihm dieses Problem zuzuschieben ("Hey, dein Code ist falsch, du musst ihn wiederholen"). Ich mache mir auch nur Sorgen, meinen Fuß in den Mund zu nehmen (ist in letzter Zeit leider ein paar Mal passiert) und bei meinen neuen Kollegen einen schlechten Eindruck zu hinterlassen.

Mehr Details

Unser Unternehmen verfügt über Quellcodeverwaltung, Fehlerverfolgung und Codeüberprüfungen für jeden Commit. Unsere Commits befinden sich beide bereits in der „Alpha“-Codebasis (sichtbar für Entwickler und Tester, aber nicht für die Öffentlichkeit freigegeben) und sind mit den jeweiligen Fehlern verknüpft, die sie beheben.

Seine Commit-Nachricht lautete: „Bug: Verlauf zeigt ABC nicht an. Fix: Zeile war nicht ABC, Zeile geändert.“ Ein Kommentar oben in der Datei erklärt, dass entweder oder XYZausgeführt wird , da dies nicht immer funktioniert. (Die richtigen Namen der Klassen ähneln eher "Thing" vs. "Thing Selector", falls das zur Erklärung beiträgt.) Deshalb vermute ich, dass er (und der Kollege, der seine Änderung überprüft hat) nicht wirklich nachgeschaut hat .ABCDEFABCXYZ

Leider hatte ich nur Tests, um sicherzustellen, dass XYZsie ordnungsgemäß funktionierten und nicht, dass diese Datei tatsächlich ausgeführt wurde XYZ(dort Lektion gelernt!).

Frage

Wie kann ich mich an Sam wenden, um ihn wissen zu lassen, dass sein „Fix“ meinen Code bricht, und seine Hilfe zu erhalten, um ihn tatsächlich zu reparieren?

Hat es Ihre Änderung in die Codebasis geschafft oder muss sie noch zusammengeführt werden?
@jcm Beide Änderungssätze befinden sich jetzt in der "Alpha" -Codebasis. Das heißt, es ist für Entwickler und eine begrenzte Anzahl von Benutzertestern sichtbar, aber nicht für die breite Öffentlichkeit.
Als Randbemerkung, da es so klingt, als hätten Sie keine Testsuite, die eine Warnung zu diesem Problem ausgelöst hätte, gibt es ein zusätzliches Kommunikationsproblem, das normalerweise durch Einfügen eines Inline-Kommentars behandelt werden sollte, der das (anscheinend nicht offensichtliche) Problem erklärt.
Anscheinend hatten Ihre Änderungen unerwünschte Nebeneffekte, sodass Sie das Problem nicht ordnungsgemäß behoben haben. Sie können Sam um Hilfe bitten, um das Problem zu beheben (und sich vielleicht dafür entschuldigen, dass Dinge kaputt gegangen sind).
Haben Sie Quellcodeverwaltung?
@Mast ja, ich habe in einer Bearbeitung weitere Details hinzugefügt

Antworten (4)

Du überdenkst das ein bisschen. Es kommt vor, dass Softwareentwickler Fehler machen. Das machen wir alle. Der beste Ansatz ist, es nicht als "das ist Ihr Fehler" oder "warum haben Sie meinen Code durcheinander gebracht " zu betrachten. Ich versuche (Betonung auf Versuch) dem Ansatz zu folgen, der als egolose Programmierung bezeichnet wird .

Der beste Ansatz ist also der direkte Ansatz. Senden Sie Sam eine E-Mail des Formulars „Ich habe ein Problem im X-Code bemerkt. Ich denke, es wird unter diesen Umständen abstürzen. Ich bin mir nicht sicher, was die Lösung ist. Ich würde es gerne mit Ihnen besprechen, wenn Sie welche haben Zeit, damit wir es herausfinden können, oder sehen, ob ich falsch liege". Angenommen, Sam ist ein Profi und nicht hyper-defensiv, wird er damit einverstanden sein.

Wenn der Fehler nicht kritisch oder zu schwer in einer E-Mail zu erklären ist, neige ich dazu, auf diese Weise zu arbeiten, damit sich die Leute in ihrer Zeit mit dem Problem befassen können.

Mach dir keine Sorgen darüber, wessen Schuld es ist. Sie arbeiten beide für das gleiche Unternehmen. Fehler betreffen Sie beide. Dem Kunden wird es egal sein, wer für den Fehler verantwortlich ist, wenn das Produkt abstürzt.

Jedes Mal, wenn so etwas passiert, versuche ich herauszufinden, wie es passiert ist und wie ich verhindern kann, dass es wieder passiert. Hat der beim Commit eingegebene Kommentar deutlich gemacht, was behoben wurde? Wenn die Lösung nicht offensichtlich ist, sollte es einen Kommentar im Code geben, der erklärt, was vor sich geht? Wie wäre es mit einem Unit-Test? Ist das „die Spitze des Eisbergs“ und gibt es verwandte Fehler?

Ich war noch nie in einem Unternehmen, das gerne xyz-Fehlerkommentare behoben hat, dafür sind Versionskontrolle und Commit-Kommentare da
@WendyG Sicher, Sie haben diese Informationen in den Commit aufgenommen. Aber die Dokumentation , warum eine nicht offensichtliche Codezeile existiert, ist genau das, was kommentiert werden sollte. Ich gehe davon aus, dass in diesem Fall aus dem Lesen des Codes nicht klar war, dass die Änderung etwas mit einem abstürzenden Fehler zu tun hatte. Sam hätte den Commit überprüfen sollen, um zu sehen, warum die Änderung vorgenommen wurde, aber das Einfügen eines Kommentars verhindert Missverständnisse.
Ich habe mir vorgestellt, dass Sie die Clutter-Linie // Bug 1245 von alleine kennen.

Ich denke, du überdenkst das. Teilen Sie Sam einfach mit, was Sie gefunden haben, indem Sie eine E-Mail nur an Sam(!) schreiben :

Hallo Sam, ich habe gesehen, dass du die Zeile XYZ wieder in ABC geändert hast. Das Problem ist, dass diese Zeile wahrscheinlich für einen weit schlimmeren Fehler verantwortlich ist, den ich gefunden habe, und der unter bestimmten Umständen einen Absturz verursachen kann (Details hier einfügen). Wir brauchen also etwas, um das Anzeigeproblem und diesen Fehler zu beheben. Können wir darüber reden?

Ich finde die Reaktion von Scohe001 nicht ausreichend, weil sie das eigentliche Problem nicht erwähnt .

Die normale Reaktion ist, dass Sie sich das beide ansehen und eine Lösung für beide Probleme finden. Es ist wichtig, dass Sie Sam zuerst alleine mailen, damit Sie beide das unter Ihnen beiden klären können, aber dass Sie Beweise für den seltenen Fall haben, dass Sam versucht, Sie zu ignorieren / zu sabotieren. Wenn Sie sehen, dass die Zeile unerwartete Probleme verursacht (ja, das passiert oft :/), ist es wahrscheinlich, dass Sie beide die Situation an den leitenden Entwickler eskalieren müssen (Wir haben hier ein kleines Problem ...).

Bist du sicher, dass Sam die Zeile überschrieben hat? Normalerweise haben Sie ein Versionskontrollsystem (VCS), das jede Person über Änderungen in der Codebasis informiert, und das erste, was ich tue, wenn ich Änderungen sehe, ist, den Grund in der Commit-Nachricht nachzuschlagen und wenn nicht ausreichend, den Kollegen zu fragen, was er getan hat . Die Sache ist die, wenn Sie Ihren aktuellen Zustand nicht wiederholt aktualisieren, ist es leicht anzunehmen, dass Änderungen (nicht) vorhanden sind, obwohl sie tatsächlich (nicht) vorhanden sind.

100% sicher - ich habe die Änderung gefunden, weil ich mir eine Liste seiner letzten Commits angeschaut habe. Der Commit hat buchstäblich nur diese Zeile geändert, mit einer Meldung wie "Bug: List does not show 'ABC'. Fix: Line was XYZ, change to ABC". Es behebt tatsächlich die Anzeige in der Liste, aber ich habe die neueste Version des Projekts erstellt und überprüft, dass es wie erwartet abstürzen wird.
@EmC Na dann sprichst du einfach nach der Mail mit ihm. Gut, dass Sie den Build haben, damit Sie es demonstrieren können. Wie gesagt, Sie können beide überlegen, wie beide Probleme gelöst werden können, und wenn nicht (oder wenn Sie sich über Nebenwirkungen nicht sicher sind), an die Leitung eskalieren.

Ich würde Sam eine E-Mail schicken mit etwas wie:

Hey Sam, ich habe einige Änderungen gesehen, die du kürzlich in diesem Commit vorgenommen hast (verlinke den Commit hier, wenn du kannst). Ich versuche immer noch, mich mit unserer Codebasis vertraut zu machen, und ich habe mich gefragt, ob ich mich mit Ihnen treffen könnte, um einige meiner Fragen zu besprechen.

Ich bin frei (listen Sie 2-3 Zeiten auf, in denen Sie frei sind. Wenn Sie können, schauen Sie sich seinen Kalender und die Spielzeiten an, wenn er frei ist).

Danke!

Sie haben Recht mit Ihrer Angst, am Ende mit dem Fuß in Ihrem Mund zu enden – das ist definitiv etwas, das mir bei neuen Jobs öfter passiert ist, als ich zugeben möchte. Ich habe festgestellt, dass eine einfache Möglichkeit, dies zu vermeiden, darin besteht, nach einer Erklärung zu fragen, was passiert, anstatt Anschuldigungen zu machen.

Wenn Sam seine Änderung genauso erklärt wie Sie, dann gibt Ihnen diese E-Mail eine Entschuldigung, um mit "Wird das nicht in den Grenzfällen I, J und K brechen?" unter dem Vorwand, mehr über das System zu erfahren. Und ob du richtig oder falsch liegst, ihm dabei zuzusehen, wie er es in Echtzeit durchdenkt und dir eine Antwort gibt, wird dir wahrscheinlich helfen zu lernen! Ganz zu schweigen davon, dass Sie diese Gelegenheit nutzen können, um ihn zu fragen, wie er möchte, dass Sie in Zukunft mit Ungereimtheiten umgehen, die Sie in seinen Commits finden.

Danke für die Antwort! Gibt es einen Grund, warum Sie E-Mail vorschlagen, anstatt nur persönlich zu sprechen? (Mir ist gerade klar geworden, dass es auch nicht klar ist, dass es eine Möglichkeit gibt, also ist das jetzt bearbeitet.)
@EmC Es hört sich so an, als ob Sie sich Sorgen machen, mit ihm zu sprechen, weil er eine vielbeschäftigte Person ist. Wenn Sie die „offiziellen Kanäle“ per E-Mail und Kalendereinladung durchlaufen, wenn Sie sich auf eine Zeit festgelegt haben, kann er Sie in seinen Zeitplan einarbeiten und Ihnen hoffentlich dabei helfen, weniger das Gefühl zu haben, dass Sie ihn „ärgern“. Ganz zu schweigen von einer E-Mail wie dieser, die ihm die Möglichkeit geben würde, sich den Commit anzusehen und sich an den fraglichen Code zu erinnern.
Je nach Bürokultur kann ein persönliches Treffen übertrieben sein.
Anstatt zu sagen "wird das nicht in den Grenzfällen I, J und K brechen?" (weil Sie es bereits wissen) warum sagen Sie nicht einfach, dass Sie den Code geändert haben, um XYZI, J und K zu adressieren, und fragen Sie dann, ob Ihnen etwas fehlt?

In einer angemessenen Umgebung durchlaufen alle Änderungen eine Codeüberprüfung. Wenn ich Ihre Änderung auf das Original zurückgesetzt habe, ist die Codeüberprüfung der richtige Zeitpunkt, um mich zu benachrichtigen. Das ist der Zeitpunkt, an dem Sie darauf hinweisen, warum Ihre Änderung erforderlich war (was ich möglicherweise nicht geschätzt habe).

Es gibt jedoch das Problem, dass Ihre Änderung einen Fehler behoben, aber ein Anzeigeproblem verursacht hat, das vor Ihrer Korrektur nicht bestand. Das hätte gefunden werden müssen, als Ihr Code überprüft wurde, war es aber leider nicht. Wenn Sie ein Problem beheben, sollten Sie keine anderen Probleme verursachen. Also würde ich Ihren Fehler erneut öffnen und einen Kommentar hinzufügen, dass Ihre Lösung das große Problem behoben, aber ein kleines eingeführt hat, und Sie sollten Ihre Lösung ändern, um das große Problem zu beheben, ohne ein kleineres zu verursachen.

Das OP sagt, dass er nicht weiß, wie er das Anzeigeproblem beheben soll, weshalb er mit Sam zusammenarbeiten muss.
Es scheint, dass das Anzeigeproblem ohne die Änderung von OP nicht da war. Also führte er es ein. Sam hat den Code entfernt, der einen Fehler behoben und einen anderen eingeführt hat. Wie man beide Fehler gleichzeitig behebt, ist OPs Aufgabe, nicht Sams.
Wie kann ich jemandem sagen, dass er meinen Code kaputt gemacht hat, und ihn bitten, ihn zu reparieren?
AntwortenHierDatenschutz-Bestimmungen1y, 0v