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?
continuous-integration
builds
release
rajachan
źródło
źródło
Odpowiedzi:
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.
źródło
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.
źródło
drop database
... Och, moc tych dwóch małych słów. To było lata temu, ale dobrze to pamiętam;)Dwa cytaty dla Ciebie:
Zgadzam się z Jimem G. , nie przepraszaj, ale ucz się na tym i nie popełniaj tego samego błędu ponownie ... zachowaj SUCHOŚĆ;)
źródło
"I expect you to make lots of mistakes. Own up to them, accept them, and learn from them. If you never make mistakes, you'll never really learn anything"
.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.
źródło
"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:
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.
źródło
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.
źródł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.
źródło
Najlepsze przeprosiny to szybkie naprawienie przerwy
źródło
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:
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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).
źródło
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.
źródło
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ś.
źródło
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.
źródło
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ę.
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.
źródło
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.
źródło
Zwykłą praktyką w mojej firmie jest:
Moja firma ma również dobry sposób na poradzenie sobie z takim „incydentem”:
źródło
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.
źródło
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ę.
źródło
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.
źródło