Czy powinienem nagrać wykryty i załatany błąd?

68

Przypuszczam, że jest to częsta sytuacja: testuję jakiś kod, odkrywam błąd, naprawiam go i zatwierdzam do repozytorium. Zakładając, że wiele osób pracuje nad tym projektem, powinienem najpierw utworzyć raport o błędzie, przypisać go sobie i odwołać się do niego w komunikacie zatwierdzenia (np. „Napraw błąd #XYZ. Błąd był spowodowany przez X i Y. Naprawiono to przez Q i R ”)? Alternatywnie mogę pominąć raport o błędzie i zatwierdzić go komunikatem „Naprawiono błąd, który spowodował A, gdy B. Błąd był spowodowany przez X i Y. Naprawiono to przez Q i R.”

Co uważa się za lepszą praktykę?

David D.
źródło
4
Zależy od wielkości Twojej firmy i zespołu oraz cech błędu. W małych i szybkich zespołach nie jest to konieczne, ponieważ możesz komunikować się z innymi programistami, krzycząc na nie. W dużych zespołach, dużych organizacjach, rozproszonym środowisku programistycznym dobrze jest rejestrować swoją pracę, ale jest to również narzut, który obniży poziom produkcji, jeśli pracujesz nad kilkoma małymi błędami. Chyba że jest to poważny błąd, który zawsze jest dobrze udokumentowany, przetestowany jednostkowo w celu uniknięcia regresji i zamknięcia.
Machado,
15
Nie zapominaj, że niektóre błędy nie zostają naprawione - spontanicznie odradzają się, jeśli je zignorujesz. Warto wiedzieć, jak ktoś próbował to naprawić ostatnim razem. Przynajmniej, nie powinno być jakiś dokumentacja mówi, co zrobiłeś kodu i dlatego, nawet jeśli jest to tylko w komentarzach w kodzie.
alephzero,
5
Oprócz poprzednich komentarzy zależy to również od tego, czy błąd trafił na wolność, ale miałeś szczęście, że nie spotkał go żaden klient, czy też został wprowadzony i naprawiony w jednym cyklu wydawniczym.
whatsisname
3
W razie wątpliwości wykrzycz to. Dla mnie nigdy nie bolało otwieranie i zamykanie zgłoszenia błędu. W niektórych okolicznościach dobrze jest mieć takie rzeczy udokumentowane i oficjalne.
fresnel
1
W związku z komentarzem @ alephzero, coś, co mi się ostatnio przydarzyło: Naprawienie błędu w jednej części kodu ujawniło błędy w innym miejscu. Nieumyślnie odwołali się nawzajem w części, której nie dotknąłem, a pierwszym instynktem opiekuna było cofnięcie mojej poprawki.
Izkata,

Odpowiedzi:

71

To zależy od tego, kto jest odbiorcą zgłoszenia błędu.

Jeśli deweloperzy przyglądają się temu tylko wewnętrznie, aby wiedzieć, co należy naprawić, nie przejmuj się. W tym momencie to tylko hałas.

Niewyczerpująca lista powodów, dla których warto się zalogować:

  • Informacje o wersji zawierają informacje o naprawionych błędach (do pewnego progu, który spełnia ten błąd) - zwłaszcza jeśli usterka jest ujawniona
  • Kierownictwo chce pojęcia „czasu poświęconego na usuwanie błędów” / „liczby wykrytych błędów” itp.
  • Klienci mogą zobaczyć bieżący stan narzędzia do śledzenia błędów (aby sprawdzić, czy znany jest ich problem itp.)
  • Testerzy otrzymują informacje o zmianie, którą powinni przetestować.
Caleth
źródło
56
Najbardziej prawdopodobne miejsce wystąpienia błędu to miejsce, w którym błąd wcześniej wystąpił. Polecam nagrywanie go praktycznie w każdym scenariuszu.
corsiKa,
18
# 4: Testerzy używają narzędzia do śledzenia błędów do prowadzenia testów. Sprawdzą, czy poprawka działa i czy nie spowodowała nowych błędów ani regresji.
jpmc26
2
@corsiKa Kiedy lek jest gorszy od choroby? ;-)
hBy2Py
1
@ hBy2Py Znajdź nowego lekarza, a następnie nagraj go.
corsiKa
2
@BradThomas, aby zmienić sformułowanie, które zacytowałeś: „Bugtracker jest używany jako lista rzeczy do zrobienia i nic więcej” + „Naprawiono błąd” -> „no TODO”. Zgadzam się w prawie wszystkich innych sytuacjach, chcesz rekord
Caleth
52

