Jak śledzisz błędy w swoich osobistych projektach? [Zamknięte]

Próbuję zdecydować, czy muszę ponownie ocenić proces śledzenia defektów w przypadku moich domowych projektów. Przez ostatnie kilka lat naprawdę po prostu śledzę defekty za pomocą TODOznaczników w kodzie i śledzę je w określonym widoku (używam Eclipse, który ma przyzwoity system tagowania).

Niestety zaczynam się zastanawiać, czy ten system jest niezrównoważony. Wady, które znajduję, są zazwyczaj związane z fragmentem kodu, nad którym pracuję; błędy, które nie są od razu zrozumiane, są zwykle zapominane lub ignorowane. Napisałem aplikację dla mojej żony, która miała poważną wadę od prawie 9 miesięcy, i ciągle zapominam o jej naprawieniu.

Jakiego mechanizmu używasz do śledzenia defektów w swoich osobistych projektach? Czy masz określony system lub proces ustalania priorytetów i zarządzania nimi?

Fogbugz (bezpłatna licencja indywidualna), jeśli jest to długi projekt lub lista rzeczy do zrobienia (przy użyciu zadań Google)

Zwykle używam internetowego systemu kontroli wersji (Github, Bitbucket, Redmine, Google Code, ...) do przechowywania mojego kodu źródłowego i śledzenia błędów. Jeśli uważasz, że w konkretnym kodzie jest błąd, możesz utworzyć problem z numerem wersji / listą zmian / zestawem zmian i określić, który plik i zakres linii podejrzewasz.

Kiedyś korzystałem z arkusza kalkulacyjnego / pliku tekstowego dla każdego projektu (komentarze ToDo w kodzie nie skalują się dobrze z powodów, które wymieniasz; są lokalne dla kodu, a jeśli występuje problem, który nie jest, prześlizguje się przez pęknięcia).

Ostatnio skonfigurowałem serwer Redmine w mojej sieci domowej. Jest to trochę ciężkie dla „zespołu” jednego, ale pracuję nad kilkoma projektami na swój własny czas i zwykle używam opcji śledzenia problemów + opcji repozytorium z być może dziwną stroną wiki w bardziej złożonych miejscach.

Mój przyjaciel przysięga Pivotal Tracker do tych samych celów, ale mój obecny pracodawca używa Redmine wewnętrznie, więc pomyślałem, że to da mi trochę praktyki. Nie jest źle.

W przypadku projektów typu open source używam tylko śledzenia problemów GitHub.

Naprawdę zainstalowałem darmowy system śledzenia błędów MANTIS na moim hostowanym serwerze internetowym (którego używam na blogu i innych rzeczach) i włożyłem w to wszystkie swoje wady.

Innymi słowy, prowadzę moje rzeczy tak, jakby były profesjonalne i za które płacono.

Uważam, że pomaga to w utrzymaniu lepszego sposobu myślenia (zamykanie wad itp.), A także jest spójne z innymi praktykami powszechnie stosowanymi w przemyśle.

Używaj też notatek TODO w kodzie itp. - ale tylko w przypadku notatek z samego siebie, takich jak: „pewnego dnia muszę to uczynić bardziej wydajnym, sortowanie bąbelkowe szkodzi wydajności”. Lub bardziej natychmiastowe notatki o tym, gdzie wstałeś, kiedy zostałeś zabrany na obiad :)

Używam programu ToDo List, otwartego kodu źródłowego z projektu kodowego

http://www.codeproject.com/KB/applications/todolist2.aspx

Bardzo fajnie iz wieloma funkcjami.

Używamy JIRA w moim miejscu pracy i jestem jej wielkim fanem. Wiele produktów i zaangażowanych ludzi, a wszystko to w porządku.

Przyszedłem szukać odpowiedzi na to jakiś czas temu i od tego czasu opracowałem bardzo schludny i prosty system, który spełnia te kluczowe dla mnie cele:

Cele w kolejności według ważności:

1. Umożliwienie bezproblemowego wprowadzania nowego zadania / błędu, dzięki czemu mogę zapisać go, gdy tylko go zauważę lub wymyślę, i wrócić do kodowania, zanim stracę swoje miejsce.
2. Ułatwiaj przeglądanie problemów i zarządzanie nimi bez konieczności częstego wyszukiwania, klikania i drążenia.
3. Ułatw sobie łączenie się z kontrolą wersji, aby później dowiedzieć się, jakie zmiany zostały wprowadzone w celu rozwiązania problemu lub jakie zadanie lub błąd spowodowały określoną zmianę w kodzie.
4. Uczyń go stosunkowo łatwym w konfiguracji: minimalna instalacja i konfiguracja oraz minimalna cena.

