Come rendere la scrittura del codice più accurata? [duplicare]

Come tutte le cose nella vita, dovresti cercare di trovare un equilibrio che funzioni per te. Vuoi massimizzare i tuoi tempi produttivi eliminando pratiche inutili, che è un buon pensiero snello , tuttavia questo deve essere fatto senza incorrere in costi inutili altrove, ed è qui che vedo il più grande rischio quando dichiari il tuo desiderio di codificare per lunghi periodi di tempo senza compilazione.

Pensa a cosa stai facendo quando scrivi software. Trascorri del tempo a pensare, a digitare, a correggere, a testare, a eseguire il debug e così via. È probabile che tu spenda meno tempo semplicemente digitando il codice che funzionerà per la prima volta, a meno che tu non sia un genio serio o forse un piccolo OCD mentre scrivi.

Quindi, come testate il vostro codice? Scrivi prima i test o esegui tutti i test alla fine? Entrambe le opzioni avranno un grave impatto sul tempo necessario per implementare con successo il tuo codice. Molti di noi che hanno praticato Agile per anni hanno scoperto che i test di scrittura prima di scrivere codice determinano un aumento generale dell'efficienza. Questo perché il test è fatto, fuori mano e si scrive solo un numero sufficiente di codice per far passare i test. È snello e, mentre il tempo di sviluppo iniziale è maggiore, il tempo di debug e test viene completato in un tempo più breve.

Tuttavia, indipendentemente dal fatto che tu test prima o test per ultimo, se c'è una cosa che ho imparato nel modo più duro nel corso degli anni, è che i maggiori errori di codifica si verificano di solito dopo le modifiche più importanti alla codifica. Pensaci per un momento. Stai scrivendo il codice e sei in zona , quindi continua a scriverlo. All'improvviso ti rendi conto che qualcos'altro deve essere modificato leggermente per poter adattare il tuo codice. Lo guardi attentamente, apporta le tue modifiche e continua a scrivere codice. Quando compili il tuo codice trovi improvvisamente un errore o due. Dopo aver corretto l'errore, il codice viene compilato per la seconda volta e quando si esegue il codice, funziona quasi come si desidera, ma c'è un bug. Correggi il bug e ricompila, poi c'è un altro bug ... e così via. Lo sto descrivendo come un problema isolato per un singolo sviluppatore, ma cosa succede quando lavori sugli stessi file sorgente e devi occuparti di rami, fusioni, ecc ...?

Quello che sto cercando di dire è che ottenere la compilazione del codice è la parte più piccola di un esercizio molto più ampio. Il tempo speso prima raffinando i tuoi test ed eseguendoli spesso contro il codice è molto efficiente, perché ti consente di risparmiare tempo prezioso in seguito, in particolare quando il tuo lavoro prevede il lavoro con altri sviluppatori di software. Il vero vantaggio viene comunque quando si lavora con un buon framework di testing unitario, perché si sarà in grado di ottenere un feedback istantaneo in modo che non solo saprete se il vostro codice viene compilato, ma saprete anche istantaneamente se il vostro codice funziona effettivamente. Questo di per sé è un enorme risparmio di tempo, perché può impedirti di ossessionare lo stato del tuo codice, liberando la tua attenzione per altre cose.

La correzione degli errori di sintassi rappresenta solo una piccola parte del tempo totale che i programmatori trascorrono mentre svolgono il nostro lavoro. Voglio dire, è così piccolo che si perde nel rumore. Il compilatore le indica, le aggiusta e tu vai avanti.

Anche la digitazione non è il collo di bottiglia, quindi un typer lento non è in genere un grande svantaggio rispetto a un typer veloce.

La correzione degli errori logici diventa un po 'più vicina a rappresentare una parte significativa del nostro sforzo di lavoro, ma tuttavia, non è il più grande errore di tempo.

