it-swarm-eu.dev

Jak sledujete chyby ve svých osobních projektech?

Snažím se rozhodnout, zda musím přehodnotit svůj proces sledování vad u svých domácích projektů. Za posledních několik let opravdu sleduji vady pomocí značek TODO v kódu a jejich sledování v konkrétním pohledu (používám Eclipse, který má slušný systém značkování).

Bohužel se začínám ptát, zda je tento systém neudržitelný. Vady, které najdu, jsou obvykle spojeny s fragmentem kódu, na kterém pracuji; chyby, které nejsou okamžitě pochopeny, bývají zapomenuty nebo ignorovány. Napsal jsem žádost své manželce, která měla vážnou vadu téměř 9 měsíců, a já ji zapomínám napravit.

Jaký mechanismus používáte ke sledování závad vašich osobních projektů? Máte konkrétní systém nebo proces pro určování jejich priorit a správu?

45
bedwyr

Fogbugz (bezplatná individuální licence), pokud se jedná o dlouhodobý projekt nebo jednoduchý seznam (pomocí úkolů Google)

25
Amit Wadhwa

K ukládání mého zdrojového kódu a sledování chyb obvykle používám webový kontrolní kontrolní systém (Github, Bitbucket, Redmine, Google Code, ...). Pokud si myslíte, že v určitém kódu existuje chyba, můžete vytvořit problém s číslem revize/changelist/changeset a určit, který soubor a rozsah řádků máte podezření.

17
Thierry Lam

Dříve jsem používal tabulkový/textový soubor na projekt (komentáře typu ToDo v kódu se příliš nesetkávají z důvodů, které uvedete; jsou lokální v kódu a pokud existuje problém, který není, má sklon proklouznout skrz praskliny).

Nedávno jsem v domácí síti zřídil server Redmine . Je to trochu těžká váha pro „tým“ jednoho, ale pracuji na několika projektech ve svém vlastním čase a mám tendenci používat pouze možnosti Issue Tracker + Repository s možná lichou wiki stránkou na složitějších místech.

Můj přítel přísahá Pivotal Tracker pro stejné účely, ale můj současný zaměstnavatel Redmine používá interně, takže jsem si myslel, že by mi to poskytlo nějakou praxi. To není špatné.

U projektů s otevřeným zdrojovým kódem používám pouze sledování problémů GitHubu.

8
Inaimathi

Ve skutečnosti jsem nainstaloval systém Free Mantis bugtracker na svůj hostovaný webový server (který používám pro blog a další věci) a do něj vložil všechny své vady.

Jinými slovy, provozuji své věci, jako by to bylo profesionální a za ně jsem platil.

Zjistil jsem, že to pomáhá udržovat lepší myšlení (odstraňování závad atd.) A je v souladu (ish) s jinými postupy běžně používanými v průmyslu.

Používejte také poznámky TODO v kódu atd. - ale pouze u poznámek, které jsou nejoblíbenější jako: „Jednoho dne musím toto zefektivnit, bublinové řazení bolí výkon“. Nebo pro více okamžitých poznámek o tom, kde jsi vstal, když jsi byl odvezen na večeři :)

7
quickly_now

Používám program ToDo List, otevřený zdrojový kód z projektu codeproject

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

Velmi pěkný as mnoha funkcemi.

5
Aristos

Na mém pracovišti používáme JIRA a jsem velkým fanouškem. Spousta produktů a lidí, kterých se to týká, a vše to zvládne dobře.

5
PatrickJ

Před chvílí jsem na to hledal odpověď a od té doby jsem vypracoval velmi elegantní a jednoduchý systém, který pro mě splňuje tyto klíčové cíle:

Cíle v pořadí podle důležitosti:

  1. Umožněte vstoupit do nového úkolu/chyby tak snadno, jak je to možné, abych jej mohl zapsat, jakmile to uvidím nebo snít, a vrátit se do kódování, než ztratím své místo.
  2. Usnadněte si prohlížení a správu problémů, aniž byste museli hodně hledat, klikat a vrtat.
  3. Usnadněte si spojení s řízením verzí, abych mohl později zjistit, jaké změny byly provedeny k vyřešení problému, nebo jaký úkol nebo chyba způsobila konkrétní změnu kódu.
  4. Nastavení je relativně snadné: minimální instalace a konfigurace a minimální cena.