(3 i 4 są mniej ważne, i byłbym w porządku z systemem, który ich nie dostarczył, ale ten robi).

Krok 1: Uzyskaj projekt w Bitbucket

Używam bitbucket do śledzenia problemów i kontroli wersji git (na przykład dla projektu iOS w XCode). Patrzyłem na FogBUGz (o którym czytałem od lat na JoelOnSoftware) i GitHub i innych, ale bitbucket wydaje się mieć najlepsze darmowe funkcje ustawione dla małych zespołów.

Krok 2: Użyj śledzenia problemów Bitbucket w projekcie

Następnie skonfigurowałem śledzenie problemów w tym samym projekcie bitbucket. Więc mój projekt ma teraz repozytorium git i śledzenie problemów.

Krok 3: Ułatw śledzenie problemów!

W tym celu używam kart Bitbucket, które są ładnym, prostym interfejsem przypominającym kanban do problemów z Bitbucket. Musisz tylko zalogować się na swoje konto Bitbucket i skonfigurować kolumny, które chcesz. Mam cztery kolumny: Backlog, Next, Bugs i Resolved. (Myślę o połączeniu błędów z zaległościami, ale na razie nieważne)

(Ten obraz pochodzi z bloga Karty Bitbucket, a nie z mojego projektu, dlatego kolumny różnią się od tych, których używam)

Karty Bitbucket pozwalają skonfigurować bardzo prosty filtr dla każdej listy, w której wybierasz status (y) i rodzaj (y) problemów, które pojawiają się w kolumnie karty. Tego openrodzaju problemy ze statusem bugtrafiają do kolumny Błąd .

(Ten jest z mojego projektu: tak wybieram to, co jest w kolumnie Błąd)

Naprawdę fajne jest to, że przeciągnięcie i upuszczenie karty z jednej kolumny do drugiej spowoduje automatyczną zmianę statusu problemu reprezentowanego przez kartę, aby pasował do tego w definicji kolumny docelowej.

Kolejną fajną rzeczą w Bitbucket Cards jest to, że nie upływa łatwo. Jest to kluczowe, ponieważ celem tego całego zestawu jest ułatwienie - więc ten system działa dla mnie, a nie dla mnie. Otwieram zakładkę stronę mojej karty i pozostaje otwarta na karcie Chrome przez cały dzień.

To zajmuje mój drugi cel.

Krok 4: Połącz to z kontrolą wersji.

Problemy z bitbucketem ściśle łączą się z kontrolą wersji (jak w przypadku większości konkurentów), więc kiedy skończę pracować nad problemem, popełniam go git z komunikatem „Dodałem coś do tego. Naprawiono # 245”. Jeśli to zrobię, to popchnę, a następnie załaduję ponownie stronę z kartami Bitbucket, zobaczę, że problem został przeniesiony do kolumny Rozwiązane. Chłodny.

Mój trzeci cel został osiągnięty.

Krok 5: UŁATWNIJ TWORZENIE problemów.

Prawdopodobnie myślisz, że cała ta konfiguracja jest już zbyt skomplikowana i dlaczego miałbym chcieć dodać kolejną aplikację internetową do tego procesu. Cóż, pamiętaj o moim głównym celu powyżej: chcę, aby dodawanie zadania było tak łatwe, że nie tracę rozumu, zanim przejdę do pola tekstowego, aby go wpisać, ani nie chcę stracić swojego miejsca w kod, zanim skończę.

Teraz karty Bitbucket pozwalają mi dość łatwo tworzyć zadania , ale wystarczy kliknięcie / przewijanie, aby w pełni osiągnąć cel # 1. Musisz kliknąć Utwórz problem; wtedy pojawia się edytor modalny; po wprowadzeniu tytułu wydania należy przewinąć w dół, aby określić rodzaj (błąd / zadanie) i priorytet; następnie kliknij Utwórz.

Zamiast tego zdecydowałem się użyć drugiej aplikacji Bitbucket o nazwie taskrd .

Możesz skonfigurować taskrd, podając login Bitbucket, ustawić go w zakładce i zakładce i pozostawić otwarty przez cały dzień, podobnie jak karty Bitbucket. Taskrd ma znacznie prostszy przepływ pracy w przypadku dodawania nowego zadania, wystarczy wpisać je, opcjonalnie ustawić rodzaj i priorytet, a następnie nacisnąć przycisk Dodaj.

