Come rintracci i bug nei tuoi progetti personali? [chiuso]


45

Sto cercando di decidere se devo rivalutare il mio processo di localizzazione dei difetti per i miei progetti cresciuti in casa. Negli ultimi anni, ho semplicemente monitorato i difetti usando i TODOtag nel codice e tenendoli tracciati in una vista specifica (uso Eclipse, che ha un sistema di tag decente).

Sfortunatamente, sto iniziando a chiedermi se questo sistema non è sostenibile. I difetti che riscontro sono in genere associati a un frammento di codice sul quale sto lavorando; i bug che non vengono immediatamente compresi tendono ad essere dimenticati o ignorati. Ho scritto una domanda per mia moglie che ha avuto un grave difetto per quasi 9 mesi e continuo a dimenticare di risolverlo.

Quale meccanismo usi per tracciare i difetti nei tuoi progetti personali? Hai un sistema specifico o un processo per stabilire le priorità e gestirli?



1
Questo potrebbe essere esagerato come una domanda che la faq considera fuori tema. "Quale tecnologia è migliore?"
jzd

Trello è un ottimo strumento per questo tipo di cose ed è gratuito.
gahooa,

Risposte:


25

Fogbugz (licenza individuale gratuita) se si tratta di un progetto a lungo termine o di un semplice elenco di attività (utilizzando le attività di Google)


7
Bello. Non avevo capito che FogBugz ha una versione gratuita (chiamata Student and Startup Edition, per chi la sta cercando).
Eric King,

A prima vista, sembra molto interessante
bedwyr

Dopo aver usato FogBugz, non riesco a vedere come qualcuno preferisce qualcosa di diverso. Per non dover tenere traccia di più account fogbugz, ho appena creato un singolo fogbugz personale per me: earlz.fogbugz.com
Earlz,

17

Di solito utilizzo un sistema di controllo delle revisioni basato sul web (Github, Bitbucket, Redmine, Google Code, ...) per memorizzare il mio codice sorgente e tenere traccia dei bug. Se ritieni che ci sia un bug in un codice specifico, puoi creare un problema con il numero di revisione / elenco modifiche / gruppo di modifiche e specificare quale file e l'intervallo di linee sospetti.


8

Ero abituato a utilizzare un foglio di calcolo / file di testo per progetto (i commenti ToDo nel codice non si adattano bene per i motivi che elenchi; sono locali al codice e se c'è un problema che non lo fa, tende a scivolare attraverso il crepe).

Di recente ho installato un server Redmine sulla mia rete domestica. È un po 'pesante per un "team" di uno, ma sto lavorando a parecchi progetti sul mio tempo e tendo ad usare solo le opzioni Issue Tracker + Repository con forse la strana pagina wiki in luoghi più complessi.

Un mio amico giura di Pivotal Tracker per gli stessi scopi, ma il mio attuale datore di lavoro usa Redmine internamente, quindi ho pensato che questo mi avrebbe dato un po 'di pratica. Non è male.

Per i progetti open source, utilizzo solo il rilevamento dei problemi di GitHub.


I commenti da fare nel codice funzionano meglio se si tratta di Doxygen / annotazioni simili, a condizione che si creino regolarmente i documenti. Ottieni l'elenco raccolto di todos (e bug) nei documenti generati. Manca ovviamente le opzioni di reportistica flessibile di un tracker di bug dedicato e non cercherai vecchi bug (presumibilmente) risolti nel tuo repository quando le annotazioni vengono eliminate dalla versione corrente, ma può funzionare abbastanza bene per i piccoli progetti semplici.
Steve314,

7

In realtà ho installato il sistema di bugtracker MANTIS gratuito sul mio server web ospitato (che uso per un blog e altre cose) e ci ho messo tutti i miei difetti.

In altre parole, gestisco le mie cose come se fossero professionali e pagate.

Trovo che aiuti a mantenere una mentalità migliore (eliminando i difetti, ecc.) Oltre ad essere coerente (ish) con altre pratiche comunemente utilizzate nell'industria.

Usa anche le note TODO nel codice, ecc., Ma solo per le note migliori come: "un giorno devo renderlo più efficiente, il tipo di bolla fa male alle prestazioni". O per appunti più immediati su dove ti sei alzato quando sei stato portato fuori a cena :)