(3 a 4 jsou méně důležité a já bych byl v pořádku se systémem, který je neposkytoval, ale tenhle ano).

Krok 1: Získejte projekt v Bitbucket

Používám bitbucket pro sledování problémů a pro kontrolu verzí git (například pro projekt iOS v XCode). Podíval jsem se na FogBUGz (o kterém jsem roky četl na JoelOnSoftware) a GitHub a další, ale zdá se, že bitbucket má nejlepší bezplatné funkce pro malé týmy.

Krok 2: Použijte sledování problému s bitbucket v projektu

Dále jsem nastavil sledování problému ve stejném projektu bitbucket. Takže můj projekt má nyní úložiště git a sledování problémů.

Krok 3: Usnadněte sledování problémů!

K tomu používám Bitbucket Cards což je pěkný jednoduchý kanban-like frontend k Bitbucket problémům. Stačí se přihlásit k účtu Bitbucket a nastavit požadované sloupce. Mám čtyři sloupce: Backlog, Next, Bugs a Resolved. (Přemýšlím o sloučení chyb s Backlogem, ale nevadí mi to prozatím)

Bitbucket Cards example (Tento obrázek pochází z blogu Bitbucket Cards, nikoli z mého projektu, proto se sloupce liší od sloupců, které používám.)

Bitbucket Cards vám umožní nastavit velmi jednoduchý filtr pro každý seznam, kde si vyberete stav (y) a druh (y) problémů, které jdou ve sloupci karty. Ve sloupci Bug jsou tedy problémy typu open typu druhu bug.

Column definition (Tento je z mého projektu: tak vyberu, co se děje ve sloupci Bug)

Skutečně skvělé je, že když přetáhnete kartu z jednoho sloupce do druhého, automaticky se změní stav problému, který karta představuje, aby odpovídal definici v cílovém sloupci.

Další pěkná věc, o Bitbucket Cards je, že to nevyprší snadno. To je rozhodující, protože cílem celé této sestavy je usnadnit - takže tento systém pracuje pro mě místo toho, abych pro něj pracoval. Otevřel jsem záložku své karty a zůstala otevřená na kartě Chrome celý den).

To se stará o můj druhý gól.

Krok 4: Spojte to s kontrolou verzí.

Problémy s bitbucketem úhledně souvisejí s kontrolou verzí (pokud jde o většinu konkurentů), takže když dokončím práci na problému, zavazuji se git zprávou jako „Přidal věc do whatsit. Opravy # 245“. Pokud se toho dopustím, pak to Push it, pak znovu načtěte stránku Bitbucket Cards, uvidím, že se problém přesunul do sloupce Vyřešeno. Chladný.

Je splněn můj třetí cíl.

Krok 5: Usnadněte VYTVOŘENÍ problémů.

Pravděpodobně si myslíte, že toto celé nastavení je již tak složité, a proč bych do procesu chtěl přidat jinou webovou aplikaci. Nezapomeňte na můj primární cíl výše: Chci, aby bylo tak snadné přidat úkol, abych neztratil svůj myšlenkový plán, než se dostanu do textové oblasti, kde ho zadám, ani nechci ztratit své místo v kód v době, kdy skončím.

Nyní, bitbucket karty mi nedovolují vytvářet úkoly poměrně snadno, ale je to jen trochu lstivé/rolovatelné, abych plně splnil cíl # 1. Musíte kliknout na Vytvořit problém; pak se objeví modální editor; po zadání čísla vydání musíte posunout dolů a určit druh (chyba/úkol) a prioritu; poté klikněte na vytvořit.

Místo toho jsem se rozhodl použít druhou bitbucket aplikaci nazvanou taskrd .

Můžete nastavit taskrd tím, že mu přihlásíte své Bitbucket přihlašování, nastavíte jej na záložku a záložku a necháte jej otevřený po celý den, stejně jako Bitbucket karty. Taskrd má mnohem jednodušší pracovní postup pro přidání nového úkolu, stačí jej zadat, volitelně nastavit druh a prioritu a stisknout tlačítko Přidat.