(ten obraz pochodzi z bloga Taskrd)

Teraz można argumentować, że nie warto próbować konfigurować Taskdda za pomocą kart Bitbucket, a nawet własnego systemu wprowadzania problemów. W końcu w Taskrd muszę kliknąć kartę w przeglądarce i kliknąć Przeładuj na mojej stronie z kartami Bitbucket, aby ją odświeżyć i uzyskać nowy problem, który dodałem w aplikacji Taskrd. Ale w rzeczywistości stwierdzam, że ogólnie jestem w trybie lub innym: albo używam kart Bitbucket do organizowania tego, co robię dalej, lub do przeglądania listy błędów, albo jestem zajęty kodowaniem i wprowadzaniem zadań / błędy, jakie mi się pojawiają - wszystko w trybie szybkiego ognia. W tym drugim trybie pracy Taskrd jest świetny: po prostu trzymam go otwarty na osobnym monitorze i szybko wprowadzam problemy podczas pracy.

To obejmuje cel nr 1.

Moim ostatnim celem było ustawienie łatwe / tanie. Cóż, jest tanie: wszystko to jest bezpłatne. Bitbucket ma bezpłatne prywatne repozytoria dla maksymalnie pięciu użytkowników, a pozostałe aplikacje były bezpłatne. Konfiguracja wydaje się nietrywialna w oparciu o powyższe, ale tak naprawdę najbardziej skomplikowaną częścią było skonfigurowanie git do przesyłania do repozytorium bitbucket, które będzie wszędzie takie samo. Nie musiałem niczego instalować, a połączenie obu aplikacji z moim repozytorium bitbucket było dość łatwe. Ustawienie kolumn z kartami, które lubiłem, wymagało trochę zabawy, ale nie było naprawdę trudne.

Czytając to, mógłbym poczuć się trochę dreszczem dla Bitbucket - ale tak naprawdę nie zamierzam tego robić. Po prostu używam tego procesu od tygodni - po latach próbowania różnych konfiguracji w celu śledzenia tego, co robię - i naprawdę go kopię, więc pomyślałem, że poświęcę trochę czasu, aby rozłożyć to na innych.

Jeśli znasz się na używaniu tagów TODO w Eclipse, prostym krokiem byłoby użycie Mylyn . Najprościej mówiąc, jest to prosta lista rzeczy do zrobienia. Ale wiąże też kontekst z zadaniami - kliknij zadanie, aby je aktywować, zrób kilka rzeczy, a następnie następnym razem, gdy je aktywujesz, Eclipse otworzy odpowiednie klasy i pokaże odpowiednie metody. Jeszcze mocniej, jeśli ostatecznie przejdziesz na inny system śledzenia błędów, Mylyn może pobierać zadania z tych systemów i prezentować je w twoim IDE.

Większość plików do pobrania Eclipse jest obecnie w pakiecie Mylyn. Wystarczy wyszukać widok Listy zadań i rozpocząć dodawanie zadań.

Używam licencji Jira na 10 USD. Jest tani i już dobrze go znam z pracy.

Podobnie jak inni tutaj używam pliku tekstowego lub narzędzia do śledzenia błędów wbudowanego w dowolną usługę hostingową dvcs.

Wiele zależy od tego, jaki to „osobisty projekt”. Czy jest to coś, co ujrzy światło dzienne, czy to tylko eksperyment? Czy ten projekt jest używany przez społeczeństwo?

Na przykład jeden z moich osobistych projektów stał się umiarkowanie popularny i utworzenie witryny Get Satisfaction działało naprawdę dobrze. Nie do końca „śledzenie błędów”, ale świetnie sprawdzało się w przypadku żądań błędów / funkcji.

Nieco zaskoczony, nikt jeszcze tego nie powiedział, ale istnieją rozproszone rozwiązania do śledzenia błędów, które działają w ramach rozproszonej kontroli źródła, tj. Baza danych błędów zawiera kod w kontroli wersji. Dobrze znane wdrożenia obejmują „Bugs Everywhere”, Fossil i Ditz.

Zobacz https://stackoverflow.com/questions/773818/distribut-projectmanagement-bug-tracking i https://stackoverflow.com/questions/1851221/distribution-bug-tracker-to-go-with-dvc?rq=1 do dyskusji.

Do moich osobistych projektów używam Omnifocus.