Ho usato MANTIS ed è fantastico!
Giobbe


5

Usiamo JIRA sul mio posto di lavoro e ne sono un grande fan. Un sacco di prodotti e persone coinvolte e gestisce tutto bene.


+1 Jira è di gran lunga il miglior sistema di localizzazione dei problemi in cui mi sono imbattuto. Facile da usare, impiega gradualmente funzionalità più avanzate quando necessario. Abbastanza amichevole anche per gli utenti non tecnici per segnalare e seguire i problemi.
Maglob,

Un altro elogio. Jira è uno strumento fortemente "esotermico", che dà più di quello che metti, che innesca un ciclo di feedback positivo :)
Maglob

4

Sono venuto alla ricerca di una risposta per questo qualche tempo fa e da allora ho elaborato un sistema molto pulito e semplice, che soddisfa questi obiettivi chiave per me:

Obiettivi in ​​ordine di importanza:

  1. Rendi possibile inserire un nuovo compito / bug nel modo più semplice possibile, in modo da poterlo annotare non appena lo rilevo o lo sogno, e tornare al codice prima di perdere il posto.
  2. Semplifica la visualizzazione e la gestione dei problemi senza molta ricerca, clic, drill down.
  3. Semplifica il collegamento con il controllo versione in modo da poter scoprire in seguito quali modifiche sono state apportate per risolvere un problema o quale attività o bug ha determinato una modifica specifica del codice.
  4. Renderlo relativamente facile da installare: installazione e configurazione minime e prezzo minimo.

(3 e 4 sono meno importanti, e sarei andato bene con un sistema che non li ha forniti, ma questo lo fa).

Passaggio 1: ottieni un progetto in Bitbucket

Uso bitbucket per il rilevamento dei problemi e per il controllo della versione git (ad esempio per un progetto iOS in XCode). Ho guardato FogBUGz (di cui ho letto per anni su JoelOnSoftware) e GitHub e altri, ma bitbucket sembra avere le migliori funzionalità gratuite impostate per i piccoli team.

Passaggio 2: utilizzare il rilevamento dei problemi di Bitbucket nel progetto

Successivamente ho impostato il rilevamento dei problemi nello stesso progetto bitbucket. Quindi il mio progetto ora ha un repository git e il rilevamento dei problemi.

Passaggio 3: semplifica il monitoraggio dei problemi!

Per questo sto usando Bitbucket Cards che è un simpatico e semplice front-end kanban per i problemi di Bitbucket. Devi solo accedere al tuo account Bitbucket e impostare le colonne che desideri. Ho quattro colonne: Backlog, Next, Bugs e Resolved. (Sto pensando di fondere Bugs con Backlog, ma non importa per ora)

Esempio di schede Bitbucket (Questa immagine è tratta dal blog di Bitbucket Cards, non dal mio progetto, quindi le colonne sono diverse da quelle che uso)

Bitbucket Cards ti consente di impostare un filtro molto semplice per ogni elenco in cui scegli lo stato (i) e il tipo (i) dei problemi che vanno in una colonna di carte. Quindi, i openproblemi di stato del tipo bugvanno nella colonna Bug .

Definizione di colonna (Questo è del mio progetto: è così che seleziono ciò che va nella colonna Bug)

La cosa davvero interessante è che quando trascini e rilasci una carta da una colonna all'altra, cambierà automaticamente lo stato del problema che la carta rappresenta per corrispondere a quello nella definizione della colonna di destinazione.

Un'altra cosa bella di Bitbucket Cards è che non si interrompe facilmente. Questo è fondamentale poiché lo scopo di tutto questo set up è quello di renderlo semplice, quindi questo sistema funziona per me invece che per me. Apro un segnalibro la pagina della mia carta e rimane aperta su una scheda di Chrome tutto il giorno.

