it-swarm.dev

Wie Sie sich entschuldigen können, wenn Sie den nächtlichen Build gebrochen haben

Mein erstes Engagement in meinem Projekt führte dazu, dass der nächtliche Build unterbrochen wurde und die Leute überall auf mir sind, als wir uns der Veröffentlichung nähern. Ich möchte eine Entschuldigungs-E-Mail senden, die aufrichtig klingen sollte und gleichzeitig darauf hinweist, dass dies mein erstes Commit war und dies nicht mehr wiederholt werden würde.

Als nicht englischer Muttersprachler habe ich Schwierigkeiten, die richtigen Wörter zu finden. Kann mir bitte jemand helfen?

185
rajachan

Entschuldige dich nicht !

  • Den Build einmal in einem blauen Mond zu brechen ist keine große Sache und sollte niemals ein Show-Stopper sein.
  • Es ist die Schuld Ihres Managers, keine kontinuierlichen, automatisierten Builds zu konfigurieren.

Ich wette auch, dass Ihr Team den 'Joel Test' nicht besteht und nicht in einem Schritt einen Build erstellen kann.

Wenn ja, wäre dies eine andere Sache, für die Sie sich nicht entschuldigen sollten. In der Tat ist es ein Team-Anti-Pattern.

307
Jim G.

Bagels. Donuts. In einem Unternehmen, für das ich in der Vergangenheit gearbeitet habe, wird das Einchecken von fehlerhaftem Code oder die sonstige Störung von Kollegen im Allgemeinen durch das Einbringen von entschuldigenden Lebensmitteln am nächsten Tag behoben.

Wir hatten eines Tages einen Typen, der eine Produktionsdatenbank wegblies, was massive Panik und eine späte Nacht für das gesamte Team verursachte. Am nächsten Tag grillte er Burger zum Mittagessen.

Ich liebe Entschuldigungen von Kollegen. Leckere, leckere Entschuldigungen.

182
Dan Ray

Zwei Zitate für Sie:

Der Mann, der keine Fehler macht, macht normalerweise nichts. - William Connor Magee

Wer keine Fehler macht, ist nicht hart genug. - Wess Roberts

Ich stimme zu Jim G. , entschuldige dich nicht, aber lerne daraus und mache nicht noch einmal den gleichen Fehler ... behalte es DRY;)

80
Lazarus

Entschuldigen Sie sich nicht, reparieren Sie es einfach so schnell wie möglich. Es ist aber okay, jeder bricht den Build mindestens einmal, in meiner letzten Firma war es so etwas wie ein Initiationsritual. Wenn ein Teammitglied den Build brach, legten wir am Morgen vor seiner Ankunft ein Gummiente auf seinen Schreibtisch. Dies ließ ihn wissen, dass er den Build gebrochen hatte und er würde ihn reparieren.

Wir nannten es das Continuous Integration Duckie und wenn Sie es für den Tag hatten, würden die Leute Sie ärgern, aber es machte alles Spaß, nichts davon sollte gemein sein.

Wir haben so etwas wie einen kaputten Build genommen und daraus eine Teambuilding-Übung gemacht.

53
maple_shaft

"Es tut mir leid!" So entschuldige ich mich normalerweise, wenn ich den Build gebrochen habe. Es passiert. Aber wie andere gesagt haben, ist dies eine Gelegenheit, Ihre Systeme so zu verbessern, dass eine Person den Build nicht so einfach für alle anderen brechen kann.

Ich würde mich unter diesen Umständen nicht formell entschuldigen, aber wenn Sie tatsächlich der Meinung sind, dass eine formellere Entschuldigung angemessen ist, sollte Ihre Entschuldigung folgende Dinge tun:

  • Bedauern Sie es ausdrücklich.
  • Geben Sie das Problem an.
  • Verantwortung übernehmen.
  • Wiedergutmachung leisten.
  • Gesicht speichern.

Das heißt: "Es tut mir leid [EXPRESS REGRET], dass ich Sie [VERANTWORTUNG ÜBERNEHMEN] dadurch belästigt habe, dass ich versehentlich [SAVE FACE] den Build gebrochen habe [STATE THE PROBLEM]. Donuts sind morgen bei mir. [MAKE AMENDS]"

