I test garantiranno la correttezza (meno i casi limite scoperti), ma non è sufficiente che il codice sia corretto; deve anche essere il più leggibile / comprensibile possibile per te e per chiunque altro che lo legge dopo di te. Anche con un rigoroso processo di revisione del codice sul mio team, eseguo sempre la mia auto-revisione prima di creare una richiesta di pull. In tal modo, trovo spesso i modi per rendere più chiaro l'intento del codice prima di inviarlo per la revisione.
Questa è una domanda personale però. È possibile che alcuni sviluppatori siano in grado di scrivere codice molto leggibile fin dall'inizio. Se è così, è grandioso. Tuttavia, la maggior parte di noi sarà probabilmente in grado di trovare alcuni miglioramenti dopo il completamento del lavoro. Di conseguenza, ti consiglio vivamente di eseguire almeno una rapida autoindagine o una revisione completa se il tuo team non ha in corso una procedura di revisione formale del codice.
Per quanto riguarda ciò che rende il codice più "leggibile", questo può essere molto soggettivo. L'obiettivo è renderlo leggibile per il maggior numero possibile di spettatori di sviluppatori. Esistono molte risorse disponibili che descrivono le tecniche per scrivere codice pulito, come il libro di Bob Martin , che è generalmente ben accettato (anche se datato) per questo scopo.
Per rispondere alle tue domande in modo più diretto: non dovresti controllare visivamente il tuo codice per verificare eventuali bug, ma dovresti esaminare visivamente il tuo codice per assicurarti che sia leggibile. Non c'è un numero magico per quanto tempo dovresti spendere per questa recensione; man mano che il tasso di scoperta dei problemi di leggibilità diminuisce, ti stai avvicinando alla fine. Il mio consiglio è di scrivere test per quanti più possibili percorsi di esecuzione ragionevolmente attesi, e controllare manualmente i miglioramenti alla leggibilità.