Riformare il design (quando ci rendiamo conto che il modo in cui stavamo cercando di fare qualcosa non funzionava e dobbiamo riscrivere tutto dall'inizio) è probabilmente l'unica cosa che perdiamo la maggior parte del nostro tempo.

Quindi, cosa impariamo da questo? Il nostro lavoro consiste principalmente nella gestione della complessità dei problemi che stiamo cercando di risolvere. E questo è un problema con lavagna bianca e marcatore. Un buon ambiente di sviluppo e strumenti aiutano, ma proprio quello che facciamo con loro non conta molto, perché il più grande bottleneck di gran lunga è il design.

Un buon test non ha nulla a che fare con la sintassi corretta. Il compilatore fa questo per te. Un buon test è uno, che copre un'alta percentuale del codice e una vasta gamma di casi speciali, non uno che accade spesso. Utilizzare i test unitari laddove possibile. Questi ti consentono di ripetere i test dopo aver apportato modifiche al tuo codice. Ciò garantisce che le modifiche e le aggiunte non infrangono la logica esistente.

Sebbene non ci sia nulla di sbagliato nel praticare codice corretto, ti consiglio caldamente di provare e praticare a scrivere codice senza test o compilazione per lunghi periodi di tempo. Invece, suggerirei il contrario, compilare e testare il codice tutte le volte che puoi.

È possibile ridurre in modo significativo il tempo di debug se si scrive un piccolo segmento di codice e quando si compila / esegui qualcosa non funziona e deve essere corretto. Se hai scritto 5 classi e 30 funzioni e poi esegui tutto, avrai un sacco di tempo per trovare tutti gli errori logici anche dopo aver superato 80 errori di compilazione.

Inoltre, a seconda dell'IDE che stai utilizzando, potresti essere in grado di scrivere codice più veloce se ciò che è stato scritto in precedenza è compilabile. Ad esempio, l'IDE VS2010 compilerà continuamente il codice in background per ricostruire il suo database IntelliSense, quindi se hai fatto un errore di sintassi, potresti perdere la funzione / ricerca del nome di variabile.

Per quanto riguarda la formazione di te stesso per fare meno errori, penso che arriverà alla fine indipendentemente da quanto frequentemente (o di rado) tu costruisci / esegui il tuo codice. Finché stai prestando attenzione a che tipo di cose ti mancano e stai attivamente cercando di ridurre il tasso di errore, dovresti stare bene. L'altra cosa che vorrei anche praticare è mantenere uno stile di codifica coerente. Non lasciare che IDE formi tutto per te, ma assicurati ogni volta che inserisci uno spazio o una nuova linea che intendi. Penso che fare attenzione a ogni sequenza di tasti e prestare attenzione a ciò che si sta digitando, non solo produca un codice più pulito e più leggibile, ma aiuta anche a non commettere gli errori di sintassi più spesso.

Ho scoperto che se conosco le risorse / strumenti / classi che sto utilizzando, posso scrivere interi programmi di grandi dimensioni senza provare nulla. (Questi IDE di nuova concezione che evidenziano i tuoi errori aiutano immediatamente molto). E il programma di solito funziona come previsto. (Va bene, dopo che alcune NullPointerException sono state aggiustate.) Se il mio intento fosse qualcosa di buono è una domanda abbastanza diversa, ma avevo bisogno di eseguire l'intero programma per scoprirlo comunque.

Ma quando non so con certezza come funzionano gli strumenti, o come guarderà all'utente, sto sempre testando le cose. Quando non avevo mai usato un socket prima, volevo vedere il flusso di dati prima di scrivere 1000 righe di codice sul presupposto che avrebbe fatto. E ho mai ottenuto familiarità con la grafica. Per me il codice grafico è un infinito breve ciclo di modifica di un po 'del codice, provalo, cambia il codice, provalo, ....

Non penso di provando a scrivere tanto codice senza testarlo. Sto solo cercando di specificare il programma. Potrei farlo in inglese, o pseudo-codice, o nei diagrammi. Preferisco, in questi giorni, Java o C #. In questo modo, quando ho il mio programma accuratamente specificato, è pronto per essere spedito. Ehm, voglio dire che posso testare e controllare il design.

Mi sono sempre sentito un po 'come Wile E. Coyote. Codice in chiaro, ma sono diventato estremamente sensibile a quella sensazione che si prova quando ci si trova nel nulla. Il trucco è tornare su un terreno solido - testare il codice - prima che la gravità cominci. Io sono più bravo di quanto lo fosse Wile E.

È interessante notare che la maggior parte dei grossi pezzi di codice errato che ho dovuto buttare via sono stati lanciati molto prima che li mettessi alla prova. Sono il risultato di difetti nel mio design che sono diventati evidenti quando ho provato a codificare i dettagli.

Nel tuo caso, fai semplicemente ciò che ti è comodo. Se i tuoi test non ti stanno dicendo nulla di interessante, inizia a saltarli. Se finisci un grande programma che dipende dal sistema operativo, fai cinque cose fondamentali per te, e si scopre che il sistema operativo non può farne nessuno - beh, prova un po 'di più in futuro. Cercare di spingerti in entrambe le direzioni è una cattiva idea.

Penso di non essere in qualche modo in disaccordo con DXM qui, ma se non lo avesse già scritto avrei finito con il suo ultimo paragrafo ("Per quanto riguarda l'allenamento per fare meno errori. .. ").

Passaggio 1: prova a disegnare il problema su lavagna o carta (scatole, frecce, flussi di informazioni)

Passaggio 2: isola la logica ed esprimila in pseudo-codice (se inserisci > 10, fallo, altrimenti fallo)

Passaggio 3: scrivere un test unitario in base al risultato del passaggio 2

Passaggio 4: scrivere il codice che supera i test unitari nel passaggio 3

Non è sempre così semplice e non sono certo un santo quando si tratta di seguire i principi del TDD, ma è così che voglio che appaia.