Jak przeprosić, gdy złamałeś nocną wersję [zamkniętą]

Moje pierwsze zatwierdzenie w moim projekcie spowodowało zepsucie nocnej kompilacji i ludzie są wokół mnie, gdy zbliżamy się do wydania. Chcę wysłać wiadomość e-mail z przeprosinami, która powinna brzmieć szczerze, a jednocześnie sugeruje, że to był mój pierwszy zatwierdzenie i że nie będzie już więcej powtarzane.

Ponieważ nie jestem rodzimym językiem angielskim, mam trudności z wymyśleniem poprawnych słów. Czy ktoś może pomóc?

Nie przepraszaj!

• Przełamanie kompilacji raz na niebieskim księżycu nie jest wielką sprawą i nigdy nie powinno być przeszkodą.
• To wina menedżera, że ​​nie konfigurował ciągłych, automatycznych kompilacji.

Założę się również, że twoja drużyna nie zdała testu Joela i nie może wykonać kompilacji w jednym kroku.

Jeśli tak, to kolejna rzecz, za którą nie powinieneś przepraszać. Rzeczywiście, jest to anty-wzór zespołu.

Bajgle Pączki Itd. W jednej firmie, w której pracowałem w przeszłości, sprawdzanie zepsutego kodu lub powodowanie zakłóceń w pracy kolegi zazwyczaj jest rozwiązywane przez przyniesienie przeprosin następnego dnia.

Pewnego dnia facet zdmuchnął bazę danych produkcji, powodując ogromną panikę i późną noc dla całego zespołu. Następnego dnia zjadł hamburgery na lunch.

Uwielbiam przeprosiny współpracowników. Smaczne, smaczne przeprosiny.

Dwa cytaty dla Ciebie:

Człowiek, który nie popełnia błędów, zwykle nic nie robi. - William Connor Magee

Każdy, kto nie popełnia błędów, nie stara się wystarczająco mocno. - Wess Roberts

Zgadzam się z Jimem G. , nie przepraszaj, ale ucz się na tym i nie popełniaj tego samego błędu ponownie ... zachowaj SUCHOŚĆ;)

Nie przepraszaj, po prostu USUŃ to tak szybko, jak to możliwe. Jest w porządku, wszyscy przynajmniej raz przerywają kompilację, w mojej ostatniej firmie było to coś w rodzaju rytuału inicjacyjnego. Kiedy członek zespołu złamał kompilację, kładliśmy gumowe kaczuszki na jego biurku rano, zanim on wszedł, to dało mu do zrozumienia, że ​​złamał kompilację i naprawi ją.

Nazywaliśmy to Duckie Continuous Integration, a kiedy miałeś go na dzień, kiedy ludzie cię droczyli, ale było wesoło, żadne z nich nie miało być złośliwe.

Wzięliśmy coś w rodzaju zepsutej kompilacji i przekształciliśmy w ćwiczenie budowania zespołu.

"Przepraszam moja wina!" tak zwykle przepraszam, gdy zepsułem kompilację. Zdarza się. Ale jak powiedzieli inni, jest to okazja do ulepszenia systemów, aby jedna osoba nie mogła tak łatwo przerwać kompilacji dla wszystkich innych.

W tych okolicznościach nie składałbym formalnych przeprosin, ale jeśli faktycznie uważasz, że bardziej formalne przeprosiny są odpowiednie, przeprosiny powinny wykonać następujące czynności:

• Wyraź żal.
• Podaj problem.
• Brać odpowiedzialność.
• Zrekompensować.
• Chroń twarz.

To znaczy: „Przykro mi [EXPRESS REGRET], że sprawiłem ci niedogodność [PODEJMUJ ODPOWIEDZIALNOŚĆ] przez przypadkowe [SAVE FACE] złamanie kompilacji [STATE THE PROBLEM]. Pączki są jutro na mnie. [POWIEDZIEĆ]”

Każda część jest niezbędna w odpowiednich przeprosinach; jeśli nie podasz problemu, to nie jest jasne. Jeśli nie wyrażasz żalu, nie bierzesz odpowiedzialności i nie zarabiasz, ludzie czują się, jakbyś był nieszczery. Część ratująca twarz jest najczęściej pomijaną częścią przeprosin; część oszczędzająca twarz przypomina poszkodowanemu, że jesteś cennym współpracownikiem, który czasem popełnia błędy, a nie idiotą (lub sabotażystą!)

Na koniec kilka przemyśleń na temat łamania kompilacji:

