La lettura su codice che ho scritto ha senso verificarla?

-1

Dopo aver scritto del codice, ho l'abitudine di scansionarlo dappertutto una o due volte per cercare eventuali bug. Questo a volte è un processo faticoso e noioso, e richiede tempo. Dopo aver esaminato il mio codice, lo eseguo attraverso i miei test per verificarlo.

È un modo produttivo per eseguire la verifica? È più efficiente se eseguo il mio codice solo con i test, e se li passa tutti, allora il codice può probabilmente essere considerato corretto? Il motivo per cui non lo faccio è che i miei test potrebbero non sempre coprire ogni singolo caso limite, e quindi c'è una possibilità che il mio programma potrebbe essere sbagliato.

Sarebbe gradito qualsiasi consiglio su come migliorare i miei metodi di verifica. Se è una buona idea scansionare il codice, quando dovrei farlo (e quante volte)?

    
posta Inertial Ignorance 14.05.2018 - 23:37
fonte

2 risposte

7

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à.

    
risposta data 15.05.2018 - 00:19
fonte
5

Puoi scrivere test e chiamarlo verifica.

Puoi scrivere prove e chiamarlo verifica.

Ma nessuno di loro significa nulla se il codice, i test e le prove non sono tutti leggibili.

Il motivo per cui scriviamo i test è di migliorare la leggibilità del codice. Lo stesso con le prove. Il motivo per cui vietavamo goto era migliorare la leggibilità del codice. Si tratta di leggibilità.

Quindi l'unica buona verifica del codice è leggerla. Il motivo per cui leggi e rileggi il codice è perché stai guardando il codice in modo diverso. Ogni volta che pensi a un nuovo modo di pensare al codice, devi rileggerlo.

Se lo trovi meticoloso e noioso da leggere, devi riscrivere il codice per essere più leggibile.

Dovresti anche riscrivere i tuoi test per essere più leggibili. Dovresti scrivere test che mostrano alle persone come leggere il codice. Dove iniziare. Cosa aspettarsi. L'ambito. Buoni test ti aiutano a leggere il codice.

Non spaventare la prossima persona che legge il tuo codice con codice difficile da capire. Scrivi come vuoi essere gentile con loro. Un giorno potrebbero essere te.

    
risposta data 15.05.2018 - 04:45
fonte