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

115

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ć.

Scott
źródło
119
Nie wysyłaj CC całego zespołu, gdy wysyłasz mu ten e-mail.
quant_dev
26
Oczywiście powiedz mu, dyplomatycznie lub / i żartem. W firmie, w której pracuję, mamy pulpit z nazwiskiem każdego dewelopera. Za każdym razem, gdy ktoś popełnia błąd związany z repozytorium (zapomniał coś zatwierdzić, zapomniał o tagowaniu, nie skompilował się itp.), Programista otrzymuje „+”. Kiedy ma „+++”, musi zapłacić śniadanie na następny dzień. O dziwo, odkąd system został wprowadzony, mniej „obowiązkowych” śniadań :-)
Jalayn
26
@Jalayn - nie z żartem - to po prostu denerwuje ludzi
user151019
29
„Załóżmy, dla celów argumentu, że błąd jest na tyle subtelny, że automatyczne testy serwera CI nie mogą go wykryć.” Dlaczego nie? Czy to coś, na co nie masz testu? Jeśli tak jest, pierwszą rzeczą, którą powinieneś zrobić, to napisać test (lub kilka testów), który teraz się nie powiedzie, ale przejdzie, gdy błąd zostanie naprawiony. Jeśli nie można tego przetestować, dlaczego nie?
Thomas Owens
18
@Thomas Owens Ponieważ nie o to pytam. :-P W idealnym świecie do systemu nie dostaliby się żadne błędy, ponieważ po raz pierwszy napisalibyśmy idealny kod, a na wszelki wypadek istniałby pełny zestaw zautomatyzowanych testów. To jednak nie jest idealny świat, więc pytam, co powinieneś zrobić, gdy błąd dostanie się do twojego kodu.
Scott

Odpowiedzi:

38

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.

Justin
źródło
„One: Jasne, to poradzi sobie… sytuacja, o której nie wiedziałam…” Mam problem z tym tbh. Jeśli skutecznie udokumentowali zmianę, nie powinnaś być tego świadoma.
temptar
1
@temptar Uczciwie - zamień „nie byłem świadomy” na „jeszcze nie myślałem o tym” lub czymkolwiek innym, co wolisz - chodzi mi o to, że chociaż możesz to sobie wyobrazić (np. przeglądając dokumentację), jego zwykle szybciej po prostu zapytać. Również dużo kodu nie jest tak dobrze udokumentowane, jak powinno być.
Justin
170

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ł.

Sardathrion
źródło
107
+1. Osobiste ulubione podejście: „Zanim zacząłem się z tym bawić, czy był powód, dla którego zrobiłeś to w ten sposób?”
pdr
67
+1. „Krytykuj kod, a nie osobę, która go napisała”.
c_maker
11
+1, Jest to bardzo podobna rada do tego, co powiedział mój doradca małżeński mojej żonie i mnie, gdy mam skargę na to, co robi twój partner, unikaj słowa TY , to jest zbyt konfrontacyjne.
wałek klonowy
3
+1, ale nie sądzę, żeby słowo „ty” było konfrontacyjne. Konieczne jest jasne zrozumienie własności. Osobiście miałem ludzi, którzy ciągle popełniali kod, który zepsuł kompilację, ponieważ nie rozumieli, że to oni ją spowodowali. Podoba mi się podejście @ pdr ... to stwierdzenie nie jest konfrontacyjne, ale zawiera słowo „ty”.
Tim Reddy,
3
Wygląda na to, że ponownie wprowadzasz nowy błąd. Ich poprawka mogła rozwiązać poprzedni problem, o którym nie wiesz. Dlaczego nie pójść do nich i zapytać, dlaczego napisali kod w taki sposób, w jaki to zrobili. Może ujawnić, że kryje się w nim dziwne zachowanie językowe / projektowe / vm. Pokazanie im swojego ego [„heres, jak mogę zrobić lepiej” nie pomoże im]
mnich
70

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.