Jeder Teil ist in einer angemessenen Entschuldigung notwendig; Wenn Sie das Problem nicht angeben, ist es unklar. Wenn Sie kein Bedauern ausdrücken, Verantwortung übernehmen und Wiedergutmachung leisten, fühlen sich die Leute unaufrichtig. Der Gesicht rettende Teil ist der am meisten übersehene Teil einer Entschuldigung; Der Gesicht rettende Teil erinnert den Verletzten daran, dass Sie ein wertvoller Mitarbeiter sind, der manchmal Fehler macht, und kein Idiot (oder Saboteur!).

Zum Schluss noch ein paar Gedanken zum Brechen von Builds:

Ich arbeite im C #/Visual Basic-Compilerteam. Natürlich ist Visual Studio heute ein so umfangreiches Projekt, dass es ein eigenes Team hat, das nur für die Verwaltung der Bauinfrastruktur zuständig ist, und einen riesigen Raum mit einer eigenen Klimaanlage. Mitte der neunziger Jahre, als ich als Praktikant anfing, war das Visual Basic-Build-Team ein Praktikant - ich - und ein Schrank voller Maschinen. Die Zeiten haben sich geändert!

In jenen Tagen vor der kontinuierlichen Integration und starken Check-in-Prozessen hatten Teams eine Reihe von Strafen für das Brechen des Builds. Bei einigen Teams war die Strafe, dass man jeden Tag bei der Arbeit einen lustigen Hut tragen musste, wenn man den Build brach, bis jemand anderes den Build brach. Wenn Sie in einigen Teams diesen Hut trugen, waren Sie dafür verantwortlich, zu überprüfen, ob der nächtliche Build korrekt war.

Das letzte bisschen klingt vielleicht grausam, aber es hat tatsächlich einen wertvollen Zweck erfüllt. Da fast jeder den Build zu der einen oder anderen Zeit brach, lernte schließlich das gesamte Team die Prozesse zur Überprüfung des nächtlichen Builds.

43
Eric Lippert

Entschuldige dich nicht. Es sind Ihre Mitarbeiter, die dafür verantwortlich sind, dass Sie Ihr erstes Commit nicht überprüft haben und kein schnelles Feedback-System für Builds wie einen Continuous Integration Server haben.

Bei meinem derzeitigen Job haben wir die informelle Regel, dass jemand, der sich kurz vor dem Verlassen der Arbeit heimlich verpflichtet und den Bau bricht, am nächsten Tag Süßigkeiten/Kuchen/Getränke für das gesamte Team mitbringen muss. Aber wir haben eine kontinuierliche Integration, die uns tagsüber vor einem kaputten Build warnt. Und die Regel würde wahrscheinlich nicht für das erste Commit einer Person gelten.

Wie auch immer, eine formelle Entschuldigungspost ist wahrscheinlich etwas zu viel.

15
guillaume31

Eine grundlegende Regel - wenn Sie falsch liegen, ADMIT IT: - | Sie müssen sich nicht entschuldigen. Jeder macht Fehler. Die Profis geben es zu. Das ist Teamwork. Die anderen Teammitglieder sollten sich zusammenreißen, um Ihnen dabei zu helfen. Wenn nicht, bitten Sie um Hilfe. Das meiste, was danach gesagt werden muss, ist - was können wir daraus lernen?

Sie sagen, dass eine erfolgreiche Ehe auf drei kleinen Worten basiert - "Ich habe mich geirrt".

Wenn jemand nicht gelegentlich einen Fehler macht, arbeitet er nicht, aber ein Fehler, aus dem man nicht lernt, sind zwei Fehler.

11
Mike Dunlavey

Die beste Entschuldigung ist, die Pause schnell zu beheben

6
JaredPar

Wenn Ihr Unternehmen bereits die Möglichkeit hat, Ihre Build-Änderungen zu testen, sind (A) Ihre Änderungen entweder fehlgeschlagen (aber Sie haben sie trotzdem eingecheckt) oder (B) sie waren erfolgreich (und Sie müssen einen neuen Testfall erstellen).

Wenn Ihre Kollegen ihre Änderungen vorsichtig testen und erwarten, dass beim nächtlichen Build Unterbrechungen auftreten, (C) haben Sie einen spröden Prozess (und Sie müssen Tests wie die in Extreme Programming beschriebenen einführen).

Es ist möglich, dass (D) Ihre Änderungen unvorhergesehene Änderungen in Bills Code verursacht haben, die entweder zuvor vorhanden waren oder im selben Build wie Ihre geändert wurden.