Pracuję w zespole kompilatorów C # / Visual Basic. Oczywiście dziś Visual Studio jest teraz tak ogromnym projektem, że ma własny zespół do zarządzania infrastrukturą i ogromną salę z własnym systemem klimatyzacji. W połowie lat 90., kiedy zaczynałem jako stażysta, zespół budujący Visual Basic był jednym stażystą - mną - i szafą pełną maszyn. Czasy się zmieniły!

W tamtych czasach przed ciągłą integracją i silnymi procesami meldowania zespoły miały różne kary za złamanie kompilacji. W niektórych zespołach karą było to, że jeśli złamałeś kompilację, musiałeś codziennie nosić zabawny kapelusz, dopóki ktoś inny nie złamał kompilacji. W niektórych zespołach, jeśli nosiłeś ten kapelusz, odpowiadałeś za sprawdzenie, czy wersja nocna była poprawna.

Ten ostatni kawałek może być okrutny, ale w rzeczywistości służył cennemu celowi. Ponieważ prawie wszyscy złamali kompilację w tym czy innym czasie, w końcu cały zespół poznałby procedury weryfikacji kompilacji nocnej.

Nie przepraszaj To twoi współpracownicy są winni za to, że nie sprawdzili twojego pierwszego zatwierdzenia i nie mieli systemu szybkiego sprzężenia zwrotnego dla kompilacji takich jak serwer ciągłej integracji.

W mojej obecnej pracy obowiązuje nieformalna zasada, że ​​ktoś, kto podstępnie popełnia tuż przed wyjściem z pracy i okazuje się, że chce przerwać kompilację, musi przynieść cukierki / ciastka / napoje całemu zespołowi następnego dnia. Ale mamy ciągłą integrację, która ostrzega nas o zepsutej kompilacji w ciągu dnia. I reguła prawdopodobnie nie miałaby zastosowania do pierwszego zatwierdzenia.

W każdym razie formalna poczta z przeprosinami to prawdopodobnie trochę za dużo.

Podstawowa zasada - kiedy się mylisz, ZGADŹ SIĘ: - | Nie musisz żałować przeprosin. Wszyscy popełniają błędy. Profesjonaliści to przyznają. To praca zespołowa. Pozostali członkowie zespołu powinni się zjednoczyć, aby ci pomóc. Jeśli nie, ZAPYTAJ o pomoc. Najważniejsze, co należy potem powiedzieć, to - czego możemy się z tego nauczyć?

Mówią, że udane małżeństwo opiera się na trzech małych słowach - „Myliłem się”.

Jeśli ktoś nie popełnia sporadycznego błędu, nie działa, ale błąd, z którego się nie uczy, to dwa błędy.

Najlepsze przeprosiny to szybkie naprawienie przerwy

Jeśli Twoja firma ma już sposób przetestować zmiany kompilacji, to (A) zmiany albo nie powiodły się (ale i tak je sprawdziłeś), albo (B) powiodły się (i musisz zbudować nowy przypadek testowy).

Jeśli twoi koledzy ostrożnie przetestują swoje zmiany i spodziewają się znaleźć przerwy w kompilacji nocnej, to (C) masz kruchy proces (i musisz wprowadzić testy podobne do tych, które można znaleźć w Extreme Programming).

Możliwe, że (D) Twoje zmiany spowodowały nieprzewidziane zmiany w kodzie Billa, które były albo wcześniej wprowadzone, albo zmienione na tej samej kompilacji co Twoja.

W zależności od tego, jak Ty i Twoja firma przeprowadzacie testy, przepraszam za każdym razem:

• (A) Nie zdałem testu kompilacji, ale sprawdziłem zmiany. Przepraszam, zmieniam proces, więc nie będę tego więcej robić.
• (B) Zdałem test kompilacji i dodałem test JUnit XYZtest.java, aby zmniejszyć ryzyko ponownego wystąpienia.
• (C) Ponieważ nie mamy procesu testowania kompilacji, tworzę go dla moich zmian. Chciałbym się z Tobą podzielić, w jaki sposób możemy ulepszyć nasz proces kompilacji.
• (D) Będę współpracować z Billem, aby napisać test JUnit XYZtest.java, aby zmniejszyć ryzyko ponownego wystąpienia.

Jestem pewien, że istnieje (E), o którym nie myślałem.

