Quando interrompere il debug

Se hai una scadenza ristretta e decidi di riscrivere il codice, come fai a sapere che non introdurrai più bug di quello che stai cercando di risolvere? E dopo aver eseguito la riscrittura, per quanto ne sai, lo stesso bug potrebbe ancora essere lì. Cosa succede se la causa principale del problema è la comprensione di alcune API esterne? Il tuo codice potrebbe essere nuovo, ma la tua comprensione dell'interazione con altri componenti è la stessa.

Consiglierei di non riscrivere MAI alcun codice solo perché ha un bug che non capisci. Come ingegneri del software, una parte significativa dei nostri lavori è il debugging. E non ci dovrebbe essere alcun motivo per cui un errore non possa essere trovato. Continua a scavare e scartare i livelli. Cerca l'aiuto di strumenti come la registrazione (homegrown o framework), i debugger e così via. Questi sono i tipi di esperienze che ti rendono uno sviluppatore migliore. Non solo acquisirai abilità che ti mancano attualmente, ma otterrai anche informazioni su cosa non fare in futuro. Se tutto il resto fallisce, inizi il processo scrupoloso della ricerca binaria manuale (disabilita la metà del codice e vedi come questo influenza il bug, quindi continua a fare la suddivisione finché non lo riduci a sufficienza)

Se hai bisogno di fare una pausa, prendilo. Un'altra cosa che aiuta è sedersi con un collega e spiegargli cos'hai trovato e i tuoi passi. a) il tuo collega potrebbe avere un consiglio addizionale eb) tu lo usi come cassa di risonanza e, a volte, quando parli ad alta voce, potresti realizzare ciò che hai trascurato te stesso.

La modifica del codice in qualche modo comporta il rischio di introdurre nuovi bug nel codice. Più grandi sono i cambiamenti, maggiore è il rischio. È possibile mitigare tale rischio tramite test unitario (e integrazione / sistema / ...) (ma non eliminarlo mai completamente).

Ovviamente, una riscrittura totale ha un rischio significativamente più alto rispetto alla semplice correzione di un bug specifico. Per creare una correzione adeguata, è necessario comprendere il problema e la soluzione abbastanza bene in modo che la risoluzione di un problema non rotti altri casi di utilizzo. Ma così è il caso di una riscrittura. Se non capisci cosa sta succedendo durante il debug, ovviamente il codice in questione è complesso, quindi riscriverlo sarà tutt'altro che banale, e di solito richiede più tempo. Che, in una scadenza ristretta, non è una buona notizia ...

Inoltre, essere stanchi e sotto pressione aumenta sempre il rischio di prendere decisioni sbagliate e di sbagliare, causando così ulteriori bug.

Quindi personalmente preferirei strongmente il debug e il bug concreto anziché riscriverlo, tranne quando il codice in questione è veramente terribile e ho una specifica chiara (sotto forma di documenti e / o test di unità) di ciò che dovrebbe fare e ho abbastanza tempo per farlo correttamente.

(Si noti inoltre che se il codice è davvero così terribile, è estremamente raro che sia adeguatamente documentato e / o testato sull'unità. In questo caso, è necessario ancora più tempo per costruire una suite di test di unità adeguata per "registrare" "il comportamento del codice corrente, per essere in grado di verificare che la nuova implementazione lo riproduca fedelmente in ogni aspetto tranne la correzione di bug.)

Se sei bloccato con il tuo approccio attuale, è davvero una buona idea riposarti e fare qualcos'altro per rilassare la mente e permettere al tuo subconscio di lavorare sul problema in pace. È anche utile chiedere aiuto a un collega (o StackOverflow). Vedi questo thread correlato in precedenza per maggiori dettagli:

Affrontare la frustrazione quando le cose non funzionano

Una corretta preparazione prima di scavare direttamente nel codice non avrebbe mai bisogno di riscriverlo. Se stai riscrivendo il tuo codice spesso significa che il metodo che hai scelto è privo di un'adeguata analisi dei requisiti e / o della tecnologia e / o dell'approccio. Non sottovalutare l'arte dell'ingegneria del software. Fa risparmiare molto tempo e danni al cervello.

Continua a commentare, il versioning potrebbe anche farti risparmiare un po 'di rilavorazione.

Per quanto riguarda quando è possibile riscrivere il codice piuttosto che eseguire il debug. Fallo solo se

1. Il codice è abbastanza piccolo.
2. Sai che non risolverebbe il problema
3. Stai lavorando su un codice non commentato di qualcun altro (deve essere di nuovo piccolo)
4. Hai molto tempo e ti vengono i brividi solo guardando il codice esistente. :)

My question is, when will you think it is better to rewrite the code rather than fix it?

Sono tentato di dire "mai". Il problema è: la riscrittura può sembrare più semplice, ma l'esperienza insegna che di solito il nuovo codice avrà nuovi bug. Quindi probabilmente sostituirai un bug con diversi nuovi.

Inoltre, se non capisci perché si verifica il bug, cosa ti dice che la tua riscrittura non accidentalmente contiene lo stesso bug (forse si trattava di un errore di progettazione o di un fraintendimento da parte tua).

Potrebbero esserci situazioni in cui il codice è così buggato che non vale la pena salvarlo, ma queste sono molto rare. Ho fatto accadere solo una o due volte in quasi dieci anni di lavoro di sviluppo.

Questo si applica solo al codice che è così buggato che praticamente non funziona affatto. Finché il codice funziona principalmente, vorrei non mai riscriverlo, non importa quanto sia brutto o complicato.