Błąd ponownie otwarty vs. nowy

55

Błąd został otwarty, naprawiony, zweryfikowany i zamknięty. Miesiąc później pojawił się ponownie w kolejnej wersji po kilku iteracjach bez regresji.

Pod warunkiem, że cechy błędu są takie same, czy ponownie otworzyłbyś istniejący identyfikator błędu lub otworzyłbyś nowy z linkiem do zamkniętego błędu?

KMoraz
źródło

Odpowiedzi:

86

Charakterystyka nie ma równych przyczyn. Nowy błąd może mieć inny podstawowy powód, nawet jeśli wydaje się być taki sam. Więc otwórz nowy błąd i wskaż go stary, aby pomóc programistom.

Dibbeke
źródło
23
+1 Istnieje wiele różnych chorób z różnymi metodami leczenia, które mają wspólne objawy.
FrustratedWithFormsDesigner
Czy słusznie byłoby wydedukować, że jeśli błąd ma tę samą przyczynę, ponownie go otworzysz?
KMoraz
@KMoraz: Tak mi się wydaje, ale to tylko coś, co należy wziąć pod uwagę po tym, jak dochodzenie udowodni, że jest to dokładnie ta sama przyczyna. Ponieważ symptomy zniknęły na jakiś czas, jest mało prawdopodobne, że jest to dokładnie ten sam błąd, chociaż może to być błąd wprowadzony do innej części systemu, ale zakodowany w taki sam sposób, jak kod pierwotnego błędu, powodując podobne objawy.
FrustratedWithFormsDesigner
1
@KMoraz powiedziałbym, że nie. Załóżmy, że został naprawiony w wersji 1.0, 1.1 go nie ma, ale pojawił się ponownie w wersji 1.2. O ile narzędzie do śledzenia problemów nie pozwala od razu powiązać go z wydaniami serwerowymi, stracisz historię, którą znaleziono i naprawiono w wersji 1.0. Po prostu otwórz nowy błąd.
Andy
1
@Andy Nie myśl, że to cokolwiek zmienia, ale może 1.1 to miało i nikt nie zauważył ...
joshuahedlund
35

Jeśli zostało to zweryfikowane i zamknięte, i działało przez chwilę, a następnie pojawiło się ponownie po zmianie czegoś, to nie jest to ten sam błąd. Może objawiać się podobnie jak stary błąd, ale jego przyczyna może być inna. Więc to nie ten sam błąd. Więc otworzę nowy, z linkiem do zamkniętego błędu.

Joonas Pulakka
źródło
16

Zawsze otwieraj nowy błąd. Dlaczego? Załóżmy, że okazuje się być identyczny z poprzednim błędem, a poprawkę dotyczącą poprzedniego błędu opublikowałeś. Informacje o wersji będą dokumentować, że „Napraw błąd XXX”. Z punktu widzenia śledzenia problemów i wyjaśnienia informacji o wydaniu lepiej jest odnieść się do nowego błędu „Napraw błąd XXX + 1 (który był podobny pod względem przyczyny i skutku do błędu XXX)” niż powiedzieć „Napraw błąd XXX (ponownie) ”lub coś podobnego.

James McLeod
źródło
2
Powoływanie się na identyfikatory błędów w opisach poprawek jest po prostu… bardzo nieprzyjazne.
Thomas Bonini
3
@krelp Pomocne jest, gdy współpracujesz z dostawcą, aby naprawić problem. Możesz śledzić otrzymany identyfikator błędu za pomocą identyfikatora błędu w informacjach o wersji.
Darryl Braaten
1
@Krelp Zastanawiałem się, dlaczego to zły pomysł, więc zapytałem tutaj: programmers.stackexchange.com/questions/142258/... Być może masz na ten temat jakieś uwagi? :)
Travis Northcutt
To dobra uwaga
KMoraz,
4

Ogólnie rzecz biorąc, otwórz nowy błąd.

Jeśli jednak wolno ci najpierw przeprowadzić dochodzenie, sprawdziłbym twoją historię w kodzie źródłowym .

Jeśli pracujesz w środowisku zespołowym, ktoś może mieć stary kod w swoim systemie (tj. Nie zrobił Get Get po sprawdzeniu oryginalnej poprawki), wprowadził zmiany, a następnie zalogował się bez robienia różnic. Zła praktyka, jasne, ale zdarza się to „przez cały czas”.

Przegląd historii plików, w których naprawiono błąd, szybko potwierdzi lub wyeliminuje to jako możliwość.

Wonko przy zdrowych zmysłach
źródło
1
„(tzn. nie dokonali aktualizacji po sprawdzeniu oryginalnej poprawki), dokonali zmian, a następnie zalogowali się bez robienia różnic”… jeśli tak się stanie, system kontroli źródła jest uszkodzony
JoelFan
@JoelFan - niekoniecznie. Czasami automatyczne scalanie nie działa poprawnie, a czasem scalanie ręczne również nie działa poprawnie. Lub może być tak, że przegapili zmianę, kiedy zrobili różnicę itp. Wszystko, co mówię, to to, że pachnie to ludzkim błędem, a 2-minutowa kontrola historii kontroli źródła może zaoszczędzić dużo kłopot.
Wonko the Sane
1
W każdym razie warto sprawdzić historię ... bo jeśli twój system kontroli źródła jest zepsuty, chcesz to wiedzieć.
mjfgates
2
Jeśli tak się stanie all the time, to nie SCM się zepsuje, to twój zespół programistów ...
Daenyth
1

Zgadzam się z sugestią poprzednich plakatów, aby otworzyć nowy błąd, ponieważ może on nie być przyczyną tej samej przyczyny.

Moim dalszym zaleceniem byłoby upewnienie się, że zawsze dodajesz testy jednostkowe i integracyjne, które obejmują błąd, aby w przyszłych wersjach wychwycić problem od razu, zanim trafi on do Twoich klientów. Nie ma nic gorszego dla klienta niż powrót tego samego błędu.

Mike Parkhill
źródło
1

Nie najlepsza analogia - tylko dlatego, że objawy dwóch osób są takie same, nie oznacza to, że choroba / przyczyna choroby jest taka sama.

Z wikipedii:

Błąd oprogramowania to błąd, wada, awaria lub usterka w programie komputerowym lub systemie, która powoduje, że generuje niepoprawny lub nieoczekiwany wynik lub zachowuje się w niezamierzony sposób. Większość błędów wynika z .....

Błąd jest wadą kodu i ma objawy / skutki. Błąd nie jest objawem. Błąd to błąd w kodzie. Tylko dlatego, że objawy są takie same, niekoniecznie oznacza to, że ta sama wada powoduje objawy.

Rozumiem, że powinieneś ponownie otworzyć błąd, gdy masz pewność, że błąd został spowodowany przez ten sam fragment kodu. Może się to zdarzyć, gdy kod zachowuje się poprawnie we wszystkich scenariuszach testowych / przypadkach testowych, ale nie występuje w nowym przypadku testowym lub przypadku testowym, o którym wcześniej nie myślałeś. Tego rodzaju scenariusz może nie być powszechny.

Innym scenariuszem jest to, że te same symptomy są powodowane przez nowe wady, tj. Nowe błędy w innych częściach tego samego kodu lub nawet w innych systemach wpływających na ten kod.

Zatem najbezpieczniejszym rozwiązaniem jest otwarcie nowego błędu, gdy wystąpią takie same objawy. Jeśli zauważysz, że ten sam stary kod jest odpowiedzialny za błąd, zamknij nowy błąd i otwórz go ponownie. Jeśli nie, pozostaw nowy błąd i połącz go ze starym.

BugBot
źródło