Zauważ, że mówię „w celu zmniejszenia szansy ponownego wystąpienia”, a nie „aby to się więcej nie powtórzyło”. To się powtórzy. Ale możesz ulepszyć swój proces, aby zmniejszyć tę możliwość. Myślę, że to jeden ze znaków zwycięskiego programisty.

Nie przepraszaj Jesteś człowiekiem i popełniasz błędy. Wszyscy od czasu do czasu przerywają kompilację, kluczem jest szybkie naprawienie.

Jeśli chodzi o ludzi skaczących po tobie ... jestem ciekawy, czy kiedykolwiek napisali błąd.

Sposób podejścia zależy od atmosfery w twojej grupie. Jeśli jest to wina obwiniana, byłbym bardzo ostrożny w przepraszaniu i jak to robisz. Jeśli jest to pozytywna atmosfera współpracy, to tak, coś w stylu „Zepsułem, przepraszam. Jak możemy tego uniknąć w przyszłości?” jest prawdopodobnie dobrym pomysłem.

W każdym razie takiemu głupkowi powinien towarzyszyć jakaś sekcja zwłok, aby a) dowiedzieć się, jak to się stało i b) jak zminimalizować szanse, że to się powtórzy.

Nie znam twojej struktury (pracuję w zupełnie innym środowisku), ale ostatecznie rzeczywistość jest taka, że ​​czasami ludzie popełniają błędy i rzeczy się psują. Uczysz się na podstawie tego doświadczenia i kontynuujesz.

W moim środowisku, jeśli złamiesz kompilację, dostaniesz dobre, naturalne żebrowanie i dowcipny kometar. Nie jestem pewien, w którym kraju anglojęzycznym jesteś, ale może się zdarzyć, że jako nie mówiący po angielsku nie dostaniesz podkreślającego charakteru komentarzy.

Będąc z drugiej strony jako starszy programista, kiedyś skomentowałem recenzję kodu, że jakiś sposób robienia x „jest do bani” nie dlatego, że kod był zły, ale do struktury projektu. To był bardziej komentarz do mnie, że muszę rozwiązać problem strukturalny. Dopiero później odkryłem, że Jr Dev był bardzo zły na niego z powodu mojej niedokładnej, nonszalanckiej mowy.

Um. Dostajesz zepsuty żeton kompilacji . Przekaż wściekliznę następnemu szczęśliwemu odbiorcy. Dzieje się cały czas. Jakość jest ważna, ale błędy są nieuniknione. Napraw je. Pójść dalej. Wstyd kolejny biedny facet.

Zasadniczo powiedziałbym:

Jeśli Twoje zgłoszenie powoduje błąd kompilatora, złapałbyś się, gdybyś zrobił „dostać najnowszą” przed zalogowaniem, proste „ups, mój zły” jest w porządku. (szczególnie, jeśli następnego ranka wejdziesz o 10, a wszyscy decydują, do którego zestawu zmian należy przywrócić)

Jeśli Twoje zgłoszenie powoduje ogólne nieoczekiwane zachowanie, a nawet błędy w czasie wykonywania, nie sądzę, że powinno się to obciążyć. Przychodzi razem z terytorium. Tak długo, jak wszyscy „zdobywają najnowsze” zwykle przechodzą kompilatory, ludzie naprawdę nie powinni rzucać napadu (z kilkoma wyjątkami, takimi jak usunięcie bazy danych, usunięcie kopii serwera projektu i wszystkich zestawów zmian lub cokolwiek innego, co jest tak głupi, że ludzie muszą przyjmować złośliwe zamiary).

ZESPÓŁ nie powiódł się.

Twoja firma potrzebuje więcej recenzji kodu dla programisty wykonującego kompilację po raz pierwszy.

Po prostu nie rozumiem, w jaki sposób zespół pozwala, aby to trwało bez dokonywania przeglądu i oferowania pewnych gwarancji, że postępujesz właściwie.

Zbliżanie się do czasu wydania nie jest usprawiedliwieniem, ale lepszym powodem do dwukrotnego sprawdzenia nowego kodu.

Jeśli wydania nie da się łatwo cofnąć, z tą grupą są jeszcze większe problemy.

Nie rozumiem, dlaczego ludzie są wokół ciebie. Jeśli system jest dobrze skonfigurowany, powinien być w stanie dokuczać twoim zmianom / naprawić je bardzo szybko.

Ale znowu, jeśli jesteś jednym z tych facetów, którzy złamali system Windows, to ... Nie mogę pomóc. (Jest to niezwykle trudne do zrobienia btw - zanim ktokolwiek zadaje pytania, stwardnienie rozsiane buduje filozofie, ale od czasu do czasu ktoś to robi - i cała kontrola jakości firmy zatrzymuje się na jeden dzień).

