Sostituire il componente buggy con la libreria: importante identificare il bug nel vecchio componente prima di sostituirlo?

Bene, dipende da quanto è importante per la tua azienda far funzionare di nuovo l'autenticazione con il componente esistente, e se puoi aspettarti di farlo molto più velocemente della sostituzione del componente. Se riesci a riparare il sistema in due giorni, ma scambiare il vecchio componente con il nuovo richiede due mesi, dovresti probabilmente pensare di ripararlo prima. Se ti aspetti che entrambe le cose impieghino un tempo simile (o pensi di poter sostituire il vecchio componente in meno tempo rispetto all'errore), la decisione dovrebbe essere chiaramente quella di sostituire il componente.

Se gli sviluppatori che gestivano il software utilizzavano regolarmente il tuo VCS e applicavano rigorosamente solo codice compilabile, probabilmente hai una buona possibilità di trovare il commit specifico che ha introdotto l'errore "bisecando". Se hai una revisione n1 che funziona e una revisione n2 > n1 che non funziona, controlla il codice di revisione n3:=(int)((n1+n2)/2) e verifica se funziona o meno. Se funziona, continua con (n3, n2), altrimenti continua con (n1, n2). Ripeti fino a quando non trovi il commit specifico che ha creato l'errore.

Devi decidere da solo se questo funziona per il tuo caso, questo dipende sicuramente dalle dimensioni del tuo sistema, dai tempi di pagamento e di costruzione e dalle tue possibilità di testare le vecchie revisioni. La mia esperienza è che questo può essere un modo molto rapido per individuare la causa principale dei bug. Ho dovuto fare i conti con una situazione simile in passato, quando sapevamo che era stato introdotto un bug nel giro di sette anni fa e volevo sapere quando è successo. Bisecare mi ha richiesto meno di un'ora per trovare il commit che ha causato il problema, e quindi è stato piuttosto facile identificare il cambiamento difettoso nel codice.

My question is more aimed at whether it is important to find the offending bug - and if it is, why?

Ci sono un paio di vantaggi nel trovare (non necessariamente risolvere) il bug.

Senza trovare il bug, è impossibile trovare la causa principale.

• È stato uno stupido errore di battitura da uno stagionato stanco oberato di lavoro in una notte prima di una scadenza incombente? O era qualcosa di molto più nefasto, un tentativo di inserire una backdoor nel codice di autenticazione, forse? Era stupidità, negligenza, un errore onesto, un malinteso? Lo sviluppatore in questione ha fatto un errore o non ha capito il sistema?
• Perché il bug non è stato rilevato dai test unitari, dai test funzionali, dai test di sistema, dai test di regressione, ... durante lo sviluppo? Gli sviluppatori non eseguono le suite di test prima di impegnarsi?
• Perché il bug non è stato rilevato dai test unitari, ... sul server CI? Gli sviluppatori hanno disabilitato CI?
• Perché non è stato rilevato durante la revisione del codice?
• Perché non è stato catturato dal team addetto al controllo qualità?
• Perché non è stato riparato una volta catturato? Ancora una volta, gli sviluppatori non capiscono il sistema?
• Perché il tuo stile di codifica non previene questo tipo di bug?
• C'è un problema con la tua cultura di codifica?

Una volta che hai trovato e capito il bug e hai compreso la causa principale, puoi cercare, tracciare, eliminare e prevenire casi simili di bug.

• Scrivi uno script / aggiungi un test / aggiungi un'attività di analisi al tuo analizzatore statico / linter / style checker che verifica (assenza di) non solo questo particolare bug, ma tutte le istanze simili.
• Cambia il tuo stile di codifica per prevenire bug simili (un esempio semplicistico richiederebbe verifiche della forma 0 == foo invece di foo == 0 per impedire il (in) famoso if (userId = 0) backdoor).
• Esegui una revisione del codice a livello di sistema per cercare bug simili.
• Addestra gli sviluppatori nelle tecniche di codifica per prevenire bug simili.
• Adotta una cultura di codifica che impedisce la ripetizione di questo particolare bug.
• Modifica o aumenta i processi che hanno portato a questo errore non solo vengono introdotti ma anche non vengono corretti.

Un esempio estremo di questo è OpenBSD. Quando trovano un bug di sicurezza nel sistema principale, eseguono un'analisi delle cause alla radice, quindi eseguono una revisione completa e completa manuale dell'intera base di codice, e cercano errori simili oltre a rivedere i processi e gli stili di codifica che potrebbe aver portato a questo bug. La comunità della sicurezza in generale è paranoica su questo. Ogni volta che si riscontra una nuova vulnerabilità in qualche pezzo di codice rilevante per la sicurezza, non solo la libreria sarà completamente rivista, ma anche tutte le librerie simili. Ad esempio, un bug di sicurezza in Apache, generalmente innescherà anche una revisione di Nginx, ecc. Inoltre, condurrà spesso a progetti come Valgrind o Coverity che cercano di capire come possono controllare questo e altri bug, e quindi eseguire il loro controllo contro un grande numero di codice open source.

Ora, indipendentemente dal fatto che questo abbia senso (aziendale), è una domanda che solo tu e i tuoi manager potete rispondere. Quanto è importante per l'azienda capire questo bug? Quanto è importante per la fiducia nel team di sviluppo? O la fiducia degli sviluppatori in se stessi?

Inoltre, una volta capito quale fosse il bug, a seconda di quale fosse esattamente la causa principale, molte delle cose che ho elencato potrebbero non avere senso. Per esempio. se davvero era solo un errore di battitura sincero, fare una revisione completa del codice per cercare altri errori di battitura, probabilmente è eccessivo. Sebbene alcune domande siano ancora interessanti, come il motivo per cui l'errore di battitura non è stato rilevato dal compilatore, dal sistema di tipi, dall'analizzatore statico, dai test o dalle revisioni del codice e da ciò che può essere fatto per garantire che la prossima volta farsi prendere.