tasrkd interface (tento obrázek pochází z blogu Taskrd)

Nyní je diskutabilní, že nestojí za námahu nastavení Taskrdu nad použitím Bitbucket Cards nebo dokonce vlastního systému zadávání čísel Bitbuckets. Koneckonců, s Taskrdem musím kliknout na záložku v prohlížeči a kliknout na Reload na mé stránce pomocí Bitbucket Cards, aby se obnovil a získal nový problém, který jsem přidal do aplikace Taskrd. Ale ve skutečnosti jsem zjistil, že jsem obecně v režimu, nebo jiný: Buď používám Bitbucket Cards k organizování toho, co dělám dál, nebo k prohlížení seznamu chyb, nebo jsem zaneprázdněn kódováním a zadáváním úkolů/chyby, když se mi objeví - vše v rychlém režimu střelby. Pro tento 2. pracovní režim je Taskrd skvělý: Jen ho nechávám otevřený na samostatném monitoru a při práci rychle zadávám problémy.

To tedy pokrývá cíl č. 1.

Můj poslední cíl byl snadný/levný. Je to levné: vše je zdarma. Bitbucket má bezplatné soukromé úložiště až pro pět uživatelů a ostatní aplikace byly zdarma. Nastavení se zdá být netriviální na základě výše uvedeného, ​​ale ve skutečnosti nejkomplikovanější částí bylo nastavení gitu na Push do úložiště bitbucketů, které bude stejné kdekoli. Nemusel jsem nic instalovat a připojení obou aplikací k mému úložišti bitbucket bylo docela snadné. Nastavení sloupců karet, jak se mi líbilo, zabralo trochu hraní, ale nebylo to opravdu těžké.

Když jsem si to přečetl, mohl bych pro Bitbucket vypadnout jako švih - ale to opravdu nechci. Jde jen o to, že jsem tento proces používal týdny - po letech zkoušení různých konfigurací, abych sledoval, co dělám - a opravdu to kopím, takže jsem si vzal čas na to, abych to dal ostatním.

4
Rhubarb

Používám startovací licenci 10 USD pro Jiru. Je to levné a už to dobře vím z práce.

3
speshak

Pokud jste obeznámeni s používáním značek TODO v Eclipse, bylo by jednoduchým krokem nahoru použití Mylyn . Je to nejzákladnější, je to jednoduchý seznam úkolů. Ale také přidruží kontext k úkolům - kliknutím na úkol jej aktivujete, uděláte nějaké věci a poté, až ho příště aktivujete, Eclipse otevře příslušné třídy a ukáže vám příslušné metody. Ještě silněji, pokud se nakonec přesunete k jinému systému sledování chyb, Mylyn může vytáhnout úkoly z těchto systémů a prezentovat je ve vašem IDE.

Většina stahování Eclipse v těchto dnech má Mylyn jako standardní balíček. Stačí si prohlédnout zobrazení seznamu úkolů a začít přidávat úkoly.

3
RevBingo

Kinda překvapila, že to nikdo zatím neřekl, ale existují distribuovaná řešení pro sledování chyb, která fungují jako součást vaší distribuované kontroly zdroje, tj. Databáze chyb žije s vaším kódem v revizní kontrole. Mezi dobře známé implementace patří „Bugs Everywhere“, Fossil a Ditz.

Viz https://stackoverflow.com/questions/773818/distributed-projectmanagement-bug-tracking and https://stackoverflow.com/questions/1851221/distributed-bug-tracker- to-go-with-dvc? rq = 1 pro diskusi.

2
Niall Douglas

Stejně jako ostatní zde používám buď textový soubor nebo sledovač chyb zabudovaný do jakékoli služby hostování DVD.

Spousta toho závisí na tom, jaký je to „osobní projekt“. Je to něco, co někdy uvidí denní světlo, nebo je to jen experiment? Používá tento projekt veřejnost?

Například jeden z mých osobních projektů se stal středně populárním a zřídil Get Satisfaction web, který fungoval opravdu dobře. Ne opravdu "sledování chyb", ale fungovalo to skvěle pro žádosti o chyby/funkce.

2
Mike