Aktualizacja: 25/10/2010 Jeśli znajdę błąd, którego nie mogę lub nie chcę natychmiast naprawiać, szybko dodam go do skrzynki odbiorczej Omnifocus. Później, kiedy robię recenzję, zgromadzę wszystkie informacje, które moim zdaniem będę musiał naprawić, a następnie dodam do projektu. Jego pozycja na liście zadań wskazuje na jej względne znaczenie.

Pod wieloma względami robaki traktuję tak samo jak wymagania / funkcje.

W przypadku projektów osobistych zazwyczaj wystarczają mi komentarze do zrobienia TODO oraz plik tekstowy z TODO i błędami itp.

Używam własnego TheKBase (ponieważ jestem na OSX, używam go w .Net na maszynie wirtualnej lub Mono, w zależności od mojego nastroju). Tylko dla jednego współbieżnego użytkownika, ale: Pozwala na wiele hierarchii, więc przechodzi od menedżera zadań do menedżera informacji, nie tracąc żadnych kroków pomiędzy nimi. Plus jest open source na Github i za darmo (to chyba oczywiste).

Dla ciekawskich instrukcje są tutaj .

Używam ToDoList do moich osobistych projektów; jest lekki, bezpłatny i ma wiele funkcji. Nie jestem pewien, jak dobrze skaluje się w projektach zespołowych, ale świetnie jest dla mnie pracować sam. Nie jestem pewien, jak przetrwałem, używając tak długiej listy zadań wbudowanej w Visual Studio, to bzdura.

Używamy kombinacji JIRA oraz Dokumentów i Arkuszy Google. Spojrzałem na inne narzędzia, ponieważ nasza instalacja JIRA jest starsza niż brud i nie jest tak łatwa w użyciu, jak nowsze, bardziej zaawansowane interfejsy typu „przeciągnij i upuść”.

Zajrzałem do Manymoon, Zoho Projects, Insightly, Redmine i Assembla. Będziemy eksperymentować z darmowym narzędziem Stand Up w Assembla . Jest to bardzo prosty 3-polowy interfejs raportowania, który zadaje każdemu członkowi zespołu 3 pytania: co robiłeś w zeszłym tygodniu? Co będziesz robić w tym tygodniu? Jakie przeszkody ci przeszkadzają?

Ostatecznie myślę, że pozostanę przy JIRA, Dokumentach Google i narzędziu Assembla Stand Up, ponieważ kombinacja daje mi wszystko, czego potrzebuję.

Najbardziej podoba mi się Trac, ponieważ jest lekki, łatwy w użyciu i łatwy w konfiguracji. Zintegrowane wiki i elegancka przeglądarka repozytoriów to duży plus.

W pracy korzystamy z JIRA, która jest również całkiem przyjemna, ale nie tak łatwa w administrowaniu. Naprawdę brakuje mi wiki (integracja z Confluence nie jest taka świetna) i dobrej przeglądarki repozytorium (mamy tylko ViewVC).

Używam Traca od kilku lat. Użyłem również Bugzilli i JIRA. Moje osobiste i prywatne projekty konsultingowe dotyczą Traca po prostu dlatego, że jestem do tego przyzwyczajony i przygotowanie projektu w mojej osobistej konfiguracji programistów zajmuje tak mało wysiłku, ponieważ wysiłek się skończył. Mam śledzenie związane ze wszystkim, czego potrzebuję, w tym SVN, Git i Hudson (a raczej Jenkins).

W niektórych projektach klienckich na ogół nie ma wyboru, ale to, czego używają, co często wystarczy, to nic lub niektóre bzdury w domu niestety. Jestem zaskoczony, gdy ostatnio mają narzędzie do śledzenia błędów. Jednak osobiście czekam na lepszą ofertę od społeczności OSS niż Trac. Sprawia, że ​​wszystko jest załatwione, ale w dzisiejszych czasach wydaje się, że to taka mozaika.

Nie widzę sensu w używaniu formalnego śledzenia błędów dla małych jednoosobowych projektów. Zwykle po prostu przechowuję (bardzo krótką) listę mentalną i naprawiam błędy, kiedy się o nich dowiem. Oczywiście nie jest to skalowalne dla dużych / wieloosobowych projektów, ale chodzi o to, że nie trzeba.

Jeśli używasz ReSharper, ma on TODO tracker, który pokazuje listę wszystkich TODOs, NOTEs i BUGtwojego rozwiązania. Podświetla je również w kodzie w dowolnym wybranym kolorze. Uważam to za bardzo przydatne w moich własnych projektach.