Czy programiści powinni wprowadzać błędy do systemu śledzenia błędów?

Podczas opracowywania (funkcji lub poprawek błędów) czasami zdarza mi się odkrywać błędy, które nie są bezpośrednio związane z tym, nad czym pracuję. Co powinienem zrobić w tej sytuacji. Napraw to? Czy pamiętasz, aby to naprawić później? Gdzieś to zapisać? Lub wprowadzić go do systemu śledzenia błędów?

Zazwyczaj wpisuję go do systemu śledzenia błędów i pozwalam, aby proces sam się rozegrał (tj. Triaging, przypisanie itp.). Jednak prawie nigdy nie widziałem, aby inny programista wprowadził błąd. (Dlaczego?)

Jeśli odkryjesz błąd, nie mogę wymyślić żadnego dobrego powodu, aby nie wprowadzać go do systemu śledzenia błędów, czy to naprawisz, czy nie. W końcu po to jest system śledzenia błędów.

W niektórych przypadkach bardziej sensowne może być zgłoszenie tego osobie odpowiedzialnej za kontrolę jakości, która ma większe doświadczenie w pracy z systemem, ale w każdym razie błąd należy śledzić.

Możliwe, że istnieje jakiś powód, ważny lub nie, że programiści nie powinni wprowadzać błędów. Jednym z możliwych powodów może być to, że system śledzenia błędów jest widoczny dla osób postronnych, a zbyt wiele zgłoszonych błędów wygląda źle. To bardzo zły powód, którym należy się zająć w inny sposób, który nadal umożliwia śledzenie błędów. Zapytaj swojego szefa.

(Oczywiście, jeśli w kodzie nadal występuje błąd, nad którym wciąż pracujesz, i nie pojawia się on w żadnym wydanym wydaniu, nie ma potrzeby śledzenia go w systemie, chociaż komentarz DO ZROBIENIA w kodzie źródłowym może być dobry pomysł. W skrajnym przypadku „Ten kod nie zostanie skompilowany, ponieważ nie wpisałem jeszcze średnika na końcu tego wiersza”, nie jest to błąd zgłaszalny.)

Jeśli chodzi o to, dlaczego inni programiści nie wprowadzają błędów, musisz je zapytać. Prawdopodobnie powinni.

Musisz wprowadzić błędy w systemie śledzenia błędów w obu przypadkach:

• gdy błąd dotyczy bezpośrednio kodu, nad którym pracujesz,

• gdy błąd dotyczy kodu, nad którym obecnie nie pracujesz, lub części, nad którą pracuje inny programista.

Jest to niezbędne, ponieważ system śledzenia błędów służy do ... śledzenia błędów. Każdy błąd. Jeśli odkryjesz coś nie tak, nie naprawiaj tego. Dokumentuj to przez system śledzenia błędów. Gdy później klient korzystający z poprzedniej wersji oprogramowania zgłosi błąd, który jest dokładnym duplikatem, będzie można połączyć go ze swoim zgłoszeniem. Jeśli nie masz nic do czego można się odsyłać, zmarnujesz swój czas (lub kolegę) na szukanie błędu w poprzednich wersjach, a następnie spróbuj go rozwiązać, aż w końcu odkryjesz, że błąd został już magicznie rozwiązany.

To wyjaśnia również, dlaczego freelancerzy muszą używać zarówno kontroli wersji, jak i systemu śledzenia błędów: te dwa narzędzia są nie tylko dla zespołów.

Nie ma ważnego powodu, aby nie wprowadzać usterki do systemu śledzenia wad. Jedyne miejsca, w których widziałem poprawki błędów zastosowane bez śledzenia, ponieważ proces został zasadniczo przerwany. W takim przypadku napraw ten proces.

powody nie wchodzenia są:

• Proces mierzy i karze na podstawie zgłoszenia usterki - nie zgłaszaj, nie daj się ukarać. W takim przypadku opuść organizację
• Proces ten jest obciążeniem - wejście w wadę i zajęcie jej do momentu zajmuje zbyt wiele wysiłku i czasu. Proces ten powinien zostać zmieniony, aby umożliwić programistom szybkie śledzenie lekkich błędów w procesie triage / accept / fixed.
• Niektórzy deweloperzy są leniwi / niechlujni / hakerzy, którzy nie dbają o to, jaki wpływ mogą mieć na innych rzeczy. Rekrutuj profesjonalnych programistów.
• Jestem zespołem jednoosobowym, nie widzę sensu. Idź do pracy dla 2-osobowego zespołu, a będziesz ...

