Con quale frequenza esegui e collaudi il tuo codice durante la programmazione? [chiuso]

16

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 5 anni fa .

Soprattutto quando scrivo un nuovo codice da zero in C, mi ritrovo a scrivere codice per ore, persino giorni senza eseguire il compilatore per tutto tranne che un controllo occasionale della sintassi.

Tendo a scrivere pezzi di codice più grandi con attenzione e testare a fondo solo quando sono convinto che il codice faccia quello che dovrebbe fare analizzando il flusso nella mia testa. Non fraintendetemi: non scriverei 1000 righe senza test (sarebbe un gioco d'azzardo), ma scriverei un'intera subroutine e la testerei (e la riparerei se necessario) dopo che penso di aver finito.

Dall'altro lato, ho visto per lo più neofiti che eseguono e testano il loro codice dopo ogni riga che inseriscono nell'editor e pensano che i debugger possano essere un sostituto per attenzione e sanità mentale. Ritengo che questa sia una grande distrazione dopo aver appreso la sintassi del linguaggio.

Quale pensi sia il giusto equilibrio tra i due approcci? Naturalmente il primo richiede più esperienza, ma influenza la produttività in modo positivo o negativo? Il secondo ti aiuta a individuare gli errori a un livello più preciso?

productivity testing coding

— Blagovest Buyukliev
fonte

3

Ci vogliono ore o giorni per scrivere un'intera subroutine?

1

@Thorbjorn La subroutine è lunga circa 999 righe ed è offuscata:

#define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)

e questa è solo una riga.

— Mateen Ulhaq,

1

i compilatori a volte possono richiedere molto tempo per compilare un programma, ecco perché non è buona norma compilare tutto il tempo. dopo ogni funzione è buona pratica. ricompilo dopo aver aggiunto nuove funzionalità o alcuni pezzi di codice difficili. Lo uso solo come correttore di sintassi. non vi è alcun sostituto per controllare attentamente il codice ed evitare errori nascosti e comportamenti casuali.

— Ross,

6

Dipende DAVVERO dall'aspetto del progetto a cui stai lavorando.

Quando faccio qualsiasi cosa con OpenGL (che funziona come una macchina a stati), compilo ed eseguo costantemente per assicurarmi di non aver rovinato accidentalmente nulla. L'impostazione di un valore senza ricordare di ripristinarlo alla fine di una funzione può facilmente rendere l'applicazione solo uno schermo nero.
Per lo sviluppo "under the hood" su larga scala, provo a ottenere il maggior numero possibile di test in anticipo. Dal momento che i test possono dirmi più facilmente cosa si è rotto, posso passare un po 'senza dover aspettare la compilazione tipicamente lunga.
Per la progettazione di UX, uso una sorta di visual designer, che sembra sempre come verrà eseguito (o vicino ad esso). In sostanza, sta sempre compilando il codice di progettazione.

— sharoz
fonte

63

Personalmente, devo lavorare in piccoli pezzi perché non sono abbastanza intelligente da conservare ore di codice nella mia cache L1 biologica. A causa delle mie capacità limitate, scrivo metodi piccoli e coerenti e oggetti di design per avere un accoppiamento molto lento. Strumenti e linguaggi più potenti rendono più facile la codifica più a lungo senza costruire, ma c'è ancora un limite per me.

La mia preferenza è quella di scrivere un piccolo pezzo, verificare che funzioni come mi aspetto. Quindi, in teoria, sono libero di dimenticare i dettagli di quel pezzo e di trattarlo come una scatola nera il più possibile.

— dss539
fonte

12

Ho votato per "... non abbastanza intelligente .." Mi sento così per un bel po 'di tempo.

— leed25d

4

E la tua cache L2?

— Mateen Ulhaq,

Stavo per votare questo, ma il punteggio è a 42 ...

— Wayne Werner

I modelli più recenti hanno cache L1 molto più grandi. Quando hai comprato il tuo? Potresti voler andare per un aggiornamento hardware.

— Peter Ajtai,

Beh, non è l'età del modello tanto quanto il fatto che fosse la linea "budget". :(

— dss539

17

Mi piace scrivere il mio test prima di scrivere il mio codice di implementazione. Mi piace per tre motivi:

Scrivere prima il mio codice di prova mi aiuta a pensare a come usare il mio codice. Mi aiuta a pensare a casi limite a cui non avevo pensato quando stavo progettando il mio programma.
So di aver finito di scrivere il codice di implementazione quando tutti i miei casi di test passano.
L'abitudine di scrivere test prima del codice ha anche l'effetto di essere in grado di dimostrare che il tuo codice non ha aggiunto nuovi bug (supponendo che tu abbia scritto buoni casi di test).

— David Weiser
fonte

2

"So di aver finito di scrivere il codice di implementazione quando tutti i miei casi di test passano." - Come si determina se sono stati scritti tutti i casi di test necessari?

— dss539,

1

Questa è un'ottima domanda. A mio avviso, non puoi mai essere completamente certo che il tuo codice funzioni correttamente se non hai una prova formale che lo afferma. Considero i test unitari come prova del fatto che il tuo codice tende a fare ciò che intendi. Tuttavia, con l'aumentare delle funzionalità che aggiungi, probabilmente aumenterà anche il numero di casi di test che scriverai. In caso di dubbi, chiedi a qualcun altro di esaminare i tuoi casi di test e di chiedere loro casi a cui non hai pensato.

— David Weiser,

4

@ David - come si può dimostrare formalmente che la prova formale non ha errori? Come dimostrate formalmente che i requisiti percepiti da voi corrispondono ai requisiti nella realtà. Puoi formalmente dimostrare che una descrizione corrisponde a un'altra, ma è perfettamente possibile che entrambe le descrizioni siano errate allo stesso modo, specialmente se entrambe le descrizioni sono state scritte dalla stessa persona. Scrivere cose in notazione matematica non rende le persone infallibili. Enormi numeri di "prove" matematiche hanno dimostrato (dopo lunghi periodi di controlli molto dettagliati) di essere sbagliate.

— Steve314,

1

@ Steve314: AFAIK, quando si dimostra formalmente la correttezza di un algoritmo, si specifica esattamente e in modo conciso quale sia la correttezza prevista. Si mettono un punto buono, però, che la definizione di "correttezza" non può in realtà essere corretto.

— David Weiser,

1

@ dss539, che deriva dai casi d'uso che il programma intende implementare.

4

Mi ritrovo a scrivere codice per ore, persino giorni senza eseguire il compilatore per tutto tranne che un controllo occasionale della sintassi.

Ore o giorni - questo è un chiaro segno che ti manca la possibilità di scomporre il tuo codice in blocchi più piccoli che possono essere verificati e testati da soli. Dovresti assolutamente lavorarci su.

Tendo a scrivere pezzi di codice più grandi con attenzione e testare a fondo solo quando sono convinto che il codice faccia quello che dovrebbe fare analizzando il flusso nella mia testa.

Invece di scrivere blocchi di codice più grandi - e quindi complicati - che richiedono ore per essere analizzati nella tua testa, dovresti provare a creare blocchi di costruzione più piccoli, non così grandi. Questo si chiama costruire astrazioni - e questo è l'essenza di una buona programmazione, sicuramente non un segno di essere un principiante.

Un'eccellente programmazione è come un'eccellente riproduzione di Billard: un buon giocatore non gioca a colpi duri. Invece, gioca in un modo in cui dopo ogni colpo le palle si fermano in una posizione in cui il colpo successivo è di nuovo facile. E un programmatore non è bravo perché può scrivere codice complicato - è bravo perché può evitare di scrivere codice complicato.

— Doc Brown
fonte

3

Compilare e testare se una delle seguenti condizioni è soddisfatta:

L'ultima compilazione è stata effettuata 15 minuti fa
L'ultima compilazione è stata effettuata 25 righe fa
Nuova funzione / subroutine è stata implementata
Grosso cambiamento
Nuova funzione (o un bug travestito da funzione)
Bug fix (rimossa una "caratteristica")
Sono annoiato

— Mateen Ulhaq
fonte

1

La frequenza con cui eseguo e collaudo il codice dipende dalla lingua con cui sto lavorando in quel momento. Se sto codificando una procedura memorizzata, di solito aspetterò fino a quando tutto è lì.

D'altra parte, se sto programmando in Lisp, proverò ciascuna funzione dopo averla digitata.

Se sto codificando in Haskell, in genere eseguirò una compilazione dopo ogni funzione per rilevare eventuali errori di tipo ed eseguirò il codice dopo aver fatto tutto.

— Larry Coleman
fonte

1

Scrivo il codice sufficiente per rendere il test verde. Ciò significa che eseguo il test ogni pochi minuti. Questo è il mio stile C ++. Tuttavia in Ruby utilizzo l'autotest, quindi ogni volta che premo Salva ottengo feedback sui test tramite un bel popup. Non smetto nemmeno di scrivere codice, succede solo in background.

— Nazgob
fonte

1

Tre volte all'ora, che ne abbia bisogno o meno.

Facciamo la programmazione test-first e impegniamo solo il codice funzionante sul VCS. Smolderbot va e controlla il repository ogni 20 minuti ed esegue la suite di test. Eventuali guasti vengono immediatamente inviati all'intero team di programmazione per la correzione immediata.

— Andy Lester
fonte

1

Per me non si tratta di quanto scrivo. Posso scrivere migliaia di righe di codice semplice senza doverlo testare. Ma quando scrivo codice più difficile, tendo a testare ciascuna funzione singolarmente dopo averne scritto un insieme coerente.

A volte, tuttavia, vedere il tuo codice in esecuzione è un enorme stimolo motivazionale, quando non esegui nulla da un po 'di tempo è bello vederlo funzionare.

— dan_waterworth
fonte

0

Per me; -
Breve sequenza temporale (non c'è molto tempo per pensare) - scrivere codice, compilare, testare. debug
Tempo sufficiente - mentre (fatto) {scrivere codice piccolo, compilare}, test, debug

— Manoj R
fonte

Trovo che il primo richieda più tempo del secondo: devi eseguire il debug di più se hai un ciclo test / write molto piccolo.

— Frank Shearar,

Può essere. Ma una breve cronologia indica che il culo è in fiamme e il manager ha bisogno di un rapporto che dice che alcune attività sono al 100%.

— Manoj R,

0

Provo per ogni concetto di codifica. A volte questa è una funzione o classe e talvolta non è altro che un'istruzione if. Una volta che il concetto funziona, passa a quello successivo.

— Dave
fonte

0

Provo a scrivere test prima del codice. Eseguo i test almeno due volte prima di un commit. Quindi viene eseguito nuovamente con il server di integrazione continua.

— dietbuddha
fonte