Le altre persone correggono i bug quando li vedono, o aspettano fino a quando non ci sono crash / perdita di dati / persone che muoiono prima di risolverlo?
Esempio 1
Customer customer = null;
...
customer.Save();
Il codice è chiaramente sbagliato e non c'è modo di aggirarlo: chiama un metodo su un riferimento null. Capita di non bloccarsi perché Save capita di non accedere a nessun dato di istanza; quindi è come chiamare una funzione statica. Ma qualsiasi piccola modifica da qualche parte può improvvisamente causare un codice rotto che non si arresta in modo anomalo: per iniziare a bloccarsi.
Ma , non è neanche inconcepibile che corregge il codice:
Customer customer = null;
...
customer = new Customer();
try
...
customer.Save();
...
finally
customer.Free();
end;
potrebbe introdurre un arresto anomalo; uno non rilevato tramite test unitari con copertura completa e test manuale dell'utente.
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à esplodere troppo presto i razzi-retro, uccidendo tutti gli occupanti del veicolo spaziale.
Ma è anche possibile che forse sopravvaluti la velocità mascherino un altro problema: gli airbag non possono essere posizionati mentre la navetta si muove troppo velocemente. Se improvvisamente aggiustiamo 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 dispiegando quando non dovrebbero.
Esempio 3
Ecco un esempio che ho avuto di recente, controllando se una stringa contiene caratteri non validi:
if (StrPos(Address, "PO BOX") >= 0)
{
//Do something
}
Che cosa succede se viene rilevato un errore nel ramo Do something ? Correggere il codice ovviamente errato:
if (StrPos("PO BOX", Address) >= 0)
{
//Do something
}
Corregge il codice, ma introduce un bug.
Per come la vedo ci sono due possibilità:
- correggi il codice e incolpati di averlo infranto
- attendi che il codice si blocchi e venga incolpato di avere un bug
Che cosa tu fai politicamente?
Esempio 4 - Bug del mondo reale di oggi
Sto costruendo un oggetto, ma chiamando il costruttore sbagliato:
Customer customer = new Customer();
Si scopre che il costruttore "parameterless" è in realtà un costruttore parametrizzato da un altro punto indietro nella catena di 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 rompere nulla. Come il mio Esempio 1 sopra, forse qualcuno, da qualche parte, in qualche modo, in alcune condizioni esoteriche, dipende dal Customer costruito per essere non valido e pieno di junk.
Forse l'oggetto Customer , ora che è correttamente costruito consentirà l'esecuzione di un codice che in precedenza non è mai stato eseguito e ora posso ottenere un arresto anomalo.
Non posso scommettere la vita di tua moglie.
E posso testarlo da qui a martedì, non posso giurare sulla vita di tua figlia che non ho introdotto una regressione.
I I:
- Risolvete il codice e vieni accusato di averlo infranto? o
- Lasciare il bug e incolpare quando il cliente lo trova?