Naprawienie błędu od razu jest prawdopodobnie złym pomysłem. Po pierwsze, ktoś inny może pracować nad tą samą poprawką, co prowadzi do powielania wysiłków, a także, w zależności od metodologii programowania, którą stosujesz, ustalenie priorytetów nad tym, co będzie dalej pracować (naprawianie błędu lub wdrażanie nowej funkcji) jest bardziej decyzja zarządcza, a następnie decyzja rozwojowa.

Decyzja nie jest jednoznaczna i wiąże się z kompromisami.

(niektóre) PROS

Śledzenie błędów jest niezbędne w komunikacji, szczególnie w dużych zespołach. Jedną z najlepszych zalet posiadania wielu oczu na kod jest możliwość wcześniejszego wykrycia problemów, i ta korzyść jest tracona, jeśli błędy nie są rejestrowane lub śledzone podczas rozwoju.

• Często błędy można najłatwiej naprawić, gdy jesteś już częścią kodu, pracując nad jego zrozumieniem.
• Nawet w mniejszych zespołach istnieje wiele korzyści, jeśli chodzi o morale, ponieważ jest w stanie wymienić błędy i postępy w ich usuwaniu - czasem korzyści moralne są kluczowe nawet w przypadku projektów jednoosobowych.
• Dokładne wykrycie błędu może być bardzo trudne po fakcie - zobaczenie błędu w kodzie może zaoszczędzić wiele późniejszej pracy w detektywie, próbując dowiedzieć się, gdzie pierwotnie wystąpił problem.
• Dla ogólnego rozwoju programisty dobrze jest zwracać uwagę na pojawiające się błędy i nabrać nawyku krytycznego poprawiania / czyszczenia / czytania kodu

Rejestrowanie błędów w miarę ich znajdowania jest, ogólnie rzecz biorąc, dobrym nawykiem.

(niektóre) CONS

Wprowadzanie błędów do systemu śledzenia błędów może być uciążliwe i czasochłonne, a także może bardzo zakłócać prace programistyczne - częściej w przypadku pracy w dużych zespołach. Można oczekiwać, że:

• sprawdź, czy Twój wpis jest duplikatem przed wejściem (może to być nawet domniemane, zniechęcanie do wprowadzania błędu do kolejki tylko po to, aby ją zamknąć)
• podaj powtarzalne przypadki testowe dla swojego raportu
• akceptuj późniejsze pytania dotyczące szczegółów błędów, aby zaakceptować / zweryfikować poprawkę po napisaniu
• pomyśl o niepowiązanych informacjach, które często są gromadzone w systemach śledzenia błędów, takich jak to, który produkt jest prawdopodobnie najbardziej dotknięty, priorytet błędu itp.

Czasami śledzenie błędów nie jest po prostu najbardziej wydajnym wykorzystaniem twojego czasu.

Są to dwie ogólne zasady, które mogą być trudne do zrównoważenia - znalezienie dobrej strategii to trochę sztuka. W takich sytuacjach myślę, że najlepiej jest zastosować elastyczną heurystykę, którą dostosowuję zgodnie z wymaganiami dla danego projektu, zespołu, środowiska pracy i twoich ogólnych umiejętności. Moja strategia zwykle jest zgodna z następującym wzorcem:

• Zawsze rejestruj problemy tak, jak je widzisz przez cały dzień. Może na lepkiej, może w pliku z boku. Może wszystko, co logujesz, to nazwa pliku i numer linii, a może więcej. Nie pozwól, aby problem zbytnio przerwał twoją obecną linię myślenia.

