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?
Odpowiedzi:
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.
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.
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.
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ść.
all the time, to nie SCM się zepsuje, to twój zespół programistów ...
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.
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.