Questo si prende cura del mio secondo obiettivo.

Passaggio 4: collegalo con il controllo versione.

I problemi di Bitbucket si collegano perfettamente con il controllo della versione (come per la maggior parte dei concorrenti), quindi quando ho finito di lavorare su un problema, lo commetto con un messaggio del tipo "Aggiunto il contenuto alla cosa. Correzioni # 245". Se lo commetto, quindi lo spingo, quindi ricarico la mia pagina Carte Bitbucket, vedrò che il problema è stato spostato nella colonna Risolto. Freddo.

C'è il mio terzo obiettivo fatto.

Passaggio 5: semplificare la CREAZIONE dei problemi.

Probabilmente pensi che l'intera configurazione sia già troppo complicata da configurare e perché dovrei aggiungere un'altra app Web al processo. Bene, ricorda il mio obiettivo principale sopra: voglio rendere così facile aggiungere un'attività che non perdo il filo del pensiero prima di arrivare all'area di testo per digitarlo, né voglio perdere il mio posto in il codice quando avrò finito.

Ora, Bitbucket Cards mi consente di creare attività abbastanza facilmente, ma è solo un po 'di fare clic / scrolly per raggiungere pienamente l'obiettivo n. 1. Devi fare clic su Crea un problema; quindi viene visualizzato un editor modale; dopo aver inserito il titolo del problema, scorrere verso il basso per specificare il tipo (bug / attività) e la priorità; quindi fai clic su crea.

Invece ho scelto di usare una seconda app Bitbucket chiamata taskrd .

Puoi impostare taskrd, dandogli il tuo login Bitbucket, impostarlo su un segnalibro e una scheda e tenerlo aperto tutto il giorno, proprio come le carte Bitbucket. Taskrd ha un flusso di lavoro molto più semplice per l'aggiunta di una nuova attività, basta digitarla, facoltativamente impostare il tipo e la priorità e premere il pulsante Aggiungi.

interfaccia tasrkd (questa immagine è tratta dal blog Taskrd)

Ora è discutibile che non valga la pena di impostare Taskrd sull'uso di Bitbucket Card o persino sul proprio sistema di immissione dei problemi di Bitbucket. Dopotutto, con Taskrd devo fare clic su una scheda sul mio browser e fare clic su Ricarica sulla mia pagina con Bitbucket Cards per aggiornarlo e ottenere il nuovo problema che ho aggiunto nell'app Taskrd. Ma in realtà, trovo che sono generalmente in modalità o nell'altro: o sto usando Bitbucket Cards per organizzare ciò che sto facendo in seguito, o per guardare l'elenco dei bug, o sono impegnato a scrivere codice e ad inserire attività / bug quando si presentano a me - tutto in modalità di fuoco rapido. Per questa seconda modalità di lavoro, Taskrd è eccezionale: lo tengo sempre aperto su un monitor separato e inserisco rapidamente i problemi mentre lavoro.

In modo che copra l'obiettivo n. 1.

Il mio ultimo obiettivo è stato semplice / economico. Bene è economico: tutto questo è gratuito. Bitbucket ha repository privati ​​gratuiti per un massimo di cinque utenti e le altre app erano gratuite. L'installazione sembra non banale in base a quanto sopra, ma in realtà la parte più complicata è stata configurare git per spingere nel repository bitbucket che sarà lo stesso ovunque. Non ho dovuto installare nulla e collegare entrambe le app al mio repository bitbucket è stato abbastanza semplice. Configurare le colonne di carte come mi sono piaciute ha richiesto un po 'di gioco, ma non è stato davvero difficile.

Leggendo questo, potrei essere un po 'un brivido per Bitbucket - ma non intendo davvero. È solo che sto usando questo processo da settimane - dopo anni in cui ho provato diverse configurazioni per tenere traccia di ciò che sto facendo - e lo sto davvero scavando, quindi ho pensato di dedicare del tempo a stenderlo per gli altri.


3