• Poświęć trochę czasu na początku każdego nowego dnia pracy, w ramach rozgrzewki do pracy, aby poradzić sobie z lepkami. Zajmuję 10-15 minut, aby przejrzeć listę wykrytych problemów z poprzedniego dnia i zrobić jedną z poniższych czynności, która jest najszybsza:

  • Napraw problem i zatwierdź go (prawdopodobnie dla jednej poprawki lub literówki). Jeśli nie możesz popełnić błędu bez zgłoszenia błędu, utwórz projekt poboczny dla małych zmian. Gdy w pobocznym projekcie zgromadzi się wystarczająca liczba poprawek, poświęć kilka godzin na ich udokumentowanie i zatwierdzenie.
  • Zaloguj problem w systemie śledzenia błędów (w przypadku oczywistych problemów, których usunięcie zajmuje więcej czasu, ale bez uciążliwych kosztów)
  • Zapisz problem w dokumencie „do obejrzenia, gdy nie jest zajęty” (zazwyczaj dodaję do źródła komentarz „// TODO - wygląda na zepsuty, napraw”). Regularnie zajmij dzień (próbuję raz w miesiącu), aby przejrzeć listę i odpowiednio ją zalogować - żądanie funkcji, zgłoszenie błędu, omówienie z menedżerem itp.

Z biegiem czasu znalazłem wiele poprawek jako przydatnych. Na przykład:

• W bardziej sztywnych środowiskach mogę po prostu zlecić zespołowi testującemu zgłaszanie błędów - poproś testera, aby spotykał się ze mną co godzinę co jakiś czas, przekaż mu listę problemów i poproś o wykonanie logowania. W środowiskach, w których rejestrowanie testów jest dużą sprawą, zwykle tester będzie zadowolony z bezpłatnego zwiększenia wydajności.
• Niektóre zespoły nie zezwalają na poprawki, które nie zawierają raportu o błędzie klienta. Trzymam projekt pełen poprawek z boku i natychmiast zatwierdzam je, gdy klient zgłosi odpowiedni problem, aby otrzymać bezpłatne punkty brownie.
• Niektóre zespoły wymagają, aby osoba „posiadająca” fragment kodu była tą, która wykonuje poprawki. Traktuję „właściciela” kodu jak przewód testowy i spotykam się nieformalnie, aby od czasu do czasu przekazać problemy

Uważam, że generalnie, gdy postępujesz zgodnie z tego typu strategią, coraz więcej współpracowników i innych członków firmy zacznie szanować twoją pracę i zaangażowanie w jakość. Po upływie określonego czasu będziesz mieć szacunek i autorytet wymagany do zoptymalizowania całego procesu według własnych upodobań. Uważaj na takie możliwości i wykorzystaj je odpowiednio.

Uważam, że jeśli programista napotka błąd, który nie jest związany z tym, co pracują i że nie będzie naprawiał, powinien wprowadzić go do systemu, aby mieć jakiś zapis. W ten sposób, gdy QA rozpocznie testowanie (i nadal nie są naprawione), możesz nadać im listę błędów jako „znane wady”, aby nie zaczęli zgłaszać tych samych błędów.

Być może inni programiści, którzy znajdą błędy, sami je śledzą, jeśli planują to naprawić, ale w takim przypadku ryzykują, że 2 programistów samodzielnie znajdzie i naprawi ten sam błąd.

Dodałbym, że nawet jeśli błąd został już naprawiony (co nie powinno się zdarzyć przed zarejestrowaniem go w narzędziu do śledzenia problemów), dobrze jest go wyśledzić.

W ten sposób, jeśli problem pojawi się ponownie w przyszłości (zdarzają się regresy!), Stosunkowo łatwo jest rozpoznać problem jako „już rozwiązany” i przeczytać, jak został rozwiązany za pierwszym razem.

Dlaczego? Ponieważ większość programistów patrzy na problem, który muszą poruszyć i kod, który muszą napisać, i uważa, że ​​łatwiej jest nie zawracać sobie głowy.

Ale to, czy jest to właściwe, zależy od twojego procesu. Czy masz zespół kontroli jakości? Czy sądzisz, że mają coś przeciwko, jeśli zmienisz kod, który nie będzie śledzony? Co z recenzjami kodu? Czy przeskoczy przez ten trzask? Co z biznesem? Czy muszą wiedzieć, że naprawiłeś błąd, aby później go nie zgłaszać?

Co z innymi programistami? Co jeśli naprawią to w inny sposób w tym samym czasie? Co, jeśli później znajdą podobny błąd, a wszystko, co możesz zrobić, to powiedzieć „och, cholera, wiem, że mieliśmy już coś takiego - teraz co to było?”

Istnieje około miliona powodów rejestrowania błędów w systemie śledzenia błędów. Jeśli masz pewność, że nie trafiłeś w żaden z tych problemów, to nie przejmuj się. Ale jeśli w ogóle nie jesteś pewien, powinieneś to nagrać, nawet jeśli większość ludzi tego nie robi.

Programowanie jest zasadniczo złożoną pracą. Błędy są złożone. więc oceniałem błąd na podstawie dwóch czynników:

1. Jak często tego rodzaju błędy mogą pojawiać się ponownie w przyszłości? Niezależnie od tego, czy ta prognoza jest dokładna, czy nie, nadal ją szacuj.
2. Kiedy takie błędy pojawiają się ponownie, czy łatwo to zrozumieć? Jest to dokładne, kiedy analizujesz ten błąd i naprawiasz go.

Zaklasyfikowałbym błąd do jednego z następujących typów:

1. Prawdopodobnie pojawią się ponownie w przyszłości i są łatwe do zrozumienia
2. Prawdopodobnie pojawią się ponownie w przyszłości, ale trudne do zrozumienia
3. Rzadko pojawiają się ponownie w przyszłości i są łatwe do zrozumienia
4. Rzadko pojawiają się ponownie w przyszłości, ale trudne do zrozumienia

W przypadku 1 książka kucharska lub FAQ to dobre urządzenie dla zespołu, aby w przyszłości naprawić takie błędy.

W przypadku 2, skomplikowany i zrozumiały zapis jest niezbędny dla zespołu, ponieważ strata wysiłku, jeśli inny programista znosi takie błędy. Na przykład: wyciek pamięci.

W przypadku 3 myślę, że nie jest wielkim problemem, że nie ma już nic do nagrania, ponieważ nie poświęcisz zbyt wiele czasu na naprawienie łatwego błędu. Na przykład literówka dla id elementu w HTML.

W przypadku 4 takie błędy tworzą dylemat. Potrzebuje trochę czasu, aby napisać skomplikowany i zrozumiały zapis, aby opisać takie błędy. Ale ten zapis jest rzadko używany w przyszłości. Jednak bez zapisu pojawienie się takich błędów byłoby walką ponownie. Na przykład takie błędy pojawiają się z powodu wirusa komputerowego na czyimś komputerze.

Oczywiście powinieneś to wprowadzić. Lub przynajmniej zgłoś to swoim pracownikom kontroli jakości, jeśli jest to normalny proces.

Nawet jeśli sam naprawisz błąd, będziesz potrzebować zapisu zmiany, aby można go było przetestować, aby upewnić się, że poprawka rzeczywiście działa i że nie wystąpiła regresja. Możliwe jest również, że użytkownik może zgłosić błąd w pewnym momencie, a jeśli jest on w systemie i oznaczony jako naprawiony, pracownicy wsparcia mogą powiedzieć mu, że został już rozwiązany.

Rzeczywiście powinieneś nagrywać je w systemie, a jeśli nie jest to praktykowane, dobrze jest zacząć.

W przeszłości należałem do zespołu ds. Produktu i pracowaliśmy nad wersją beta nowego produktu, a czasami czasami znajdowaliśmy błędy, które w tym momencie notowaliśmy i wysyłaliśmy pocztą do odpowiednich osób obsługujących moduły (mieliśmy system śledzenia błędów, ale nie myśleliśmy o tym, aby je tam przenieść). Później, gdy dni mijały, elementy w poczcie zaczęły być ignorowane z powodu innych priorytetów, co w końcu doprowadziło do nieprzespanych nocy.

A więc, uderz się pewnego dnia, Nirvana! Dlaczego nie używamy narzędzia do śledzenia błędów, nawet jeśli znalazłeś coś, co wydaje się błędem i możliwe, że to nie jest jeden (twoja myśl o tym procesie jest błędna / wadliwa). Przynajmniej nadrabia zaległości na liście, którą następnie można przetestować i najważniejsze ze wszystkich opinii na temat tego, dlaczego jest to krytyczne lub z drugiej strony jest idealne i tak powinno działać z powodów 1 ... 2 ... .

Teraz masz listę, a także dla tych, którzy źle zrozumieli niektóre części aplikacji, mają informacje zwrotne, na podstawie których mogą wyjaśnić swoje myśli. Sytuacja wygrana-wygrana.

Zakładając, że jego już przetestowany (a zwłaszcza jeśli wydany) kod jest absolutnie.

Istnieje wiele powodów:

Pamięć - naprawdę mało prawdopodobne jest, aby system zapomniał o błędzie, jakikolwiek programista.

Metryki - Liczba znalezionych, zamkniętych błędów i poświęcony czas mogą być dobrymi, łatwymi do przechwycenia metrykami, informującymi o postępie jakości kodu

Pilność - może to wydawać się najważniejszą rzeczą na świecie dla programisty, jednak czas poświęcony na naprawienie tego problemu można lepiej poświęcić na coś, czego użytkownicy końcowi chcą najpierw (patrz także pamięć).

Duplikacja - być może została już zauważona i jest sprawdzana / naprawiana przez kogoś innego. Ewentualnie być może naruszył zasadę pilności i został odłożony. Oczywiście fakt, że znalazłeś go ponownie, nie tylko oznacza, że ​​nie należy tego robić, może również oznaczać, że (w miarę pojawiania się) jest teraz bardziej pilne do naprawienia.

Analiza przyczyn źródłowych - najłatwiejszym do naprawienia błędem jest ten, którego nigdy nie było. Być może zespół powinien przyjrzeć się temu błędowi, aby dowiedzieć się, jak to się stało. Jest to zdecydowanie nie karanie odpowiedzialnego (co nigdy nie pomaga), ale ustalenie, w jaki sposób można uniknąć tej sytuacji w przyszłości.

Szersza analiza wpływu - najtańszym znalezionym błędem jest ten, o którym wiedziałeś, zanim go znalazłeś. Patrząc na ten błąd (szczególnie po przeprowadzeniu analizy przyczyn źródłowych), można szybko stwierdzić, że problem ten może występować w innych miejscach kodu. W rezultacie zespół może zdecydować się go znaleźć, zanim podniesie brzydką głowę w bardziej zawstydzającym momencie.

Ilość czasu poświęcanego na te (jeśli w ogóle) zależy w dużej mierze od dojrzałości i poziomu jakości kodu. Analiza przyczyn źródłowych prawdopodobnie będzie przesadą dla małego zespołu pracującego nad kodem demonstracyjnym, ale duży zespół zajmujący się krytycznym rozwojem biznesu prawdopodobnie musi nauczyć się lekcji skutecznie i wydajnie.

Z doświadczenia wynika, że ​​istnieją dwa ogólne powody, dla których programiści unikają używania tego narzędzia:

1. Narzędzie do obsługi błędów i / lub proces są postrzegane jako zbyt ciężkie dla rozwoju
2. Dla programistów wyzwanie naprawienia błędu jest bardziej interesujące niż rzeczy, nad którymi obecnie pracują.

Punkt 1 oznacza, że ​​może być wymagany lepszy / prostszy system; lub alternatywnie bardziej uzasadnione może być uzasadnienie istniejącego systemu.

Punkt 2 powinien być użytecznym znakiem ostrzegawczym dla lidera ds. Rozwoju przed bieżącymi przydziałami zadań.

W większości zgadzam się z FrustratedWithFormsDesign, ale myślę, że jest jeszcze jaśniej, jeśli cały problem zostanie podzielony na dwa obszary:

• Zgłaszanie błędów.
• Naprawa błędów.

Często są one traktowane jako takie same, a ich rozdzielenie prawie na pewno bardzo pomoże.

Można sobie z tym poradzić za pomocą: Raportowania błędów: - umieść go w systemie, jak wszyscy mówią.

Naprawianie błędów: - Co tydzień lub dwa (dostosuj do harmonogramu rozwoju itp.) Wszyscy spotykają się przy projekcie i decydują, co należy naprawić, przez kogo itp. To było, że wszyscy są na tej samej stronie i mogą zobaczyć, co należy będzie zrobione. W Agile Development jest to spotkanie planowania sprintu.

Dobre narzędzie, z którego ludzie chcą korzystać, również robi dużą różnicę. Lubię Pivotal Tracker, który przeszedł mój test „naprawdę użytecznego narzędzia”, kiedy zacząłem go używać, aby śledzić rzeczy, które chcę robić lub naprawiać w moich prywatnych projektach!

Jeśli coś zobaczysz, powiedz coś!

Wpisuję nawet raporty o błędach dotyczące moich własnych modułów, ponieważ nie chcę przerywać bieżącego zadania. I mogę zapewnić, że wszystkie kroki do odtworzenia są uwzględnione :-)

Jeszcze lepiej, gdy ktoś inny zobaczy, że wymieniono coś jako znany błąd. Lubią wiedzieć, że ktoś to znalazł.

Myślę, że jest to bardziej pytanie polityczne niż pytanie o najlepszą praktykę.

• czy sombody z winy błędów?
• Czy klient może odczytać wpisy błędów i widzi, że są dodatkowe błędy. Czy jest to kwestia reputacji Twojej firmy?
• czy to naprawdę błąd lub funkcja, o której nie wiesz?
• kto będzie płacił poprawkę?

Moim zdaniem dobrą praktyką jest dodawanie nietrywialnych błędów do systemu śledzenia, ale kierownictwo musi zdecydować, jak sobie z tym poradzić.

W przypadkach innych niż trywialne nie powinieneś naprawiać problemu bez konsultacji z kimś innym, aby się upewnić

• to naprawdę błąd, a nie funkcja
• sombody może przetestować poprawkę i upewnić się, że poprawka nie wprowadza nowego błędu w innym miejscu (regresja)