Czy powinienem powiedzieć komuś, że ich popełnienie spowodowało regres?

Kiedy wyśledzisz i naprawisz regresję - tj. Błąd, który spowodował, że poprzednio działający kod przestał działać - kontrola wersji pozwala całkowicie sprawdzić, kto dokonał zmiany, która go złamała.

Czy warto to robić? Czy konstruktywne jest wskazanie tego osobie, która dokonała zatwierdzenia? Czy charakter pomyłki (w skali zwykłej nieuwagi wobec fundamentalnego niezrozumienia zmienionego przez siebie kodu) zmienia się, czy jest to dobry pomysł?

Jeśli dobrze jest im powiedzieć, jakie są dobre sposoby na to, aby nie powodować obrażeń lub defensywy?

Załóżmy dla argumentu, że błąd jest na tyle subtelny, że automatyczne testy serwera CI nie mogą go wykryć.

Jeśli tylko podejdziesz do nich i powiesz im o pomyłce, którą popełnili, to jeśli nie będziesz najlepszym dyplomatą na świecie, trudno będzie nie brzmieć jak „Ha! - spójrz na ten błąd, który popełniłeś!”. Wszyscy jesteśmy ludźmi, a krytyka jest trudna do przyjęcia.

Z drugiej strony, chyba że zmiana jest całkowicie trywialna i ewidentnie błędna, zwykle uważam, że rozmowa z osobą, która dokonała pierwotnej zmiany w ramach mojego dochodzenia, jest po prostu słuszna, aby upewnić się, że w pełni rozumiem, co się dzieje, stąd zwykle w końcu radzenie sobie z tą sytuacją polega na przejściu do wspomnianej osoby i przeprowadzeniu podobnej rozmowy:

Ja: Pracuję nad tym błędem, w którym ... podsumowanie błędu ... i myślę, że wyśledziłem problem do zmiany, którą wprowadziłeś. Czy pamiętasz, po co ta zmiana? / Czy masz czas na wyjaśnienie tej zmiany?

Następnie albo:

One: Jasne, to poradzi sobie z ... sytuacją, o której nie wiedziałem ...

Lub coś w stylu:

One: Nie, przepraszam, nie pamiętam, wygląda mi źle.

Idąc i wspólnie badając zmianę / błąd, oryginalny komisarz może uczyć się na swoich błędach bez poczucia, że ​​jest krytykowany *, a także istnieje spora szansa, że ​​się czegoś nauczysz.

Jeśli pierwotnego sprawcy nie ma w pobliżu lub jest zajęty, możesz zawsze po prostu prześlizgnąć się i sam to wszystko zrozumieć, po prostu zwykle rozmawiam z osobą, która dokonała zmiany, jest szybsza.

* Oczywiście zadziała to tylko wtedy, gdy jesteś naprawdę zainteresowany pomocą innych osób. Jeśli używasz tego tylko jako słabo zakamuflowanej metody mówienia komuś o pomyłce, którą popełnili, to prawdopodobnie jest to gorsze niż otwarcie na ten temat.

Bądź asertywny, a nie agresywny. Zawsze faworyzuj powiedzenie czegoś podobnego do „ten fragment kodu nie działa” a „twój kod nie działa”. Krytykuj kod, a nie osobę, która go napisała.

Jeszcze lepiej, jeśli możesz wymyślić rozwiązanie, napraw je i pchaj do nich - zakładając, że masz rozproszony system kontroli wersji. Następnie zapytaj ich, czy poprawka dotyczy poprawionego błędu. Ogólnie rzecz biorąc, spróbuj zwiększyć swoją wiedzę na temat programowania. Ale róbcie to bez przeszkadzania waszemu ego.

Oczywiście powinieneś chcieć słuchać innych programistów przychodzących do ciebie z tym samym problemem i postępować tak, jak byś tego chciał.

Tak, zawsze . Jako programista Twoim zadaniem jest uczyć się na błędach.

