Se il bug ha più di 5 anni, allora è una funzionalità? [chiuso]

17

Consentimi di aggiungere dettagli: Lavoro in un luogo istituzionale con molti programmatori, tester, analisti del QA, proprietari di prodotti, ecc. E qui c'è qualcosa che mi infastidisce:

Siamo stati in grado di vendere software scadente (sebbene piuttosto funzionale) per oltre un decennio. Ha molte caratteristiche e il prodotto è competitivo, ma ci sono alcuni bug gravi là fuori, così come migliaia di "tagli di carta" - piccoli fastidi ai quali i clienti devono abituarsi.

Mi addolora guardare alcune cose perché credo fermamente che se i computer non aiutano a semplificarci la vita, non dovremmo usarli. Ho fiducia nei miei colleghi: sono intelligenti, abili e possono migliorare le cose quando ci si concentra su questo.

Tuttavia, può essere difficile archiviare bug contro alcune vecchie funzionalità senza vederle chiuse o dimenticate. "Ha funzionato così per eoni" è una tipica risposta. Inoltre, quando il QA fa regressione, tende a cercare tutto ciò che è diverso tanto quanto tutto ciò che non sembra giusto. Quindi, una soluzione a un vecchio problema può essere scritta come un bug, perché "è stato così anche prima del mio tempo".

Il giovane programmatore in me pensa: riscrivi questa cosa terribile! Come qualcuno che ha avuto l'opportunità di essere vicino alle vendite, clienti, voglio dare un beneficio a questo approccio.

Sono interessato anche alla tua opinione / esperienza. Si prega di provare a considerare il rischio, il costo-beneficio e altri fattori non tecnici.

    
posta Job 12.01.2011 - 18:14
fonte

4 risposte

14

Sento il tuo dolore.

Ma riparare qualcosa solo perché si tratta di un bug non è una buona ragione.

Devi assicurarti che la tua correzione non infranga nessun altro codice (non solo il tuo ma il codice dei tuoi clienti che usa il tuo codice). Se sposti una correzione e questo rompe ogni sistema dei clienti, avrai alcuni clienti molto scontenti.

Ci sono molti esempi famosi in cui è stato scritto un nuovo codice per sostituire un vecchio sistema. Dove dovevano aggiungere esplicitamente la funzionalità di un bug nel vecchio sistema perché gli utenti dipendevano da quel bug (non andando a nomi ma sono sicuro che puoi google).

I test di regressione sono fondamentalmente un test di ciò che i tuoi clienti si aspettano che accadano. Prima di rimuovere un test di regressione assicurati che non faccia del male a qualcuno (questo è quasi impossibile). Se puoi correggere un bug E questo non interrompe i test di regressione, allora è una soluzione reale.

    
risposta data 12.01.2011 - 18:23
fonte
3

alcune cose da considerare quando si decide di correggere un bug ... in nessun modo tutto incluso.

  • È fondamentale (il sistema si blocca)? ... chiaramente questi vengono riparati
  • I clienti si lamentano spesso di ciò? Questo potrebbe essere un bug in quanto qualcosa è rotto nel codice o potrebbe essere un bug di requisiti come la funzionalità non è facile da usare o si aspetta che funzioni diversamente.
  • Dal punto di vista aziendale è più vantaggioso correggere il bug o implementare una nuova funzione?
  • Il bug richiede cambiamenti architettonici significativi o si trova in una parte del sistema che è strongmente dipendente da altri sottosistemi? Ciò potrebbe influire drasticamente sui tempi di test e complicare la necessaria copertura di test richiesta per convalidare il bug? Se è molto vecchio, è talvolta difficile capire esattamente quale altro effetto avrà nel sistema modificando la sezione di codice del buggy.
  • Stai perdendo potenziali clienti a causa di un sistema buggato
risposta data 12.01.2011 - 18:28
fonte
3

Definisci bug. "Le specifiche indicate per data, ma sono ordinate per quantità di transazioni" non è necessariamente un bug nel codice. Potrebbe essere un cambiamento non documentato - a volte, da qualche parte, qualcuno ha chiesto di cambiare l'ordinamento, ma le specifiche, i requisiti, il manuale (anche i pulsanti e le etichette sull'interfaccia utente) non sono stati modificati per corrispondere, e nessuno se ne preoccupa. Perché tu possa presentarti e cambiarlo in "per data" causerà il caos, e per te aggiornare l'interfaccia utente, le specifiche, il manuale ecc sta fondamentalmente sprecando il tuo tempo, con la possibile eccezione di un po 'di "teoria delle finestre rotte" ".

Alcune cose sono ovviamente bug. Se fai clic su questo pulsante, esplode. Oppure, se fai clic su questo pulsante il lunedì, esplode. A meno che qualcuno non ti abbia incaricato di investire tempo a capire il motivo, potresti dedicare un sacco di tempo a investigare. E una volta scoperto il motivo, potrebbe essere che non puoi cambiarlo, perché ciò rovinerebbe qualcosa che è più importante per gli utenti o per la gestione.

Se vedi "sloppiness" - perdite di memoria, codice che ha chiaramente bisogno di alcune convenzioni di ottimizzazione, indentazione e denominazione che non corrispondono alle tue - è super strong tentare di sistemare un giorno quando non hai nient'altro da fare, o il tuo tempo. Tuttavia, queste "correzioni" rovinano la cronologia nel controllo del codice sorgente per poco o nessun beneficio, disastri di rischio come "non compiliamo mai quel modulo perché il file binario che stiamo usando in produzione è stato creato dal codice che è stato perso e lo hai appena sovrascritto "e può seriamente turbare le persone i cui" errori "stai" aggiustando ".

Raccomando uno a uno con il tuo capo. Spiega cosa ti infastidisce: è lo stile di codifica, cose che devi sicuramente infastidire gli utenti, numeri imprecisi, incoerenze o disastri che attendono di accadere? Quindi chiedi indicazioni e (questa è la chiave) prendilo.

    
risposta data 12.01.2011 - 21:26
fonte
2

Se vuoi correggere un bug che è stato vecchio, dovrai fare attenzione a non rompere nessuna funzionalità esistente. Se ci sono test unitari, questo è più facile, ma data l'età implicita della società e del software, non esistono. Suggerirei di passare attraverso il libro Refactoring di Martin Fowler perché si tratta di come rifattorizzare e correggere i bug mentre si cerca di minimizzare gli effetti collaterali. Ti suggerisco inoltre di assicurarti che la compagnia stia bene con te, passando attraverso vecchi bug durante il normale orario. Potrebbero lasciarti fare solo se lo fai fuori orario.

Inoltre, se un bug è diventato una caratteristica, ovvero è effettivamente utilizzato dai client perché fornisce qualcosa, assicurati di fornire un sostituto adatto a quando lo desidera (o semplicemente documentalo come una caratteristica invece di una bug).

    
risposta data 12.01.2011 - 18:30
fonte

Leggi altre domande sui tag