Altre persone correggono i bug quando li vedono o aspettano che si verifichino arresti anomali / perdita di dati / persone che muoiono prima di risolverli?
Esempio 1
Customer customer = null;
...
customer.Save();
Il codice è chiaramente sbagliato e non c'è modo di aggirarlo: sta chiamando un metodo su un riferimento null. Non si verifica un arresto anomalo perché Savenon accede ai dati di istanza; quindi è proprio come chiamare una funzione statica. Ma qualsiasi piccola modifica in qualsiasi luogo può causare improvvisamente un codice non funzionante che non si arresta in modo anomalo: avviare un arresto anomalo.
Ma non è nemmeno inconcepibile che la correzione del codice:
Customer customer = null;
...
customer = new Customer();
try
...
customer.Save();
...
finally
customer.Free();
end;
potrebbe introdurre un arresto anomalo; uno non scoperto attraverso test unitari con copertura completa e test utente manuale.
Esempio 2
float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);
Le persone che conoscono la fisica riconosceranno che dovrebbe essere R 2 nel denominatore.
Il codice è sbagliato, è assolutamente sbagliato. E sopravvalutare la velocità farà sì che i razzi retro sparino troppo presto, uccidendo tutti gli occupanti del veicolo spaziale.
Ma è anche possibile che sopravvalutare la velocità stia mascherando un altro problema: gli airbag non possono schierarsi mentre la navetta si muove troppo velocemente. Se improvvisamente ripariamo il codice:
float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);
Ora la velocità è precisa e improvvisamente gli airbag si stanno diffondendo quando non dovrebbero.
Esempio 3
Ecco un esempio che ho avuto di recente, verificando se una stringa contiene caratteri non validi:
if (StrPos(Address, "PO BOX") >= 0)
{
//Do something
}
E se si scopre che c'è un bug nel Do somethingramo? Correzione del codice ovviamente errato:
if (StrPos("PO BOX", Address) >= 0)
{
//Do something
}
Risolve il codice, ma introduce un bug.
Per come la vedo io ci sono due possibilità:
- correggi il codice e ottieni la colpa per averlo infranto
- attendi che il codice si blocchi e venga accusato di avere un bug
Che cosa si politicamente fai?
Esempio 4 - Bug del mondo reale di oggi
Sto costruendo un oggetto, ma sto chiamando il costruttore sbagliato:
Customer customer = new Customer();
Si scopre che il costruttore "senza parametri" è in realtà un costruttore con parametri da più indietro nella catena dell'ereditarietà:
public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)
Chiamarlo è un errore, poiché ignora tutti i costruttori successivi.
Potrei cambiare il lignaggio dell'oggetto per non esporre un costruttore così pericoloso, ma ora devo cambiare il codice in:
Customer customer = new Customer(depends);
Ma non posso garantire che questo cambiamento non rompa nulla. Come il mio esempio 1 sopra, forse qualcuno, da qualche parte, in qualche modo, in alcune condizioni esoteriche, dipende dal fatto che sia costruito Customerper essere non valido e pieno di spazzatura.
Forse l' Customeroggetto, ora che è stato costruito correttamente , consentirà l'esecuzione di un codice che in precedenza non ha mai fatto, e ora posso ottenere un arresto anomalo.
Non posso scommettere sulla vita di tua moglie.
E posso provarlo da qui a martedì, non posso giurare sulla vita di tua figlia che non ho introdotto una regressione.
Devo:
- Correggi il codice e ti incolpano di averlo infranto? o
- Lasciare il bug e ottenere la colpa quando il cliente lo trova?