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

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ę?

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

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.

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.

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.

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.

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

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.

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.