Abhängig davon, wie Sie und Ihr Unternehmenstest durchgeführt haben, würde ich mich von Fall zu Fall entschuldigen:

  • (A) Ich habe den Build-Test nicht bestanden, aber meine Änderungen eingecheckt. Entschuldigung, ich ändere meinen Prozess, damit ich ihn nicht noch einmal mache.
  • (B) Ich habe den Build-Test bestanden und den JUnit-Test XYZtest.Java hinzugefügt, um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern.
  • (C) Da wir keinen Build-Testprozess haben, erstelle ich einen für meine Änderungen. Ich möchte Ihnen mitteilen, wie wir unseren Erstellungsprozess verbessern können.
  • (D) Ich werde mit Bill zusammenarbeiten, um einen JUnit-Test XYZtest.Java zu schreiben, um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern.

Ich bin sicher, es gibt ein (E), an das ich nicht gedacht habe.

Beachten Sie, dass ich sage "um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern" und nicht "damit es nicht wieder vorkommt". Es wird wieder passieren. Sie können jedoch Ihren Prozess verbessern, um diese Möglichkeit zu verringern. Ich denke, das ist eines der Kennzeichen eines erfolgreichen Programmierers.

5
rajah9

Äh. Sie erhalten das defektes Build-Token . Geben Sie die Tollwut an den nächsten glücklichen Empfänger weiter. Es passiert die ganze Zeit. Qualität ist wichtig, aber Fehler sind unvermeidlich. Repariere sie. Mach weiter. Schade um den nächsten armen Kerl.

2
M. Tibbits

Entschuldige dich nicht. Du bist ein Mensch und wirst Fehler machen. Jeder wird den Build gelegentlich brechen, der Schlüssel ist, ihn einfach schnell zu reparieren.

Was die Leute betrifft, die über dich springen ... nun, ich bin gespannt, ob sie jemals einen Fehler geschrieben haben.

2
Corv1nus

Wie Sie dies angehen, hängt von der Atmosphäre in Ihrer Gruppe ab. Wenn es eine Schuldkultur ist, würde ich sehr vorsichtig sein, wenn ich mich entschuldige und wie du es machst. Wenn es eine kollaborative, positive Atmosphäre ist, dann ja, etwas in der Art von "Ich habe es vermasselt, es tut mir leid. Wie können wir dies in Zukunft vermeiden?" ist wahrscheinlich eine gute Idee.

In jedem Fall sollte ein solcher Fehler von einer Art Obduktion begleitet werden, um a) herauszufinden, wie es passiert ist und b) wie die Wahrscheinlichkeit minimiert werden kann, dass es erneut passiert.

Ich bin mit Ihrer Struktur nicht vertraut (ich arbeite in einer ganz anderen Umgebung), aber letztendlich ist die Realität, dass gelegentlich Menschen Fehler machen und Dinge kaputt gehen. Sie lernen aus der Erfahrung und gehen weiter.

2
temptar

In meiner Umgebung würden Sie, wenn Sie den Build brechen würden, eine gutmütige Rippung und einen witzigen Kometen bekommen. Ich bin mir nicht sicher, in welchem ​​englischsprachigen Land Sie sich befinden, aber es kann sein, dass Sie als nicht englischer Muttersprachler nicht die Unterstreichung der Kommentare verstehen.

Als Senior-Entwickler von der anderen Seite habe ich einmal eine Code-Überprüfung kommentiert, dass eine Art, x zu tun, nicht "saugte", weil der Code schlecht war, sondern sich auf die Struktur des Projekts auswirkte. Es war mehr Kommentar für mich, dass ich das strukturelle Problem beheben muss. Erst später stellte ich fest, dass der Jr Dev, obwohl ich wegen meiner ungenauen, leichtfertigen Rede sehr wütend auf ihn war.

2
rerun

In der Regel würde ich sagen :

Wenn Ihr Einchecken einen Compilerfehler verursacht, den Sie sich selbst abgefangen hätten, wenn Sie vor dem Einchecken ein "Get Recent" durchgeführt hätten, ist ein einfaches "Whoops, my Bad" angebracht. (vor allem, wenn Sie am nächsten Morgen um 10 Uhr hereinspazieren, während alle entscheiden, auf welches Änderungsset zurückgesetzt werden soll)

Wenn Ihr Check-in allgemeines unerwartetes Verhalten verursacht, sogar Laufzeitfehler, sollte es meiner Meinung nach nicht gegen Sie gerichtet werden. Es kommt mit dem Territorium. Solange jeder "Get Recent" im Allgemeinen an seinen Compilern vorbeikommt, sollten die Leute wirklich keinen Fit werfen (mit ein paar Ausnahmen wie Löschen einer Datenbank, Löschen der Serverkopie des Projekts und aller Änderungssätze oder irgendetwas anderes, das so dumm ist, dass die Leute böswillige Absichten annehmen müssen).

