Sollte ein Programmierer den fehlgeschlagenen Build einer anderen Person reparieren? [geschlossen]

Ein Programmierer legte einige Arbeiten im SVN-Repository fest und ging dann nach Hause. Nachdem er gegangen war, schlug die automatische Erstellung des Hudson fehl. Ein anderer Programmierer sah dies und stellte nach Durchsicht der Codeänderungen fest, dass das Problem darin bestand, dass eine Bibliothek nicht vorhanden war. Er fügte diese Bibliothek zu SVN hinzu und der nächste Build wurde erfolgreich abgeschlossen.

Hat der zweite Programmierer das Richtige getan oder hätte er einfach warten sollen, bis der erste Programmierer das Problem behoben hat?

Es hängt bis zu einem gewissen Grad davon ab, wie Ihr Team normalerweise arbeitet, aber ich würde sagen, dass das in Ordnung war. Wenn Sie den Build weiterhin verwenden, sparen Sie allen anderen Zeit.

Es ist höflich, wenn der zweite Programmierer dem ersten eine E-Mail sendet, um zu erklären, was er getan hat, falls eine bestimmte Version der Bibliothek benötigt wird oder andere Komplikationen auftreten. Es ist auch eine etwas subtilere Art, darauf hinzuweisen, dass sie den Build gebrochen haben.

Es hängt davon ab, ob.

• Ist der Fehler so offensichtlich, dass Sie ihn durch Hinzufügen einer Bibliothek beheben können? Manchmal besteht die Lösung darin, eine Problemumgehung zu finden, um diese Bibliothek nicht zu benötigen.

• Befindet sich das Projekt in einer Phase, in der alle Änderungen mit einem vorhandenen Ticket verknüpft werden müssen? Wenn ja, haben Sie ein Ticket eingereicht? Wurde Ihnen dieses Ticket zugewiesen?

Wie auch immer, konzentrieren Sie sich auf die Behebung des Fehlers und nicht darauf, die Verantwortlichen dafür verantwortlich zu machen.

Ja es ist ok. Es ist jedoch unprofessionell, dass der ursprüngliche Programmierer nach Hause geht, bevor er testet, ob der Build kompiliert werden soll.

Ihr Ruf liegt zu 100% in Ihrer Hand. Solche Dinge trüben Ihren Ruf und es ist sehr schwierig, einen getrübten Ruf zu verbessern.

Kommunizieren

Für dieses Szenario gibt es keine strengen Regeln (neben Ihren eigenen Teamregeln).

Dev2 sollte in der Lage sein, dev1 mitzuteilen, dass er seinen Fehler beheben kann. Keiner von ihnen sollte das Ergebnis dieses Austauschs fürchten. Sie sind Teil eines Teams.

Warum nicht? Wenn Ihr Produkt wichtiger ist als das Beheben von Schuldzuweisungen, ist es mit Sicherheit in Ordnung. Obwohl ein Build, der aufgrund von Bibliotheksänderungen fehlschlägt, ziemlich lahm ist und Sie den Entwickler zurechtweisen müssen, weil er ihn nicht getestet hat.

Build-Fehler passieren. Wenn es wichtig ist, dass ein täglicher Build durchgeführt wird, werde ich ihn reparieren und den Entwickler, der den fehlerhaften Code eingecheckt hat, bitten, den Fix am nächsten Tag zu überprüfen und sicherzustellen, dass der Code jetzt so ist, wie er sein sollte.

Wie bereits gesagt, sollte der Typ, der das Problem behoben hat, demjenigen, der das Problem behoben hat, wahrscheinlich eine E-Mail senden und genau angeben, um welche Lösung es sich handelt.

Mein Motto ist, dass Sie nach 15 Uhr keine SVN-Verpflichtung mehr eingehen, damit Sie Ihre Build-Fehler immer selbst beheben können.

Wenn Sie den Buildfehler nicht beheben, schlägt auch der Build aller anderen fehl. Ich würde es reparieren, um auf lange Sicht Zeit zu sparen, aber stellen Sie sicher, dass sie wissen, dass Sie es reparieren mussten.

Eine Art 'Schuldzuweiser'-Skript ist eine gute Möglichkeit, dies zu tun, oder die Person, die den Build bricht, dazu zu bringen, Donuts zu kaufen !!

Jemand muss das Problem beheben, und der erste Programmierer hätte nicht nach Hause gehen dürfen, ohne vorher sicherzustellen, dass er den Build nicht beschädigt hat. Für ein so leicht zu behebendes Problem wäre es jedoch extrem, ihn zurückzurufen, um es selbst zu beheben.

Ich stimme dem Vorschlag von Luke Graham zu, eine erklärende E-Mail zu senden, obwohl ich sagen würde, dass dies mehr als höflich ist - es handelt sich um eine grundlegende Kommunikation.

