Si sentono frustrati, delusi o addirittura non ammettono affatto?
Non so come i più programmatori si sentano riguardo ai loro bug, solo come faccio io e alcuni dei miei colleghi (passati / presenti).
Fortunatamente quasi tutti quelli con cui ho lavorato finora (incluso me stesso) erano ed è un realista: creiamo bug, è un dato di fatto. L'unico modo per evitare di produrre bug software è non scrivere del tutto del codice. Quindi l'importante è non cercare di evitare di commettere errori, ma piuttosto di imparare dai nostri errori e fare ciò che è necessario per impedire che si ripetano . In questo modo, errori e bug possono essere trasformati in una grande opportunità per imparare qualcosa (su noi stessi, il team, la lingua, gli strumenti / framework utilizzati ecc.) E migliorare le cose (abitudini di codifica, comunicazione, processi, ecc.).
Quest'ultimo aspetto è particolarmente importante perché gli errori maggiormente preoccupati sono quelli che riescono a passare alla produzione e causare problemi reali ai clienti. Questo è il motivo per cui abbiamo test / revisioni di codice / dipartimento QA ecc. Ogni volta che un insetto scivola attraverso questi scudi, è un segno evidente che c'è un buco nella nostra difesa.
Per problemi non banali, è una buona idea fare retrospettive o analisi post mortem per recuperare la vera causa alla radice del problema, in modo che possa essere affrontato. Questo è spiegato da un ottimo esempio di Joel in Five Whys .
In realtà mi sento felice. Quando trovo il mio insetto, posso scrivere un test ed essere sicuro che non lo farò mai più. Questo mi dà più fiducia nel mio lavoro.
Nessuna delle precedenti.
I bug sono un dato di fatto, non c'è motivo di sentirsi frustrati o delusi. La cosa migliore da fare è ammettere di aver commesso un errore e di prendere provvedimenti per correggerlo.
Un bug è una differenza rispetto al comportamento desiderato del programma, che capita a tutti.
Le emozioni coinvolte derivano principalmente dalla quantità di problemi derivanti da detta differenza. C'è una grande differenza tra un errore di spelling e il risveglio a 3 A.M. essere raccolto da un elicottero e portato alla tua scrivania per ripararlo.
EDIT: O peggio, un elicottero ti vola sulla scrivania ...
C'è qualche frustrazione iniziale che presto passa. Se influisce su ciò che un utente sta facendo e fa perdere molto tempo, ne sono più infastidito. Ti piacerebbe pensare di prenderli prima.
Mi piacerebbe pensare di essere il padrone di tutti i miei errori e di essere poco utile per le persone che non lo fanno (non solo i programmatori).
Bene, dipende tutto dal tipo di bug e quando è stato catturato.
I bug di Bonehead (cioè, molto semplice da individuare / trovare) vanno bene fintanto che sono io a catturarli. Se passo un bug di bonehead al team di QA, tendo ad essere un po 'seccato con me stesso.
I bug funzionali sono un dato di fatto. Non mi sento frustrato o infastidito da loro. Solo qualcosa su cui accettare e andare avanti.
Adoro i bug di comportamento inattesi quando il QA me li porta. "Davvero, lo fa? Dolce." Non sono tanto un fan di loro quando ricevo una chiamata di supporto su di loro nel bel mezzo della notte però. ;)
Quindi ci sono i bug che sono vissuti nel codice così a lungo che devono essere considerati feature. Quando passi dei giorni a debuggarlo per rintracciarlo e alla fine uccidere quello stupido bug che nessun altro vorrebbe toccare, penso che tu ti senta euforico. Vuoi solo dire a qualcuno quando hai risolto un errore del genere.
Ma i bug sono separati dallo sviluppo. Non puoi definirti uno sviluppatore se non ti occupi di bug. Ottenere il tuo codice per lavorare in tempo e budget, riducendo al minimo il numero di bug di cosa si tratta. :)
I bug stanno per accadere, come l'arrivo della marea. Se c'è frustrazione, di solito viene da una mancanza di comprensione da parte dei miei colleghi / capo che queste cose sono normali.
Tuttavia, per quanto possa sembrare stupido, rivedere il codice che ho scritto di recente (attendere almeno 10 minuti dopo la revisione) aiuta molto. Scrivere un codice per anticipare strani input aiuta anche una tonnellata (anche se in questi casi, meglio annunciarlo piuttosto che spazzarlo sotto il tappeto).
Oppure .. potresti fare come Htbaa e scrivere solo funzioni. :)
Come mi sento? Realistico per la mancanza di perfezione, ma anche per il senso dell'obbligo di correggere tutto ciò che è sbagliato. Ciò include i datori di lavoro del passato, dove, se necessario, sarei felice di essere al telefono, e-mail, qualsiasi cosa in modo tale che se vogliono fare domande o chiedere assistenza darò volentieri.
Ci sono 2 tipi di bug in realtà:
Più di un problema è la velocità con cui è possibile correggerli e installare una patch, e questo dipenderà spesso dal processo di sviluppo. In un sistema ideale non avrai bisogno di creare un sistema completo e installarlo per distribuirne uno, ma invece di costruire e installare solo il piccolo componente con la correzione.
Dal modo in cui penso che molti sviluppatori siano felici di essere "responsabili" del codice che hanno scritto e di correggere i loro bug. Sta correggendo i bug di altre persone mentre quegli sviluppatori stanno facendo la "nuova" codifica a cui la maggior parte degli sviluppatori si opporrà.
Scrivendo per me stesso, mi sento imbarazzato, ma ammetterò apertamente che è colpa mia. I bug sono generalmente evitabili.
Nel mio attuale lavoro faccio molto più revisioni rispetto alla codifica, in particolare del codice di produzione. Tuttavia, mancare un problema è imbarazzante e colpa mia. Non pretendere che sia corretto prendere scorciatoie poco chiare. Il tentativo di rivedere il codice di bassa qualità è un gioco da mug.
L'unica cosa che mi infastidisce davvero è quando un bug "se ne va" prima che io possa trovarlo. Altrimenti è solo una parte del lavoro, davvero. Ovviamente cerco di evitarli, la loro caccia è in realtà divertente e spesso estremamente educativa.
E una volta che rinunci al concetto di possedere il codice che hai scritto (come dovresti), un effetto collaterale positivo è che non sei ferito da qualcuno che trova un bug nel "tuo codice" così tanto. È ancora imbarazzante, ma non così male.
Forse sto interpretando erroneamente il tono di questo thread ma sembra che la maggior parte delle persone che pubblicano qui sia troppo pignola per quanto riguarda i bug. Come qualcuno ha detto, ci sono 2 tipi di bug. Quelli a causa di requisiti erroneamente interpretati. Quelli sono comprensibili
Tuttavia, l'altro tipo, i bug nel tuo programma che non fanno quello che pensavi dovesse essere fatto dovrebbero essere estremamente rari. Quelli sono quelli che mostrano un fallimento nella parte del programmatore nel loro lavoro correttamente. Sto ottenendo l'impressione dai poster di questo forum che non è un grosso problema rilasciare il codice buggy, è normale. Continua a scherzare, perché non è normale. O almeno, non è accettabile in molti posti di lavoro. Una volta o due volte l'anno, forse. Ma oltre a questo, sei un programmatore scadente e sarai trattato come tale.
Penso che una cosa da aggiungere sia che la reazione può avere molto a che fare quando viene trovato il bug. Ho visto reazioni difensive quando gli sviluppatori hanno chiesto di tenere traccia dei bug prima ancora che avessero avuto la possibilità di compilare e testare il codice una volta . Inutile dire che ha avuto un strong respingimento dal momento che per la maggior parte della gente, la compilazione e l'esecuzione del codice è una parte organica dello sviluppo. Penso che ogni sviluppatore voglia avere la possibilità di testare il codice in modo sano prima di rendere il proprio lavoro "pubblico" - quindi le modifiche al codice di pre-check-in potrebbero essere facilmente definite "sviluppo" e non "bug fixing".
Post check-in / pre-release - Penso che nella maggior parte dei casi il risultato sia di sollievo, sia che lo sviluppatore lo trovi da solo, sia che un altro membro del team lo trovi, è una buona cosa colpire un bug, specialmente un grande uno, prima che il cliente lo faccia. Ho visto un strong desiderio nella maggior parte degli sviluppatori di voler correggere gli errori nel codice che hanno sviluppato. Questo può essere problematico, se hai a che fare con un team in cui una piccola percentuale di persone ha scritto il codice, ma un gruppo molto più grande sta testando / eseguendo il debug.
Con un avvertimento - la risposta "non è un bug, è una caratteristica" - ci sono molte volte in cui una decisione di progettazione (specialmente nell'interfaccia utente) ha portato a qualche comportamento che il tester trova sbagliato, ma il programmatore crede sia giusto . Convincere uno sviluppatore che la "caratteristica" sia un "bug" può essere un vero trucco, ma è fattibile.
Pre-release, penso che il trucco sia evitare che il processo di individuazione / correzione degli errori sia vergognoso - deve essere uno di trionfo. Ogni bug è un'opportunità per rendere il codice migliore, e dovrebbe importare chi lo ha trovato. Se hai una cultura in cui i bug vengono esaminati e attribuiti come "colpa" specifica di una persona, è probabile che tu crei una cultura che si getta nel piede quando prova a trovare i bachi perché sarà più importante per il CYA che per risolvere il problema. prodotto.
Il più difficile può essere il bug post-rilascio - quando qualcuno al di fuori del team tecnico viene coinvolto, è facile iniziare una guerra colpa. Il trucco è di tenerlo focalizzato sulla soddisfazione del cliente. C'è un ottimo esempio di Lexus su come un importante richiamo è stato gestito con tanta eleganza, che anche nel bel mezzo di un grande problema di qualità, la società è stata in grado di stupire i clienti. È quel tipo di attitudine che deve essere presente - non puoi pensare a quanto sia stato male avere un bug - devi pensare a come con garbo puoi recuperare.
Leggi altre domande sui tag bug