Tom Squires
źródło
3
Część „uczenie się na błędach” nie jest powszechnie prawdą. Ogromna liczba błędów to na przykład brakujące walidatory. Są to rzeczy, które po prostu się zdarzają, nawet doświadczonym programistom. Z tego wiele się nie nauczysz. Dlatego musimy mieć przyzwoitą kontrolę jakości.
Falcon
2
@Falcon Wgląd „musimy mieć przyzwoitą kontrolę jakości” jest przykładem uczenia się na błędach. Możesz kontynuować, myśląc o tym „dlaczego nie mamy kontroli jakości / dlaczego w naszej kontroli jakości brakuje tego problemu”
MarkJ
2
@ Falcon „To są rzeczy, które po prostu się zdarzają” <--- to tylko wiedza, którą otrzymujesz z powtarzających się, ale trywialnych błędów. Czy miałeś doświadczenie podczas kompilacji i rzeczy nie działają, najpierw sprawdź swoją pisownię i huk, w ciągu 10 sekund błąd zniknął. Zdajesz sobie sprawę, że „są to rzeczy, które się po prostu dzieją”, czasem dlatego możesz debugować w 10 sekund, a nie 10 godzin.
Gapton
@Gapton and MarkJ: To są dobre punkty! Nie myślałem o tym.
Falcon
„Jako programista Twoim zadaniem jest uczyć się na błędach”. -> „Jako człowiek ...” Uczenie się na błędach nie jest czymś specyficznym dla tej dziedziny.
Burhan Ali,
23

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.

mouviciel
źródło
4
+1 za „podejmij działania, aby uniknąć podobnych błędów, które mogą powstać w przyszłości”. To najważniejsza część, IMO.
CVn
1
The constructive way is to find the bug, fix it and take actions to avoid similar bugs to arise in the future.-> Założeniem pytania jest to, że już naprawiłeś błąd.
Hugo
1
Tak, ale bądź ostrożny przy wprowadzaniu nowego procesu. Jeśli wprowadzisz zbyt wiele procesów i zwołujesz zbyt wiele spotkań, to spowalnia tempo rozwoju i zatruwa morale w całej firmie. Widziałem zbyt wiele sklepów nadmiernie reagujących na błąd jednej osoby. Tylko wtedy, gdy błąd wskazuje na przerwany proces, nowy proces powinien być odpowiedni.
Jacob
@jacob - Zgadzam się.
mouviciel
19

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ć.

Caleb
źródło
2
Podoba mi się „Nie do końca rozumiem, czy możesz mi wyjaśnić, jak to działa?” podejście. Jeśli jest to zamierzone (i najnowsze), oryginalny programista powinien być w stanie dość dobrze wyjaśnić, jak działa kod. Jeśli jest to błąd, istnieje duża szansa, że ​​wyjaśniając, co robi kod, zauważy błąd, aw środku wyjaśnienia usłyszysz „ups”. Tak czy inaczej, trudno byłoby poczuć, że ktoś wskazuje na niego palcem z powodu możliwego błędu.
CVn
3
+1 za „wygląda na błąd, ale chciałem go uruchomić, zanim zacznę zadzierać z twoim kodem”.
Russell Borogove
6

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.

D Krueger
źródło
5

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ść.

Mike Dunlavey
źródło
5

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.

Michael „Opt” Gram
źródło
4

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!

opóźnienie
źródło
2

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.

Imran Omar Bukhsh
źródło
+1 za ostatnie zdanie. Chwała publicznie, krytykuj na osobności.
Scott C Wilson,
2

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;)

Żeglarz dunajski
źródło
1
Wszystko polega na tym, jak powiedzieć osobie, że popełniła błąd. Cały czas popełniam błędy i chętnie ktoś wskaże je, abym mógł je poprawić, ale jeśli przyjdziesz i powiesz mi: „Stary, twoje ostatnie popełnienie całkowicie złamało kod. Dlaczego nie możesz być lepszy w sprawdzaniu swoich błędów? ? Oczywiście będę obrażony.
Dzbanek
Tak, jednak pytanie „Koleś, przeprowadziłeś testy junit przed zatwierdzeniem?” jest, jak sądzę, w pełni akceptowalny :)
Danubian Sailor
+1 dla Tylko ci, którzy nic nie robią, nie popełniają błędów . Oczywiście, kiedy jest przegubowy, ale nie widziałem go wcześniej tak starannie.
FumbleFingers
2

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.)

puszysty
źródło
2

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 "

Rachel
źródło
2

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.

KeithS
źródło
W małej firmie, w której pracowałem, mieliśmy podobny system. Zabawne było to, że gdy sprawdziłeś jakiś kod, a testy zakończyły się niepowodzeniem, system kompilacji winiłby niepowodzenie testu za osobę, która ostatnio sprawdzała edycję w linii, której test / kompilacja nie powiodła się. Więc jeśli usunąłem funkcję, której używałeś, a Twój kod nie może się teraz zbudować. Build-Bot gwałtownie cię winił. Wynikające z tego przekleństwa i przyjazne wywoływanie nazw zapewniły, że błędy kompilacji zostały natychmiast naprawione, a irytacja wszystkich skierowana była na Build-Bot.
Stuart Woodward,
2

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.

Stuart Woodward
źródło
1

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ę.)

Russell Borogove
źródło
1

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.

HLGEM
źródło