Pro osobní projekty je obvykle dostačující TODO-komentáře a textový soubor s TODO a chybami atd.

1

Pro své osobní projekty používám Omnifocus.

Aktualizace: 25/10/2010 Pokud najdu chybu, kterou nemůžu nebo nechci opravit okamžitě, rychle ji přidám do doručené pošty Omnifocus. Později, když dělám recenzi, shromáždím všechny informace, které si myslím, že budu muset opravit chybu a poté ji přidat do projektu. Jeho pozice v seznamu úkolů naznačuje, že je to relativní význam.

Chyby chovám stejně jako požadavky/funkce ve většině ohledů.

1
Henry

Používám ToDoList pro své osobní projekty; je lehký, zdarma a má spoustu funkcí. Nejste si jisti, jak dobře se přizpůsobuje týmovým projektům, ale je pro mě skvělé pracovat sám. Nejsem si jistý, jak jsem přežil pomocí vestavěného seznamu úkolů Visual Studio tak dlouho, je to kecy.

1
Andrew Arnold

Používáme kombinaci JIRA a Google Docs and Spreadsheet. Podíval jsem se na jiné nástroje, protože naše instalace JIRA je starší než špína a není tak snadno ovladatelná jako novější, fantastická, drag and drop rozhraní.

Podíval jsem se na Manymoon, Zoho Projects, Insightly, Redmine a Assembla. Budeme experimentovat s Assembla free Stand Up tool . Jedná se o velmi jednoduché rozhraní pro hlášení v terénu, které klade každému členovi týmu 3 otázky: Co jste udělali minulý týden? Co uděláte tento týden? Jaké překážky máte v cestě?

Nakonec si myslím, že se budu držet JIRA, Google Docs a Assembla Stand Up nástroje, protože tato kombinace mi dává vše, co potřebuji.

1
jmort253

Trac se mi nejvíce líbí, protože je lehký, snadno použitelný a snadno konfigurovatelný. A integrovaná wiki a elegantní prohlížeč úložišť jsou velkým plusem.

Při práci používáme JIRA, což je také docela pěkné, ale ne tak snadné spravovat. A opravdu mi chybí wiki (integrace s Confluence není tak skvělá) a dobrý prohlížeč úložišť (máme pouze ViewVC).

1
Simon

Trac používám několik posledních let. Použil jsem také Bugzilla a JIRA. Moje osobní a soukromé konzultační projekty zahrnují Trac jednoduše proto, že jsem na to zvyklý a že projekt v mém osobním dev setupu vyžaduje tak malé úsilí, protože úsilí skončilo. Mám spojení se vším, co potřebuji, včetně SVN nebo Git a Hudson (nebo spíše Jenkins teď).

U některých klientských projektů není obecně na výběr, ale to, co používají, což bohužel často není nic, nebo bohužel v domácích blbostech. Překvapilo mě, když v poslední době mají sledovač chyb. Osobně se ale těším na lepší nabídku od komunity OSS než Trac. Dělá to věci, ale v dnešní době se jeví jako taková mozaika.

1
Johnny

Používám svůj vlastní TheKBase (protože jsem na OSX, používám jej na .Net ve virtuálním stroji nebo Mono, v závislosti na mé náladě). Pouze pro jednoho souběžného uživatele, ale: Umožňuje více hierarchií, takže jde od správce úloh k informačnímu manažerovi, mezi nimiž chybí žádné kroky. Navíc je to open source na Github a zdarma (to je zřejmé, myslím).

Pokyny pro zvědavé jsou zde .

1
Dan Rosenstark

Pokud používáte ReSharper, má TODO tracker, která vám zobrazí seznam všech TODOs, NOTEs a BUGs ve vašem řešení. Také je zvýrazní v kódu v libovolné barvě, kterou si vyberete. Považuji to za skutečně užitečné na svých vlastních projektech.

0
Nobody

Nevidím smysl používat formální sledování chyb pro malé projekty jednoho člověka. Obvykle si ponechám (velmi krátký) mentální seznam a opravím chyby, jakmile si je uvědomím. To samozřejmě není měřítko pro velké/multi-personální projekty, ale jde o to, že to nemusí.

0
dsimcha