Se hai familiarità con l'uso dei tag TODO in Eclipse, un semplice passo sarebbe usare Mylyn . Al massimo, è una semplice lista di cose da fare. Tuttavia, associa anche il contesto alle attività: fai clic su un'attività per attivarla, fare alcune cose e poi la prossima volta che la attivi, Eclipse aprirà le classi pertinenti e ti mostrerà i metodi pertinenti. Ancora più efficacemente, se alla fine passi a un altro sistema di tracciamento dei bug, Mylyn può estrarre attività da tali sistemi e presentarle nel tuo IDE.

La maggior parte dei download di Eclipse in questi giorni hanno Mylyn incluso come standard. Basta cercare nella vista Elenco attività e iniziare ad aggiungere attività.


+1 Ho visto Mylyn, ma temo che non mi aiuterà molto più delle attività in Eclipse. I bug che trovo che non sono direttamente visibili nel codice tendono a perdersi nello shuffle, quindi è meno probabile che aggiungerei un bug a Eclipse quando non è aperto :)
bedwyr

Uso i tag TODO, quindi uso find / grep -o per farmi l'elenco delle cose da fare.
sal

3

Uso la licenza iniziale di $ 10 per Jira. È economico e lo so già bene dal lavoro.


2

Come altri qui uso un file di testo o il tracker dei bug integrato in qualunque servizio di hosting dvcs.

Molto dipende dal tipo di "progetto personale". È qualcosa che vedrà mai la luce del giorno o è solo un esperimento? Questo progetto è utilizzato dal pubblico?

Ad esempio, uno dei miei progetti personali è diventato moderatamente popolare e la creazione di un sito Get Satisfaction ha funzionato davvero bene. Non proprio "bug tracking" ma ha funzionato alla grande per richieste di bug / funzionalità.


2

Un po 'sorpreso che nessuno lo abbia ancora detto, ma ci sono soluzioni di tracciamento dei bug distribuite che agiscono come parte del controllo del codice sorgente distribuito, ad es. Il database dei bug vive con il tuo codice nel controllo di revisione. Le implementazioni ben note includono "Bugs Everywhere", Fossil e Ditz.

Vedi https://stackoverflow.com/questions/773818/distributed-projectmanagement-bug-tracking e https://stackoverflow.com/questions/1851221/distributed-bug-tracker-to-go-with-dvc?rq=1 per una discussione.


1

Per i miei progetti personali utilizzo Omnifocus.

Aggiornamento: 25/10/2010 Se trovo un bug che non posso o non voglio risolvere immediatamente, lo aggiungo rapidamente alla casella di posta Omnifocus. Successivamente, quando farò una recensione, raccoglierò tutte le informazioni che penso dovrò correggere il bug e quindi aggiungerle al progetto. La sua posizione nell'elenco delle attività indica la sua importanza relativa.

Tratto i bug allo stesso modo dei requisiti / funzionalità per la maggior parte degli aspetti.


2
Grazie per la risposta: ti dispiace approfondire come lo usi specificamente per il rilevamento dei difetti?
bedwyr,

Grazie per l'aggiornamento! È interessante vedere un todo-tool generale utilizzato per la gestione dei difetti.
bedwyr,

Nota: solo per prodotti Apple
Segna C

Omnifocus è un prodotto Apple ma lo uso per il mio sviluppo non Apple.
Henry,

1

Per i progetti personali, i commenti TODO e un file di testo con TODO e bug ecc. Di solito sono sufficienti per me.


1

Uso il mio TheKBase (dato che sono su OSX, lo uso su .Net in una macchina virtuale o Mono, a seconda del mio umore). Solo per un utente simultaneo, ma: consente più gerarchie, quindi passa dal task manager al responsabile delle informazioni senza passaggi intermedi. Inoltre è open source su Github e gratuito (è ovvio, immagino).

Per i curiosi, le istruzioni sono qui .


1

Uso ToDoList per i miei progetti personali; è leggero, gratuito e ha molte funzionalità. Non sono sicuro di come si adatta ai progetti di gruppo, ma è fantastico per me lavorare da solo. Non sono sicuro di come sia sopravvissuto per così tanto tempo all'elenco delle attività integrate di Visual Studio, è una schifezza.