Ja Ja Ja! Es fördert die kollektive Eigentümerschaft von Code und setzt die Kollegen unter Druck, einen hohen Standard beizubehalten und die Entwicklung eines Szenarios mit zerbrochenen Fenstern zu verhindern. Ein bisschen Kommunikation, um den anderen Entwickler zu informieren, ist eine gute Idee.

Ich denke, es ist in Ordnung, offensichtliche Dinge zu korrigieren - dh wenn Sie zu 100% sicher sind, dass der Typ, dessen Code Sie korrigieren, die gleiche - oder im Wesentlichen die gleiche - Korrektur durchführen würde. Wenn die Korrektur komplexer ist, ist es normalerweise höflich, mit der Person zu sprechen, deren Code Sie korrigieren. Möglicherweise haben Sie die Absicht oder den Grund für den Bruch falsch verstanden aber aus irgendeinem Grund konnte ich es noch nicht begehen (das Leben passiert, weißt du :).

Im Allgemeinen lautet die Regel in der Regel: Sie brechen den Build ab - Sie reparieren den Build, aber es gibt Ausnahmen, insbesondere wenn der Fix offensichtlich ist und / oder die verantwortliche Person nicht erreichbar ist.

Wenn es sich um einen Serien-Build-Breaker handelt - insbesondere mit dem Muster "Eingecheckt, nach Hause gegangen, Build tagelang gebrochen" - muss die verantwortliche Person natürlich darüber sprechen, warum CI-Systeme und -Tests existieren und wie sie funktionieren sollen check vor dem einchecken :)

Dinge passieren. Das Fehlschlagen des Hinzufügens einer neuen Codedatei (ob Quelle oder kompiliert) zu Subversion ist wahrscheinlich die häufigste Ursache für fehlerhafte Builds, vorausgesetzt, sie funktionierte auf dem Computer des Entwicklers. Bei meinem letzten Job in einem CI-Umfeld vergaßen sogar die erfahrensten Leute manchmal.

Ich denke, wenn eine andere Person in der Lage war, den Build zu reparieren und so das Team am Laufen zu halten, ist das in Ordnung. Ich denke, der Programmierer, der nach Hause gegangen ist, braucht zumindest eine freundliche E-Mail, die angibt, was passiert ist, und um ihn daran zu erinnern, dass vor dem Festschreiben neuer Code hinzugefügt wird. Wenn es öfter vorkommt, machen Sie das vielleicht zu einer geringfügigen Straftat, die mit dem "Tanz der Schande" geahndet wird, um das Auftreten zu reduzieren (und die Stimmung zu verbessern).

Es hängt von der Teamdynamik ab, aber in einer idealen Welt würde jeder im Team das gesamte Projekt, den gesamten Code und folglich alle Fehler gemeinsam "besitzen". Wenn Sie also ein Problem finden, können Sie es beheben und nur dann mit dem Urheber des Fehlers kommunizieren, wenn der Code einen bestimmten Mehrwert bietet.

Es ist in Ordnung, das Problem zu beheben, es sei denn, dies ist ein normaler Vorgang. In diesem Fall würde ich den Chef bitten, ihn anzurufen und ihn zurückkehren zu lassen und es selbst zu beheben.

Es kommt darauf an, es kommt darauf an ...

Als Programmierer besteht unsere Arbeit darin, Dinge zum Laufen zu bringen und nicht Menschen zu beurteilen. Das Beste, was Sie tun können, ist, das Problem zu beheben. Wenn dies nicht offensichtlich ist, setzen Sie einfach die Änderungen zurück und lassen Sie den ersten Programmierer wissen, damit er es später beheben kann.

Jedenfalls ist es genug, den neuesten Mann zu haben, der den Build gebrochen hat, um einen seltsamen Hut zu tragen, um das nächste Mal mehr Aufmerksamkeit zu schenken ^ _ ^

In einigen Umgebungen ist dies aus guten Gründen sehr unhöflich. In anderen Umgebungen wird dies aus guten Gründen erwartet.

In noch anderen Umgebungen ist es aus sehr schlechten Gründen sehr unhöflich oder zu erwarten.

Es hängt weitgehend davon ab, wie kritisch ein fehlerhafter Build im Vergleich zu einem überprüften korrekten Build ist. Und bis zu einem gewissen Grad hängt es davon ab, wie offensichtlich es war, dass der Fix der richtige und der einzige war, der benötigt wurde.

Erstens ist "nach Hause gegangen" ein Anachronismus. Programmierer gehen nicht mehr nach Hause - sie sind entweder online oder offline. Sie könnten pingen und warten.

Im Ernst, die Frage besteht eigentlich aus zwei Teilen. 'die Codeänderungen durchsehen' ist in Ordnung; Ruhe ist möglicherweise nicht das Richtige. Was, wenn seine Einschätzung einer fehlenden Bibliothek falsch war?