Czy powinienem rejestrować trywialne poprawki?

28

Jestem w sklepie z kodami dla dwóch osób. I chociaż rozumiem, że narzędzie do śledzenia błędów jest przydatne tam, gdzie liczba programistów jest większa lub równa jedności, nie jestem przekonany, że rejestrowanie błędów, zmian i poprawek jest warte czasu, gdy są one trywialne. Kiedy znajduję prosty błąd, rozumiem go, naprawiam i przeprowadzam przez kilka testów. A potem zrozumiałem, że muszę to zalogować.

Wiem teoretycznie, że rejestrowanie błędów powinno odbywać się gdzieś między znalezieniem błędu a naprawieniem błędu, ale jeśli naprawa jest szybsza niż zalogowanie, wydaje się, że to przeciąganie. W większych sklepach z kodami szef zwraca uwagę na to, co robi, i miło jest wiedzieć, gdzie inni się bawią.

Opisuję rzeczy, które już naprawiłem, a następnie natychmiast je zamykam. Mam wątpliwości, czy ktokolwiek jeszcze raz spojrzy na ten zamknięty błąd. Czy nadszedł czas, aby przyciąć tłuszcz z procesu?

issue-tracking time-management process

— Philip
źródło

6

Gdy znajdziesz błąd, zapisz, jaki błąd był na papierze. Po naprawieniu błędu zapisz, które pliki zostały zmodyfikowane. Przed przesłaniem poprawki zaloguj błąd, a następnie prześlij zmiany. Jeśli robisz to za każdym razem, gdy nabierzesz nawyku, obecnie masz zły nawyk, rejestrowanie błędów nie jest stratą czasu.

— Ramhound

5

Jak możesz być pewien, że te błędy są trywialne?

2

@ashansky, czy w ogóle przeczytałeś drugie zdanie mojego pytania?

— Philip

1

Niezarejestrowanie własnej pracy to pewny sposób na a) nieotrzymanie uznania ib) pytanie: „dlaczego X nie jest zrobione i dlaczego pracujesz nad Y?”.

— Michael Durrant

1

Nie możesz zalogować wszystkiego, to po prostu niepraktyczne. Dlaczego niektórzy ludzie podskakują i myślą, że niektórzy jak nie logują się kilka drobnych rzeczy RÓWNY, aby wcale się nie logować ???

— Darknight

36

Należy rejestrować każdą zmianę wprowadzoną w systemie. Nie ma nic złego w logowaniu go po zdarzeniu - o ile podłączysz raport o błędzie do numeru zmiany.

Następnie, jeśli coś pójdzie nie tak, możesz wyśledzić błąd i dowiedzieć się, dlaczego dokonałeś zmiany.

W zdecydowanej większości przypadków masz rację i nikt nigdy nie będzie na nie patrzył, ale w 1 na 100, gdy coś pójdzie nie tak, ta informacja będzie bezcenna - szczególnie, jeśli problem pojawi się dopiero po 6 miesiącach.

AKTUALIZACJA

Oczywiście, jeśli nadal opracowujesz nową funkcję i odkrywasz błąd w części funkcji, o której myślałeś, że skończyłeś, nie jest konieczne rejestrowanie jej jako osobnej zmiany. W takich przypadkach logowałbym to do elementu żądającego głównej funkcji.

Gdy system z funkcją został przekazany do QA lub klienta, a następnie trzeba robić to, co opisano powyżej.

— ChrisF
źródło

W początkowej fazie rozwoju, przed wypuszczeniem pierwszej wersji z zespołu inżynierów, nie trzeba rejestrować zmian w narzędziu do śledzenia błędów. Zmiany zostaną jednak odnotowane w dziennikach kontroli wersji przy każdym przesłaniu.

— uɐɪ

@Ian To prawda, ale generalnie podczas wczesnego rozwoju (zakładając, że masz na myśli faktyczne opracowywanie, a nie prototypowanie eksploracyjne lub inne tego typu), zwykle będziesz pracować przeciwko pewnego rodzaju zestawowi funkcji. W takim przypadku każda zmiana powinna być powiązana z obsługiwanymi funkcjami. Drobne poprawki naprawiające linię do „gotowej” funkcji mogą nadal się z nią łączyć, wskazując na wsparcie tego elementu. Pamiętaj, że zależy to od sposobu śledzenia funkcji i specyfikacji.

— CodexArcanum

1

@Darknight - to nie jest łatwe! Pomaga nam w tym fakt, że korzystamy z TFS i skonfigurowaliśmy go tak, aby nie zezwalał na meldowanie się, które nie ma powiązanego elementu pracy. Tak, możesz zastąpić regułę, ale przestaje ona powodować, że myślisz o tym, co robisz.

