Quando si correggono i bug nel codice esistente, è facile cadere nell'abitudine di trovare l'"errore" nel codice e regolare il codice per evitare l'errore. Ma se la causa principale del problema era un errore di progettazione, o un problema con l'algoritmo, allora aggiungere un altro flag o goto nel codice è l'approccio sbagliato. Non solo avete lasciato intatta la causa alla radice, ma ora avete reso il codice più difficile da capire per il prossimo ingegnere del software che deve capirlo.
Allenatevi a chiedere "come avrei risolto questo problema se fossi stato io il codificatore originale? Poi guardate la differenza tra l'approccio del "foglio di carta pulito" e quello che è effettivamente lì davanti a voi. Ma sii pragmatico. Non sto certo suggerendo che dovresti reimplementare una funzione perché tu e l'autore avete un approccio diverso. Fate questo passo come un esperimento di pensiero. Avete un caso di prova che fallisce. L'autore ha perso questo caso. Cosa l'ha portata a perdere questo caso? Se l'autrice avesse saputo di questo caso, in che modo il suo approccio sarebbe stato diverso? Questo tipo di domande sono preziose quando si scava nel codice che fondamentalmente funziona, ma che presenta ancora alcuni bug.
Nel nostro caso, invece di aggiungere un altro parametro ad una funzione interna, e di aggiungere un'altra variabile automatica che doveva essere correttamente inizializzata in 3 diversi punti di ingresso alla procedura principale, e di aggiungere codice per testare questa nuova variabile in un punto critico, mi sono reso conto che potevamo riparare l'algoritmo cambiando l'ordine in cui i sotto-punti venivano eseguiti. Una volta fatto questo, la necessità di variabili aggiuntive e casi speciali è scomparsa. Il codice finale è in realtà molto più facile da capire del codice originale, per non parlare del primo tentativo di riparazione. Questo mi dà la certezza che siamo sulla strada giusta. Il caso di prova che riproduce il problema ha dimostrato che sia la correzione originale (troppo complessa) che la correzione riveduta (semplificata) risolvono il problema. Ora dobbiamo solo essere sicuri di non aver rotto nient'altro.
Dato che questo fix è diretto ad un rilascio sul campo (cioè uno già installato presso le sedi del cliente), eseguiremo anche tre tipi di test di regressione intensivi. Due di essi verificheranno la continua aderenza allo standard POSIX (il bug fix è in codice che implementa una funzione POSIX), e il terzo tipo di test è un test di regressione generale a livello di sistema.
Fissare prima l'algoritmo. Una volta che l'algoritmo è corretto, occuparsi del codice.
Azienda