Powiedziałbym, że to zależy, czy Twój produkt został wydany z błędem, czy nie.

Jeśli został wydany wraz ze znalezionym błędem, to tak, utwórz raport o błędzie. Cykle wydań mogą często być długie i nie chcesz, aby twój błąd był zgłaszany jako nowy problem, gdy już go naprawiłeś.

Jeśli twój błąd nie został jeszcze wysłany, nie podążę tą samą ścieżką. Będziesz teraz mieć ludzi próbujących odtworzyć twój błąd, którego nie mogą, ponieważ nie ma go jeszcze w wydaniu, co zasadniczo marnuje ich czas.

Pieter B.
źródło
2
Ponadto, jeśli sprawdzasz kod względem elementów pracy, rozważ naprawienie błędu w stosunku do oryginalnego elementu pracy podczas naprawiania błędów, które nie zostały wprowadzone do wersji produktu.
wablab,
24

Powinieneś to zrobić, jeśli jest to błąd, który mógł zostać zgłoszony przez klienta. Najgorszy przypadek: naprawiasz błąd, ale nikt nie wie. Klient zgłasza błąd. Twój kolega próbuje naprawić błąd, ale nie może go odtworzyć (ponieważ już go naprawiłeś). Właśnie dlatego chcesz zapisać błąd.

Jest to również przydatne, jeśli robisz recenzje kodu, gdzie zwykle kod byłby napisany dla jakiegoś zadania, a następnie sprawdzony. W takim przypadku lepiej jest usunąć tę usterkę, co może wymagać umieszczenia czegoś na liście zadań, a następnie wykonania całej pracy.

gnasher729
źródło
9

To zależy od kilku czynników.

Zarówno Pieter B, jak i Caleth wymieniają niektóre w swoich odpowiedziach:

  • Czy błąd był częścią oficjalnej wersji?
  • Czy liczba błędów / czasu spędzonego na nich jest specjalnie śledzona?

Mogą również obowiązywać wewnętrzne procedury, często poparte wymogami certyfikacji. W przypadku niektórych certyfikatów obowiązkowe jest, aby każda zmiana kodu była identyfikowalna w rekordzie w narzędziu do śledzenia problemów.

Ponadto czasami nawet trywialnie wyglądające poprawki nie są tak trywialne i niewinne, jak się pojawiają. Jeśli po cichu dołączysz taką poprawkę do dostarczenia niezwiązanego problemu, a później poprawka okaże się problematyczna, znacznie utrudni to wyśledzenie, nie mówiąc już o izolacji lub przywróceniu.

Angew
źródło
2
Oczywiście powinieneś wspomnieć o błędzie w komunikacie zatwierdzenia, a najlepiej dokonać osobnego zatwierdzenia dla zmiany, która naprawiła błąd. (A może osobna seria pull-request lub patch, jeśli jest to zmiana, która jest samodzielna). Jedynym wyjątkiem jest sytuacja, gdy błąd zostanie naprawiony jako efekt uboczny zmiany czegoś z innego powodu (ale nadal wspomni o tym w komunikacie zatwierdzenia). Jedyne pytanie brzmi: czy zawracać sobie głowę trackerem błędów, a nie czy łączyć zmianę z innymi rzeczami w jednym zatwierdzeniu!
Peter Cordes
3

Odpowiedzi na to pytanie może udzielić tylko kierownik projektu lub osoba odpowiedzialna za „proces biletowania”.

Ale pozwól mi zapytać w drugą stronę: dlaczego byś nie nagrać błąd co połatany?

Jedynym możliwym do zrozumienia powodem, dla którego widzę, jest to, że wysiłek włożenia zgłoszenia błędu, popełnienia go i zamknięcia go jest o rząd wielkości większy niż czas usunięcia błędu.

W tym przypadku problemem nie jest to, że błąd można tak łatwo naprawić, ale że papierkowa robota trwa zbyt długo. Naprawdę nie powinno. Dla mnie narzutem na utworzenie biletu Jira jest naciśnięcie c, następnie wprowadzenie krótkiego podsumowania 1-liniowego i naciśnięcie Enter. Opis nie jest nawet narzutem, ponieważ mogę wyciąć i wkleić go do komunikatu zatwierdzenia wraz z numerem wydania. Na koniec . c <Enter>problem został zamknięty. Sprowadza się to do 5 naciśnięć klawiszy nad głową.