Poinformowanie ich o popełnionych błędach pomoże im stać się lepszym programistą i zmniejszyć ryzyko popełnienia błędów w przyszłości. ALE bądź uprzejmy i nie rób z tego wielkiego problemu, wszyscy robimy błędy co jakiś czas. Uważam, że uprzejmy e-mail to bardzo niekonfrontacyjny sposób informowania ludzi.

Konstruktywnym sposobem jest znalezienie błędu, usunięcie go i podjęcie działań w celu uniknięcia podobnych błędów, które pojawią się w przyszłości.

Jeśli wymaga to wyjaśnienia ludziom, jak nie wprowadzać błędów, skorzystaj z nich.

Kiedyś pracowałem w zespole, w którym kierownik projektu nigdy nie powiedział konkretnemu deweloperowi, że popełnił błąd: zorganizował spotkanie z całym zespołem, w którym wyjaśnił, że popełnił błąd i zdefiniowano nowy proces w celu stłumienia tego rodzaju błędy. W ten sposób nikt nie został napiętnowany.

Ogólnie tak .

Nikt nie powinien się bronić, jeśli jesteś taktowny. Łatwym sposobem na poradzenie sobie z tym jest poproszenie ich, aby dokładnie sprawdzili twoją zmianę przed zatwierdzeniem jej z powrotem do linii głównej (lub czegokolwiek, co jest odpowiednie dla twojego systemu kontroli wersji). Ludzie docenią to, jeśli zaoszczędzisz im kilka minut, naprawiając oczywiste błędy, ale nie docenią tego, jeśli naprawisz coś, co nie zostało zepsute, a ostatecznie złamie kod. Dając im szansę na sprawdzenie zmiany, mówi im, że nie chcesz nadepnąć na ich palce i daje im możliwość sprzeciwienia się wprowadzonym zmianom.

Jeśli jest to duża zmiana, a nie tylko literówka, dobrym pomysłem jest poinformowanie autora, zanim spróbujesz go naprawić. „Joe, wczoraj połączyłem własne rzeczy i znalazłem coś, czego nie jestem pewien, czy rozumiem. Wygląda to na błąd, ale chciałem go uruchomić, zanim zacznę mieszać się z Twoim kodem. mnie?"

Wasze relacje z autorem są ważnym czynnikiem. Jeśli nie miałbyś nic przeciwko autorowi, który naprawiał twój kod, nie mówiąc ci o tym, i jeśli jesteś pewien, że to uczucie jest wspólne, to może nie warto o tym wspominać. Jeśli jest to ktoś z większym doświadczeniem / stażem pracy / statusem, musisz poinformować go, że zamierzasz zmienić jego kod. Jeśli jest to ktoś mniejszy, zastanów się, czy jest to coś, co musi usłyszeć, aby uniknąć powtórzenia błędu, czy może niepotrzebnie go zawstydzić.

Zawsze pamiętaj, że jeśli możesz dowiedzieć się, kto zarejestrował „błąd”, równie łatwo może dowiedzieć się, kto „naprawił” swój kod. Jeśli sądzisz, że byliby zdenerwowani / zirytowani / zawstydzeni, gdy dowiedzieliby się o twojej zmianie po fakcie, z całą pewnością powiedz im wcześniej.

Naprawienie błędu to nie jedyna opcja. Zawsze możesz po prostu zgłosić błąd w narzędziu do śledzenia problemów. Ponownie wymagany jest tutaj takt - zgłoszenie błędu czyni go bardziej widocznym dla całego zespołu, ale daje też autorowi szansę na naprawienie własnego błędu. Raportowanie jest najlepszą opcją, jeśli nie masz pewności co do najlepszego sposobu rozwiązania problemu lub po prostu nie masz czasu, aby go naprawić.

Jeśli dokonam zatwierdzenia zawierającego błąd, lepiej mi o tym powiedzieć. Jeśli znajdę twoje zatwierdzenie, które zawiera błąd, na pewno ci powiem.

Poprawiamy się tylko wtedy, gdy rozumiemy nasze błędy. W ten sposób produkujemy lepszy kod w przyszłości.

Dostajesz tutaj doskonałe odpowiedzi.

Mogłem tylko dodać technikę, której nauczyłem się od menedżera raz, kiedy popełniłem błąd.