I tak - nie przepraszaj. Po prostu porozmawiaj z menedżerem i daj mu do zrozumienia, że ​​nauczyłeś się z tego, co zrobiłeś.

Kompilacje cały czas się psują. Błędy i pomyłki są faktem i dlatego powinieneś mieć proces minimalizujący skutki błędów i pomyłek.

Jeśli łamanie kompilacji jest tak duże, oznacza to, że proces jest zepsuty.

Powinieneś robić ciągłe kompilacje, a nie kompilacje nocne.

Lepsza późna odpowiedź niż nigdy ...

Jak wielu innych powiedziało, nie przepraszaj za złamanie kompilacji. Po prostu przyznaj, że to byłeś ty i zacznij pracę. Te rzeczy miałyby miejsce bez względu na to, czy tam byłeś, czy nie, i nikt nie zasługuje na to, aby być źle traktowanym z tego powodu. Ludzie źle reagują na presję, więc jeśli jesteś w stanie zachować spokój i po prostu kontynuować pracę, wyróżnisz się, gdy ma to znaczenie. Moja rada, gdy ludzie mają trudności, to po prostu unikanie obrony, rozbrajanie sytuacji poprzez informowanie ludzi, że masz problem lub szybko szukać porady, jeśli utkniesz.

Osobiście widzę zepsutą wersję jako szansę.

• Jeśli kompilacja się zepsuje i udowodnisz, że to twoja wina, prawdopodobnie pokaże, że ciągłe procesy integracji i kompilacji wykonują swoje zadania. To dobra rzecz, ponieważ potwierdza twoje procesy. Jeśli kompilacja nigdy się nie psuje, martwię się, że coś jest z nią nie tak.
• Jeśli złamałeś kompilację w dość powszechny sposób i zdarza się, że często tak się psuje, być może w procesie CI brakuje czegoś. Jest to okazja do usprawnienia procesów, aby lepiej zarządzać typowymi scenariuszami awarii.
• Jeśli wykroczyłeś poza wezwanie do służby i naprawdę zepsułeś wersję z niejasnym problemem, masz okazję dowiedzieć się o czymś nowym, co może być wystarczająco ważne, aby wywołać ostrzeżenie dla reszty zespołu.

Mówię więc, że od czasu do czasu przerwanie kompilacji oznacza, że ​​ludzie wykonują swoją pracę. Pewnie popełniłeś błąd, ale jeśli wykorzystasz go jako okazję do nauki, wykonujesz swoją pracę po prostu ucząc się robić to lepiej następnym razem.

Powiedz im, że potrzebują kompilacji CI przy odprawie. W ten sposób nie będziesz musiał czekać do wieczora, aby wiedzieć, że jest zepsuty. TAK!!! Powiedz im, że to proces jest zły, nic więcej. Właśnie zidentyfikowałeś lukę w ich systemie.

Ale tak, upewnij się, że to naprawisz. Żaden problem. Nie jest w produkcji. Po prostu bezwartościowa nocna.

Zwykłą praktyką w mojej firmie jest:

• Krzycząc „to nie byłem ja!” (zwykle dowody CVS / SVN w innym przypadku)
• W koszulce z napisem „my-userlogin ist Schuld!” (tak, 50% własnej koszuli naszego programisty)
• Twierdzenie, że działa w lokalnej skrzynce wysyłkowej, a wszystkie testy przeszły dobrze

Moja firma ma również dobry sposób na poradzenie sobie z takim „incydentem”:

• Pracownik musi nosić następujący kostium przez pół dnia ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• Nie przepraszam.

• Zrzuciłbym winę CI za umożliwienie mi popełnienia zepsutej kompilacji.

• Powinien istnieć proces CI, aby powstrzymać programistów przed popełnianiem uszkodzonego kodu.

• Jeśli kompilacja lokalna zakończy się niepowodzeniem, nie powinno być dozwolone wchodzenie na serwer kompilacji.

Chociaż myślę, że można przeprosić, nie mów: „Dopilnuję, aby to się więcej nie powtórzyło”. Ponieważ tak będzie. A jeśli to zrobi, ugryzie cię.

Jeśli pracujesz nad projektem typu open source,

po prostu powiedz „Przepraszam, zepsułem wersję.

i dodaj jako komentarz github.

Jest tak, ponieważ wielu programistów open source pisze kod o północy.