Nie wiem o tobie, ale to wystarczy, aby nawet w małych projektach zapisywać każdą poprawkę w ten sposób.

Korzyści są oczywiste - jest całkiem sporo osób, które mogą z łatwością pracować z systemem biletowym takim jak Jira, ale nie z kodem źródłowym; istnieją również raporty generowane z systemu biletów, ale nie ze źródła. Zdecydowanie chcesz, aby były tam naprawione błędy, aby dowiedzieć się o możliwych zmianach, takich jak stale rosnący napływ małych 1-liniowych poprawek błędów, które mogą zapewnić ci wgląd w problemy związane z procesem lub cokolwiek innego. Na przykład, dlaczego często musisz robić tak małe poprawki błędów (zakładając, że zdarza się to często)? Czy to możliwe, że twoje testy nie są wystarczająco dobre? Czy poprawka dotyczyła zmiany domeny lub błędu kodu? Itp.

AnoE
źródło
2

Zasadą, którą stosuję jest to, że jeśli sekcja, nad którą pracujesz, nigdy nie została wydana, a nawet jeszcze nie działa i żaden użytkownik jej nie widział, napraw każdy błąd, który widzisz szybko i przejdź dalej. Po wydaniu oprogramowania i rozpoczęciu jego produkcji, a niektórzy użytkownicy go widzieli, każdy widziany błąd otrzymuje raport o błędzie i jest sprawdzany.

Odkryłem, że to, co uważam za błąd, jest cechą dla kogoś innego. Naprawiając błędy bez ich sprawdzania, mógłbym tworzyć błąd zamiast go naprawiać. Wprowadź raport o błędzie, które wiersze chcesz zmienić, aby naprawić błąd i swój plan, w jaki sposób należy go naprawić.

Podsumowując: Jeśli ten moduł nigdy nie był w produkcji, szybko napraw błąd, który widzisz, i postępuj zgodnie ze specyfikacją. Jeśli moduł jest już w produkcji, zgłoś każdy błąd jako raport o błędzie do przejrzenia przed naprawą.

Russell Hankins
źródło
1

Tak .


Istnieją już odpowiedzi, które ujawniają sytuacje, w których warto utworzyć raport o błędzie. Niektóre odpowiedzi. I różnią się.

Jedyną odpowiedzią jest to, że nikt nie wie. Różni ludzie w różnych momentach będą mieli różne opinie na ten temat.

Więc teraz, gdy napotykasz błąd, masz dwa rozwiązania:

  • Zastanów się, czy warto otworzyć raport o błędzie, czy nie, może zapytaj kolegę o opinię ... a później, w niektórych przypadkach, żałuj, że nie zrobiłeś tego, ponieważ ktoś o to pyta, a jeśli masz już raport, możesz po prostu wskaż im to
  • po prostu utwórz raport

Tworzenie raportu jest szybsze, a jeśli nie ... zautomatyzuj go.


Jak to zautomatyzować? Zakładając, że twój moduł śledzący obsługuje skrypty, po prostu stwórz skrypt, który możesz wywołać i który użyje komunikatu zatwierdzenia (tytuł i treść), aby przesłać raport o błędzie i natychmiast go zamknąć jako „zaimplementowany”, z rewizją zatwierdzenia związaną ze śledzeniem.

Matthieu M.
źródło
0

Zgadzam się, że wszystkie pozostałe odpowiedzi oferują dobre ogólne zasady, a kilka nawet dotyka tej kwestii, ale myślę, że tutaj jest tylko naprawdę pewna odpowiedź.

Zapytaj swojego kierownika . Cóż, twój menedżer lub alternatywnie kierownik projektu lub mistrz scrum itp. W zależności od struktury grupy.

Istnieje wiele różnych systemów dobrych i złych praktyk, ale jedynym sposobem na sprawdzenie, czy robisz to dobrze dla swojego zespołu, jest zapytanie.

Coś w stylu jednominutowej rozmowy na korytarzu zrobiłoby: „Hej, szefie, jeśli naprawię drobny błąd, który zajmuje tylko kilka minut, czy warto zrobić bilet, czy powinienem po prostu wspomnieć o tym w wiadomości zatwierdzającej? „ i na pewno się dowiesz. Cała dobra praktyka na świecie jest bezużyteczna, jeśli ta metoda denerwuje zespół i kierownika.

Rzeczywistość
źródło