Byłem konsultantem w średnim wieku z doktoratem. a ona była młodym menedżerem bez, więc mógł być postrzegany gradient prestiżu. W każdym razie wyraźnie miała doświadczenie z tą sytuacją i wiedziała, jak sobie z tym poradzić.

Wspomniała mi niemal przepraszającym tonem, że wydaje się, że jest problem i czy miałbym czas, aby się tym zająć?

Często błąd był mój i wiedziała o tym. To jest umiejętność.

Myślę, że u podstaw tego pytania leży głębszy problem. Tak, zgłaszający powinien z pewnością zostać poinformowany o konsekwencjach ich zmiany, aby mogli zrozumieć, co się stało, i nie robić tego samego ponownie. Jednak kontekst twojego pytania wskazuje, że przygotowałeś i przesłałeś poprawkę bez wiedzy pierwotnego zgłaszającego, że nawet spowodował problem. Na tym polega głębszy problem: dlaczego zgłaszający nie wie już o regresji i dlaczego nie naprawił jej sami? Sytuacja, którą opisałeś, może wskazywać na brak odpowiedzialności lub czujności ze strony oryginalnego podmiotu przesyłającego, co może potencjalnie budzić obawy dotyczące ich ogólnej wydajności i motywacji.

Moje doświadczenie w inżynierii oprogramowania nauczyło mnie, że jestem właścicielem wszystkich moich zmian w kodzie, nie tylko projektów, za które jestem odpowiedzialny, aż do produkcji, co obejmuje świadomość ich wpływu, w tym na system kompilacji i (oczywiście) zachowanie produktu.

Jeśli czyjaś zmiana spowodowała problem, nie oznacza to, że dana osoba jest złym inżynierem, ale zwykle powinna być odpowiedzialna za naprawę wszystkiego, co poszło źle. Nawet jeśli nie są „winni”, np. Ich kod ujawnił ukryty błąd, który istnieje w bazie kodów od lat, powinni być jedną z pierwszych osób, które zdają sobie sprawę z problemu z ich zmianą. Nawet jeśli oryginalny zgłaszający nie jest odpowiednią osobą do naprawienia błędu, powinien być ściśle powiązany z cyklem życia jego zmiany.

Dobra przyczepność do twojego pytania! Wszyscy ci powiedzieli, co robisz. Powinieneś powiedzieć TAK! Za każdym razem, gdy pytanie brzmi „czy powinienem więcej komunikować?”, Odpowiedź brzmi prawie zawsze TAK!

Ale aby dodać coś innego: twoje założenie jest wadliwe.

Współpracownik dokonał zatwierdzenia, które nie złamało CI, ale doprowadziło do odkrycia problemu.

Gratulacje! Znalazłeś nowy błąd, a nie regres. Poważnie, czy podczas testowania ręcznie testujesz każdy scenariusz i wiersz kodu nieobjęte automatycznym (lub znormalizowanym ręcznym testowaniem)?

Z całą pewnością zaangażuj swojego kolegę w poprawkę, przeprowadzając testy, aby upewnić się, że nie może się to powtórzyć. Obaj jesteście bohaterami! Jeśli jednak zignorujesz jakąś winę za słowo lub działanie, jesteś odpowiedzialny za utrwalenie jednej z najgorszych chorób organizacyjnych: odpowiedzialności bez odpowiedzialności.

Jeśli naprawdę potrzebujesz znaleźć wieśniaka, pomyśl o facecie, który popełnił oryginalny kod, który złamał i pozostawił pułapkę dla niczego niepodejrzewającego kolegi (oczywiście bez wystarczającego zasięgu testu). Mam nadzieję, że to nie byłeś ty!

Zawsze uważaj drugą osobę za kogoś lepszego od ciebie, zawsze postrzegaj inne dobre cechy i zawsze wiem, że też mogę popełniać błędy.

Powiedz im, kiedy to tylko wasza dwójka.