— ChrisF

1

@Darknight Przepraszamy, ale te liczby nic nie znaczą. Mówienie, że to nie czyni prawdy; nawet gdybyś mógł to wszystko potwierdzić, więc co z tego? Jedyny wniosek, jaki mogę wyciągnąć z tych liczb, to próba ustawienia się w jakiś sposób nad innymi, co, szczerze mówiąc, wydaje się daremne, niepotrzebne i graniczne niegrzeczne / obraźliwe.

— casperOne

3

@Wszystko Weź udział w tej dyskusji na czacie.

— wałek klonowy

14

Jeśli używasz narzędzia kontroli źródła, możesz opisać błąd, który naprawiłeś w opisie zatwierdzenia, i jest to zwykle wystarczająca dokumentacja do bardzo małych, trywialnych napraw błędów.

Ponadto, jeśli korzystasz z narzędzia do śledzenia błędów / funkcji, które jest w pełni zintegrowane z kontrolą źródła i repozytoriami, takimi jak FogBugz i Kiln , będziesz mógł skorzystać z globalnego narzędzia wyszukiwania, aby znaleźć te poprawki błędów i zobaczyć, jakie zmiany kodu wprowadziłeś całkiem z łatwością.

Ponadto możesz przypisać weryfikację kodu swojemu partnerowi programistycznemu, aby mógł przejrzeć trywialną poprawkę, którą wprowadziłeś, ale ja rozpamiętuję ...

— CFL_Jeff
źródło

1

Tak, robię to. Chociaż czasami zdarza mi się, że naprawiam rzeczy, gdy jestem w oddziale i łączę je w inne zobowiązania.

— Philip

1

Dla porównania, oto połączona lista modułów do śledzenia problemów i kontroli źródła, z którymi są zintegrowane

— Matthieu

@matthieu Czekaj, Jira integruje się z SVN? Mój Boże, dlaczego tego nie robimy? Wygląda na to, że jest kilka wtyczek.

— Philip

5

Z metrykalnego punktu widzenia może być nadal przydatne.

Tych informacji można użyć, aby pokazać szefowi kilka rzeczy:

potrzebujemy więcej programistów
coś innego w tym procesie jest zepsute (dlaczego tyle błędów? czy ten drugi facet generuje większość błędów), być może pokazując, że masz za dużo błędów. Może coś to powoduje? wypuszczasz za wcześnie? czy wystarcza testowanie?
dobra lista tego, nad czym pracowałeś, przyszedł czas bonusowy.

To wszystko powiedziane, zależy od tego, jak mały błąd, o którym mówisz. Na przykład jeden z linerów, który zauważysz podczas dodawania nowego kodu, prawdopodobnie nie miałby sensu rejestrować.

— ozz
źródło

2

Staram się rejestrować każdą dokonaną zmianę, niezależnie od jej wielkości. Nigdy nie wiadomo, kiedy ty lub ktoś inny (przyszły lub teraźniejszy) będzie musiał wrócić i sprawdzić, czy ta zmiana jest możliwą przyczyną czegoś innego.

— Corv1nus
źródło

1

Śledzenie jest ważne, ale rozważ także inny scenariusz: kiedy przyjdzie czas na recenzję. Odbędzie się to formalnie osobiście lub nieoficjalnie bez ciebie poprzez szefa wyciągającego raporty z narzędzia do śledzenia błędów.

Rozważ ich „sztuczki”, które ostatecznie zwiększają twoje liczby. W końcu są to błędy, które naprawiłeś, i powinieneś zostać rozpoznany za ich naprawienie, nawet jeśli są to trywialne poprawki.

Zaloguj je.

— Steven Evers
źródło

Tak, w większych sklepach z kodami szef ma oparte na tym „metryki”, więc jest to dobra ogólna rada. Prowadzi to również do nadużywania narzędzia do śledzenia błędów i wyrzucania tych danych do piekła. Ale tutaj jestem tylko ja i drugi facet. Szef nie używa narzędzia do śledzenia błędów.

— Philip

1

Odpowiedź na to pytanie zależy od tego, gdzie jesteś.

Mogą one dotyczyć nowego projektu lub projektowanego nowego zestawu funkcji.

Projekt wstępny Jeśli znajdziesz błędy w kodzie, który stworzyliśmy podczas wstępnego projektu, wówczas utworzenie ścieżki błędów nie będzie konieczne. Proponuję osobne zatwierdzenie zmiany, abyś mógł ją łatwo odprężyć, jeśli znajdziesz problem później.

