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

Consentitemi di aggiungere dettagli: lavoro in un luogo istituzionale con molti programmatori, tester, analisti di QA, proprietari di prodotti, ecc. Ed ecco qualcosa che mi infastidisce:

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

Mi fa male guardare alcune cose perché credo fermamente che se i computer non ci aiutano a semplificarci la vita, non dovremmo usarli. Ho fiducia nei miei colleghi: sono intelligenti, capaci e possono migliorare le cose quando l'attenzione è rivolta a farlo.

Ma può essere difficile archiviare i bug con alcune vecchie funzionalità senza vederle chiuse o dimenticate. "Ha funzionato così per eoni" è una risposta tipica. Inoltre, quando la QA fa regressione, tende a cercare qualsiasi cosa sia diversa da qualsiasi cosa non sembri corretta. 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 strana! Come qualcuno che ha avuto l'opportunità di essere vicino alle vendite, i clienti, voglio dare un dubbio su questo approccio.

Sono interessato anche alla tua opinione / esperienza. Prova a considerare il rischio, il rapporto costi-benefici e altri fattori non tecnici.

Condivido il tuo dolore.

Ma riparare qualcosa solo perché è un bug non è una ragione sufficiente.

Devi assicurarti che la tua correzione non rompa nessun altro codice (non solo il tuo ma il codice dei tuoi clienti che utilizza il tuo codice). Se invii una correzione e questo rompe ogni sistema dei clienti avrai dei 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 nominare i nomi ma sono sicuro che puoi cercarlo su Google).

I test di regressione sono fondamentalmente un test di ciò che i tuoi clienti si aspettano che accada. Prima di rimuovere un test di regressione, assicurati che non danneggi qualcuno (è quasi impossibile). Se riesci a correggere un bug E questo non interrompe i test di regressione, allora è una vera soluzione.

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

• È critico (il sistema si arresta in modo anomalo)? ... chiaramente questi vengono risolti
• I clienti si lamentano spesso? Potrebbe trattarsi di un bug in quanto qualcosa è rotto nel codice o potrebbe essere un bug di requisiti come la funzionalità non è user friendly o si aspettano che funzioni diversamente.
• Dal punto di vista aziendale è più vantaggioso correggere il bug o implementare una nuova funzionalità?
• Il bug richiede cambiamenti architetturali significativi o è in una parte del sistema su cui si basano fortemente altri sottosistemi? Ciò potrebbe influire drasticamente sui tempi di test e complicare la copertura di test necessaria per convalidare il bug? Se è davvero vecchio, a volte è difficile capire esattamente cos'altro influirà sul sistema modificando la sezione buggy del codice.
• Stai perdendo potenziali clienti a causa di un sistema difettoso

Definisci bug. "Le specifiche indicate sono ordinate per data, ma sono ordinate per importo della transazione" non è necessariamente un bug nel codice. Potrebbe essere una modifica non documentata: qualche volta, 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. Per te mostrarlo e cambiarlo in "per data" causerà il caos, e per te aggiornare l'interfaccia utente, le specifiche, il manuale ecc. Sta sostanzialmente sprecando il tuo tempo, con la possibile eccezione di un po 'di "teoria delle finestre rotte" ".

Alcune cose sono ovviamente bug. Se si fa 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 nella comprensione del perché, potresti dedicare molto impegno a indagare. E una volta scoperto il perché, potrebbe non essere possibile modificarlo, perché ciò rovinerebbe qualcosa di più importante per gli utenti o per la gestione.

Se vedi "sciatteria" - perdite di memoria, codice che necessita chiaramente di alcune convenzioni di ottimizzazione, rientro e denominazione che non corrispondono alle tue - è super tentato di risolverli un giorno quando non hai nient'altro da fare o nel tuo tempo libero . Tuttavia, queste "correzioni" incasinano la storia nel controllo del codice sorgente per un vantaggio minimo o nullo, rischi di disastri come "non abbiamo mai compilato quel modulo perché il binario che stiamo usando in produzione è stato costruito dal codice che è stato perso e lo hai semplicemente sovrascritto ", e può seriamente turbare le persone i cui" errori "stai" riparando ".

Raccomando uno a uno con il tuo capo. Spiega che cosa ti disturba: è lo stile di codifica, le cose che sei sicuro devono infastidire gli utenti, numeri imprecisi, incoerenze o disastri in attesa di accadere? Quindi chiedi la direzione e (questa è la chiave) prendila.

Se si desidera correggere un bug che era vecchio, si dovrà fare attenzione a non interrompere alcuna funzionalità esistente. Se ci sono test unitari, questo è più semplice, ma data l'età implicita dell'azienda e del software, non esistono. Consiglierei di leggere il libro Refactoring di Martin Fowler perché esamina come refactoring e correzione dei bug nel tentativo di minimizzare gli effetti collaterali. Vorrei anche raccomandare di assicurarsi che la compagnia sia d'accordo con te che stai affrontando vecchi bug durante le ore regolari. Potrebbero lasciarti fare solo se lo fai fuori orario.

Inoltre, se un bug è diventato una funzionalità, cioè viene effettivamente utilizzato dai client perché fornisce qualcosa, assicurati di fornire un sostituto adatto per quando vogliono quel comportamento (o semplicemente documentalo come una funzionalità invece di un bug).