Jeśli ktoś się obrazi, kiedy mu powiedziałeś, że popełnił błąd, oznacza to, że myśli, że jest najmądrzejszy na ziemi i nie popełnia błędu, a kiedy go krytykuje, ma wrażenie, jak powiedzieliśmy w Polsce, że „korona spada jego głowa'.

Dlatego nie wahaj się powiedzieć, że ktoś popełnił błąd. To normalne. Każdy popełnia błędy, nawet najlepiej! Tylko ci, którzy nic nie robią, nie popełniają błędów;)

Oprócz tego, co powiedzieli inni, upewnij się, że to AKTUALNIE ich zatwierdzenie spowodowało błąd. Na pewno nie obwiniaj kogoś za swój błąd. Bez względu na to, jak taktownie do nich podchodzisz, nadal ich wkurzasz, jeśli obwiniasz ich o coś, czego nie zrobili. (Mówiąc jak ktoś, kogo ciągle obwiniano za błędy innych ludzi; pewnego razu ktoś podszedł do mnie i powiedział, że zrobiłem coś zupełnie głupiego, a ja przywołałem dziennik zmian i stwierdziłem, że ostatnią osobą, która dotknęła tego wiersza kodu, była osoba, która mnie obwiniała. W jakiś sposób nadal wydawało mu się, że to moja wina, ponieważ pierwotnie napisałem ten wiersz.)

Dlaczego nie widzę tutaj żadnej odpowiedzi, która odzwierciedla najczęściej głosowany komentarz do pytania?

Tak, absolutnie powiedz im o tym, ale nie rób tego przed całym zespołem

Podejdź do programisty 1: 1 i wskaż błąd. Nie rób z tego wielkiej sprawy. Zawsze myślałem, że wskazanie błędu przed całym zespołem było złym pomysłem. Może działać dla niektórych programistów, ale nie dla wszystkich i może mieć negatywny wpływ. Pamiętaj, że wszyscy byliśmy w pewnym momencie w swoich butach, a jak mówi druga najczęściej głosowana odpowiedź, uczysz się na własnych błędach

Zwykle uważam, że działa najlepiej, gdy zaczynasz od komplementu, a następnie dochodzisz do błędu ... coś w rodzaju „poprawka, którą zaimplementowałeś działa świetnie, ALE wygląda na to, że popsuła x, y, z” lub „dzięki za zrobienie , b, c, ALE wydaje się, że powoduje x, y, z "

Prosta odpowiedź: tak.

Dłuższa odpowiedź: moją ostatnią pracą była firma Agile, która używała TDD z narzędziami CI, aby upewnić się, że to, co było w naszym repozytorium SVN, było dobre, działający kod przez cały czas. Gdy coś zostało popełnione, nasz serwer TeamCity otrzymał kopię, skompilował i przeprowadził testy jednostkowe. Co godzinę przeprowadzano również testy integracyjne. Jeśli popełniono coś, co spowodowało awarię CI, wszyscy otrzymywali wiadomość e-mail z informacją, że kompilacja uległa awarii na podstawie zatwierdzenia określonej osoby.

Nie zawsze wszystko łapało; biada nam, nie egzekwowaliśmy pokrycia kodu, a nawet jeśli coś zostało objęte testami jednostkowymi lub integracyjnymi, mogą nie wykonywać tego kodu w wystarczającym stopniu. Gdy to się stanie, ktokolwiek dostanie zadanie naprawienia znanego problemu (jeśli QA go złapie) lub wady (jeśli, dun-dun-dun, klienci)), popełni „winę” (pokazuje, kto ostatnio zmodyfikował każdą linię plik kodu) i określ winnego.

Wzywanie kogoś do sprawdzenia złamanego kodu niekoniecznie jest złą rzeczą. Nie udało im się właściwie wykonać swojej pracy i albo oni, albo ktoś inny musiał wrócić i naprawić błąd. Tak dzieje się cały czas; jak duża powinna być umowa, zależy od tego, jak łatwa była łatka, czy błąd wskazuje, że dana osoba nawet nie skompilowała ani nie uruchomiła danego kodu, a także ogólną kulturę korporacyjną. Najważniejsze w tym wszystkim jest to, że osoba, która popełniła błąd, uczy się czegoś; jeśli kompilacja zepsuje się z powodu tego samego faceta w kółko, istnieje głębszy problem z tą osobą, który należy rozwiązać. Awarie kompilacji cały czas wskazują na problem z komunikacją zespołu lub znajomością procesu.

