Correzione di un bug che non ha mai causato problemi fino ad ora

Di recente ho apportato una modifica che ha causato l'esecuzione di un codice molto più spesso rispetto al passato. Ciò ha portato alla scoperta di un bug. Questo bug aveva il potenziale per accadere ogni volta che il codice veniva eseguito, ma perché veniva eseguito così raramente che non emerse mai.

Quando ho portato questo all'attenzione dello sviluppatore principale, voleva che annullassi la modifica che ha esposto il bug piuttosto che correggere il bug citando l'adagio, "Se non è rotto, non risolverlo".

Mi è chiaro che fino ad ora siamo stati solo fortunati, ma non ascolterà la ragione.

Devo ripararlo comunque?

Aggiornare

Il lead tecnicamente non ha alcuna autorità su di me. Solo mandato. È stato l'unico sviluppatore del progetto per diversi anni fino a un anno fa e penso che non prenda molto bene le critiche costruttive. Per quel che vale, non l'ho criticato. Ho appena sottolineato che solo perché il bug non è mai apparso non significava che non c'era.

Vorrei suggerire che se si dispone di tracciamento dei bug, quindi inviarlo. Se è fondamentale, elevalo e portalo alla sua attenzione. Lascia che il tuo superiore lo declassi nel tracker. Quando le cose vanno male, avrai la scia di carta.

Personalmente lo riparerei, a meno che non richiedesse un notevole sforzo in più di quanto valesse. "Se non è rotto, non aggiustarlo" è orribile da applicare al software.

Se il tuo sviluppatore principale è il tuo capo e dice di non toccarlo, in tal caso non lo farei.

La maggior parte delle risposte e dei commenti ha suggerito di mitigare la responsabilità della decisione creando una segnalazione di bug e consentendo a qualcun altro di effettuare la chiamata.

Dal momento che non ho un bug tracker (e dubito che chiunque diverso da me lo userebbe se lo facessimo) ho fatto la cosa migliore da fare. Sono andato oltre la testa dello sviluppatore principale. Dopo aver spiegato la situazione alla direzione, hanno visto le cose a modo mio. Mi hanno detto di risolverlo correttamente e ignorare la richiesta di richiesta del lead . Dissero che avrebbero lisciato le piume arruffate se avesse scoperto il sotterfugio e si fosse lamentato.

Non è una soluzione ideale ma almeno il bug è stato corretto correttamente.

Ricordagli che la frase è "Se non è rotto, non aggiustarlo" e non "Se il client non l'ha notato, non aggiustarlo".

Quale giustificazione hai per il cambiamento che hai apportato? Se non riesci a sottolineare quali cambiamenti si verificherebbero l'utente o il debito tecnico è stato rimosso, mi schiererei con lo sviluppatore principale in termini di dire semplicemente indietro il cambiamento poiché questo sta solo peggiorando le cose.

Ho almeno un paio di opzioni diverse qui nella mia mente:

Se vai avanti e risolvi l'errore, rischi di aggiungere altri bug al mix che potrebbero ritorcersi contro di me. A seconda di quanta esperienza hai e della fiducia di evitare qualche brutta sorpresa che probabilmente sarebbe la mia guida qui.

Se fai ciò che ti è stato detto di fare, è solo colpa che sarebbe il problema o è più di questo? Mi chiedo cosa c'è di sbagliato qui a parte quella roba conosciuta come principi e valori. Voglio dire che è un po 'uno scherzo ma anche un punto onesto di cosa c'è di sbagliato in questa idea?

Mentre il mio travolgente istinto sarebbe quello di correggere i bug e non nascondere il problema, ci sono scenari in cui mi trattengo il naso e nasconderei il problema.

1. Il codice viene utilizzato internamente e occasionalmente, quindi le conseguenze del bug sono gestibili all'interno dell'azienda.
2. Considerazioni commerciali travolgenti che richiedevano la spedizione oggi e una correzione di bug potrebbe essere lanciata 2 settimane dopo con conseguenze minime.

Professionalmente, non mi piacciono queste risposte, e chiarirei internamente che si stavano verificando l'etere di queste situazioni.

Alla fine, non dovresti fare nulla che il tuo superiore abbia esplicitamente detto di non fare. Credo che la cosa migliore da fare nella tua posizione sia quella di creare una segnalazione di bug in qualunque database di tracciamento di bug tu abbia. in questo modo almeno tutti sono a conoscenza del problema e qualcuno con più autorità può decidere cosa farne.

Copia la funzione buggy, applica la correzione, rinominala, magari mascherala un po 'e chiamala invece.

Sulla base del tuo commento sui due bug di showstopper, la scelta migliore potrebbe essere quella di seguire la lettera della legge, ma ignorare il suo spirito.

Ovviamente c'è un lato negativo della codifica taglia e incolla, ma sembra che questo sarà l'ultimo dei tuoi problemi.