Testowanie

Kod jest zwykle wciąż niedojrzały podczas testów jednostkowych, więc chyba że zrobi to inna grupa, powiedziałbym „nie”. Jeśli testy jednostkowe przeprowadzane są przez inną grupę niż narzędzie do śledzenia błędów, dobrym sposobem jest sformalizowanie procedury testowej.

Testowanie CSCI zależy. Czy robi to inna grupa? Jeśli tak, to tak (patrz wyżej). Czy to ostatni etap testowania przed wydaniem? Zatem tak, ponieważ w tym momencie twoje oprogramowanie powinno być uważane za dojrzałe. Jeśli interesują Cię metryki, dobrze byłoby rozpocząć śledzenie błędów w tym miejscu.

Dla każdego wyższego poziomu testowania powinieneś użyć śledzenia błędów. W tych momentach oprogramowanie należy uznać za dojrzałe, dlatego ważne jest śledzenie błędów.

Wydanie

Zawsze powinieneś śledzić błędy w wydanym kodzie. Jest to ważne dla rozliczalności.

Ważne jest również usprawnienie procesu w celu dopasowania do twoich potrzeb. Czy naprawdę potrzebujesz ogromnego systemu śledzenia błędów? Czy wszystkie pola są tak ważne dla zespołu 2 osób?

— Charlie
źródło

1

Czy to możliwe, że ktoś inny może napotkać błąd, być może w starszej wersji oprogramowania, które zostało wydane światu zewnętrznemu? Jeśli tak, rejestrowanie zarówno błędu, jak i poprawki może być przydatne.

Inni sugerują, że jeśli zarejestrowanie błędu zajmuje więcej czasu niż naprawienie, nie warto rejestrować błędu. Sugeruję, aby odpowiedni przedział czasu nie znajdował się między znalezieniem błędu a naprawieniem go, lecz między momentem wprowadzenia błędu a wydaniem poprawki.

Jeśli historia zmian i wydań wskazuje, że błąd nigdy nie ujrzał światła dziennego, zalogowanie poprawki po sprawdzeniu w kontroli źródła powinno wystarczyć.

Jest to dość zbliżone do tego pytania , ale nie jestem pewien, czy to duplikat, ponieważ ten koncentruje się na trywialnych poprawkach.

— Keith Thompson
źródło

1

Dlaczego nie powinieneś śledzić błędów, autor: Jon Arid Torresdal - zamiast tego napraw je.

Podczas opracowywania: napotkasz błąd funkcji; Państwo dodać przypadek testowy, który łamie kompilacji , a następnie sprawdzić poprawki w stosunku do funkcji.
Po wydaniu: udokumentuj zachowanie . Jeśli planujesz wydanie aktualizacji, goto 1. Jeśli nie jesteś odpowiedzialny za to wydanie, przechowuj test + fix w prywatnym oddziale.

Po wydaniu kodu mogą obowiązywać inne priorytety, a naprawa błędu może być trywialna, ale sama dystrybucja poprawki może nie być ekonomiczna, chyba że wykonujesz ciągłe wdrażanie.

— Henk Langeveld
źródło

-6

Zależy jak trywialny, używam tego środka:

Jeśli trwa to dłużej , aby go zalogować niż zajęło aby naprawić to, że nie jest wart rejestrowania go.

— Ciemna noc
źródło

3

Tylko dlatego, że rejestrowanie zajmuje więcej czasu niż naprawa, nie jest wystarczającym uzasadnieniem. Ha! ten miał wyjaśnienie :)

— u

2

Nie głosowałem za tym, ale gdybym musiał zgadnąć, dlaczego ktoś tak zrobił, to dlatego, że wierzy w rejestrowanie wszystkich poprawek błędów lub myśli, że twoja odpowiedź nie była zbyt pomocna / wnikliwa.

— CFL_Jeff

3

Nie zamierzam go głosować, ale nie zgadzam się z tą ogólną zasadą (chociaż w większości przypadków widzę, że ma to sens!). Co jeśli miałeś błąd „wyłączony przez jeden błąd”, który został wysłany, ale prześlizgnął się przez sieć kontroli jakości?

— Rejestrowanie

2

Jeśli nie jest zalogowany, nie może być zweryfikowany jako ustalony przez QA

— 17 z 26

3

-1 To tylko programista arogancja (” ja nie popełniać błędów) i niewiedza (ja nie widziałem nic złego się stało z drobnymi poprawkami). Jedna naprawdę bardzo dobra awaria i wypalenie po „drobnej” poprawce zwykle pomaga w tym (znanym również jako doświadczenie).

— Michael Durrant