Tak. Poproś osobę o sprawdzenie poprawki dokonanej w kodzie. Czasami odkryłem, że czyjś błąd był w rzeczywistości trudną częścią kodu z innymi niewidocznymi konsekwencjami, jeśli błąd został po prostu naprawiony.

W grę wchodzi wiele czynników.

• Jak poważny jest błąd?
• Jaki jest stosunek starszeństwa między tobą a przerywaczem?
• Jak zajęty / zestresowany jest zespół?
• Czy łamacz działał w części bazowej czy w twojej?
• Jak jesteś pewien, że to był prawdziwy błąd i jak bardzo jesteś pewien, że poprawka jest poprawna?

Jeśli problem był niewielki - błąd w pisowni / cienkim / wycinaniu i wklejaniu - a łamacz jest zajęty, a ty jesteś pewny swojej oceny problemu, prawdopodobnie nie musisz zwracać na to uwagi. (np foo.x = bar.x; foo.y = bar.y, foo.z = bar.y.).

W większości innych przypadków warto wspomnieć o problemie. W mniej poważnych przypadkach nie musisz przerywać tego, co robią; poczekaj i zrób to podczas lunchu lub gdy wpadniesz na nich w pokoju wypoczynkowym.

Jeśli jednak charakter błędu wskazuje na poważne nieporozumienie (dotyczące platformy wdrażania, lokalnych zasad lub specyfikacji projektu), przywołaj je jak najszybciej.

Jeśli nie masz pewności co do oceny, poproś o sprawdzenie poprawki, zwłaszcza jeśli nie jest ona w kodzie, który znasz. (Zdecydowanie zalecamy, aby Twój zespół programistów przyjął zasadę „kumpel kodowy”, zgodnie z którą wszystkie zmiany są sprawdzane przez inną osobę przed zalogowaniem się.)

Co się stanie, jeśli im nie powiesz?

Wady

Mogą popełnić ten sam błąd w innych miejscach, ponieważ nie rozumieją, że to powoduje problem. Nie tylko to, ale będzie dodatkowy niepotrzebny czas, aby wielokrotnie naprawić ten sam błąd. Nie możesz uczyć się na błędach, których nie jesteś świadomy.

Po drugie, myślą, że wykonują lepszą pracę niż oni. Kiedy ludzie nie są świadomi swoich problemów, nie można ich winić za to, że myślą, że dobrze sobie radzą, kiedy tak nie jest. Nawet gdy problem jest nieostrożnym błędem, ludzie robią ich mniej, gdy są świadomi, że błędy zostały zauważone.

Następnie, jeśli ktoś nie spojrzy na to, kto to zrobił, skąd będziesz wiedzieć, czy masz szczególny problem pracownika, który jest zawsze nieostrożny lub ma podstawowe nieporozumienia dotyczące produktu? Czy osoba odpowiedzialna chciałaby, aby trwała w zespole, w którym jest powiązana?

Jeśli naprawisz i przejdziesz dalej bez dyskusji, jesteś pewien, że naprawiłeś to poprawnie? Czasami są to testy, które należy zmienić, gdy zmieni się wymaganie. Jeśli jest to coś innego niż dość niewielka literówka, czy naprawdę możesz być pewien, że jedno z was ma właściwe rozwiązanie? Możesz łamać jego kod w zamian bez konsultacji.

Profesjonaliści

Ludzie nie wstydzą się i nie denerwują cię za wskazanie swoich błędów.

Wydaje mi się, że zdecydowanie opieram się na opowiadaniu im, ale robię to ładnie i prywatnie. Nie ma potrzeby publicznego upokorzenia. Jeśli osoba wielokrotnie popełnia te same błędy lub popełnia błędy krytyczne, które wskazują na brak zrozumienia, należy również uświadomić przełożonemu.