1

Das TEAM ist fehlgeschlagen.

Ihr Unternehmen benötigt mehr Codeüberprüfung für einen Entwickler, der zum ersten Mal erstellt.

Ich sehe nur nicht ein, wie ein Team dies zulässt, ohne dass es eine Überprüfung durchführt und einige Zusicherungen auf dem Weg gibt, dass Sie die Dinge richtig machen.

Kurz vor der Veröffentlichung ist keine Entschuldigung, sondern ein besserer Grund, neuen Code zu überprüfen.

Wenn Ihre Veröffentlichung nicht einfach rückgängig gemacht werden kann, gibt es noch größere Probleme mit dieser Gruppe.

1
JeffO

Besser eine späte Antwort als nie ...

Wie viele andere gesagt haben, entschuldigen Sie sich nicht dafür, dass Sie den Build gebrochen haben. Gib einfach zu, dass du es warst und mache mit dem Job weiter. Dieses Zeug würde passieren, ob Sie dort waren oder nicht, und niemand verdient es, deswegen schlecht behandelt zu werden. Die Menschen reagieren unter Druck schlecht. Wenn Sie also in der Lage sind, ruhig zu bleiben und einfach mit der Arbeit fortzufahren, werden Sie auffallen, wenn es darauf ankommt. Mein Rat, wenn die Leute es Ihnen schwer machen, ist, einfach zu vermeiden, defensiv zu sein, die Situation zu entschärfen, indem Sie die Leute wissen lassen, dass Sie entweder mit dem Problem befasst sind, oder Sie schnell Rat einholen, wenn Sie feststellen, dass Sie nicht weiterkommen.

Persönlich sehe ich einen kaputten Build als Chance.

  • Wenn der Build unterbrochen wird und Sie beweisen können, dass es Ihre Schuld ist, zeigt dies wahrscheinlich, dass die kontinuierlichen Integrations- und Buildprozesse ihre Arbeit erledigen. Dies ist eine gute Sache, da es Ihre Prozesse validiert. Wenn der Build nie kaputt geht, würde ich mir Sorgen machen, dass etwas nicht stimmt.
  • Wenn Sie den Build auf eine ziemlich häufige Art und Weise beschädigt haben und dieser häufig auf diese Weise unterbrochen wird, fehlt möglicherweise etwas im CI-Prozess. Dies ist eine Gelegenheit, Ihre Prozesse zu verbessern, damit die gängigen Fehlerszenarien besser verwaltet werden können.
  • Wenn Sie über die Pflicht hinausgegangen sind und den Build wirklich mit einem obskuren Problem durcheinander gebracht haben, haben Sie die Möglichkeit, etwas Neues zu erfahren, das wichtig genug sein könnte, um eine Warnung an den Rest des Teams auszulösen.

Ich sage also, dass das gelegentliche Brechen des Builds bedeutet, dass die Leute ihre Arbeit machen. Sicher, Sie haben vielleicht einen Fehler gemacht, aber wenn Sie ihn als Gelegenheit zum Lernen nutzen, erledigen Sie Ihre Arbeit einfach, indem Sie lernen, es beim nächsten Mal besser zu machen.

0
S.Robins

Ich verstehe nicht, warum die Leute überall auf dir sind. Wenn das System gut eingerichtet ist, sollten sie in der Lage sein, Ihre Änderungen zu überprüfen/sehr schnell zu beheben.

Aber nochmal, wenn Sie einer von denen sind, die Fenster gebaut haben, dann ... kann ich nicht anders. (Übrigens ist es unglaublich schwierig, dies zu tun - bevor jemand Fragen zur MS-Philosophie stellt, aber ab und zu macht es jemand - und die gesamte Qualitätssicherung des Unternehmens stoppt für einen Tag).

Und ja - entschuldige dich nicht. Sprechen Sie einfach mit Ihrem Manager und machen Sie ihm klar, dass Sie aus dem, was Sie getan haben, gelernt haben.

Builds brechen die ganze Zeit. Bugs und Fehler sind eine Tatsache des Lebens, und deshalb sollten Sie einen Prozess haben, der die Auswirkungen von Bugs und Fehlern minimiert.

Wenn ein Build-Breaking eine so große Sache ist, bedeutet dies, dass Ihr Prozess unterbrochen ist.

Sie sollten kontinuierliche Builds durchführen, keine nächtlichen Builds.