È meglio trovare dei problemi da solo o lasciare che sia il computer a capirlo?

L'esecuzione del codice è la strada da percorrere se per qualche motivo non puoi eseguire il codice solo in un ambiente di produzione.

Come per verificare la sintassi e gli errori di configurazione, il tempo del computer è molto economico rispetto al tempo del programmatore. Idealmente, dovresti eseguire test di unità e integrazione per verificare la validità del codice per te. Se il tuo codice è abbastanza modulare, prova a scrivere test prima di apportare modifiche per assicurarti che il codice che stai modificando funzioni.

Il problema con l'analisi del codice riga per riga è che puoi leggere ciò che vuoi vedere, non ciò che fa realmente il codice. È tempo di eseguire tutto il codice su carta per verificare la validità e è probabile che tu commetta un errore o due. E alla fine devi comunque eseguire il codice che eseguirà una dozzina di controlli molto rapidamente.

Sarebbe meglio scrivere test unitari che definiscano il comportamento richiesto dopo la migrazione. Dopo aver superato tutti i test unitari, avviare i test di integrazione. Se trovi dei bug nei test di integrazione, aggiungi un nuovo test unitario o modificane uno esistente per testare il requisito appena scoperto.

Lo sforzo di scrivere i test delle unità assicurerà almeno la definizione dei requisiti prima di procedere con la migrazione.

Scruta il codice. Questa è la tua opportunità per comprenderlo, convalidarlo, refactoring e scrivere test per questo. Altrimenti, erediterete tutti i problemi con il codice originale.

Trova un modo per automatizzare la ricerca di errori. Se hai test automatici, eseguili. Se conosci tabelle o stored procedure che sono cambiate, esegui una ricerca testuale per nome. Se il database è completamente diverso, cerca ogni chiamata al database. Identifica le classi di errori e individua i modi per trovarli.