Sui miei piccoli progetti personali, l'elenco ReSharper TODO funziona per me.
Nessuno il

1

Utilizziamo una combinazione di JIRA e documenti e fogli di lavoro di Google. Ho esaminato altri strumenti poiché la nostra installazione JIRA è più vecchia dello sporco e non è facile da usare come le interfacce più recenti, più elaborate, di trascinamento della selezione.

Ho esaminato Manymoon, Zoho Projects, Insightly, Redmine e Assembla. Sperimenteremo con lo strumento Stand Up gratuito di Assembla . È un'interfaccia di reporting a 3 campi molto semplice che pone a ciascun membro del team 3 domande: cosa hai fatto la scorsa settimana? Cosa farai questa settimana? Quali sono gli ostacoli sulla tua strada?

Alla fine, penso che continuerò a utilizzare JIRA, Google Docs e lo strumento Standla di Assembla, poiché la combinazione mi dà tutto ciò di cui ho bisogno.


1

Mi piace di più Trac, perché è leggero, facile da usare e facile da configurare. E il wiki integrato e l'elegante browser del repository sono un grande vantaggio.

Al lavoro usiamo JIRA, che è anche abbastanza carino, ma non così facile da amministrare. E mi manca davvero un wiki (l'integrazione con Confluence non è così eccezionale) e un buon browser di repository (abbiamo solo ViewVC).


Trac è un incubo da installare e configurare.

1

Uso Trac da alcuni anni. Ho usato anche Bugzilla e JIRA. I miei progetti di consulenza personale e privata coinvolgono Trac semplicemente perché ci sono abituato e per avviare un progetto nella mia configurazione di sviluppo personale richiede così poco sforzo perché lo sforzo è finito. Ho un trac collegato a tutto ciò di cui ho bisogno tra cui SVN o Git e Hudson (o piuttosto Jenkins ora).

Su alcuni progetti client non c'è generalmente altra scelta se non quello che usano, che spesso è purtroppo niente o qualche schifo in casa. Sono sorpreso quando hanno un localizzatore di bug ultimamente. Personalmente, non vedo l'ora di fare un'offerta migliore dalla community OSS di Trac. Fa cose ma in questi giorni sembra un tale patchwork.


Trac è un incubo da configurare e amministrare.

0

Non vedo il punto nell'usare il tracciamento formale dei bug per piccoli progetti individuali. Di solito tengo solo un elenco mentale (molto breve) e correggo i bug non appena ne accorgo. Ovviamente questo non si adatta a progetti di grandi / più persone, ma il punto è che non è necessario.


3
Questo è in parte il problema: un elenco mentale tende ad essere insufficiente. Molti dei miei difetti vengono registrati mentalmente e quindi persi nel tempo man mano che nuove funzionalità e miglioramenti vengono implementati.
bedwyr,

@bedwyr se ti attieni alla regola di correggere tutti i difetti noti prima di implementare nuove funzionalità, questo non è un problema.
Kevin Laity,

@ Kevin, i difetti si possono trovare nelle versioni precedenti mentre si sta lavorando sull'ultima iterazione di un progetto. Arresteresti immediatamente lo sviluppo di una funzione ad alta priorità per correggere un difetto di bassa priorità, caso maiuscolo in una versione precedente? In caso contrario, come li rintracci? Nel mio caso, un elenco mentale non è sufficiente.
bedwyr

@bedwyr Un buon punto, immagino sia una questione di preferenza. In realtà riparerei immediatamente quel difetto, poiché stiamo parlando di un piccolo progetto individuale. Se fossi in un grande contesto aziendale, storia diversa.
Kevin Laity,

0

Se usi ReSharper, ha a TODO tracker, che ti mostra un elenco di tutti gli TODOs, NOTEs e BUGs nella tua soluzione. Inoltre li evidenzia nel tuo codice in qualsiasi colore tu scelga. Lo trovo davvero utile nei miei progetti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.