Quanto spesso esegui e collaudi il tuo codice durante la programmazione? [chiuso]

Dipende VERAMENTE dall'aspetto del progetto su cui stai lavorando.

• Quando faccio qualsiasi cosa con OpenGL (che funziona come una macchina a stati), compongo e eseguo costantemente per assicurarmi di non aver rovinato accidentalmente nulla. Impostare un valore senza ricordare di reimpostarlo alla fine di una funzione può facilmente rendere l'applicazione solo uno schermo nero.

• Per uno sviluppo su scala più ampia, cerco di fare il maggior numero di test possibile in anticipo. Dato che i test possono dirmi più facilmente cosa si è rotto, posso andare un po 'senza dover attendere la compilazione di solito lunga.

• Per la progettazione di UX, utilizzo una sorta di visual designer, che ha sempre l'aspetto del modo in cui verrà eseguito (o vicino ad esso). Essenzialmente sta sempre compilando il codice di progettazione.

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

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

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

1. Scrivere il mio codice di test prima della mano mi aiuta a pensare a come dovrebbe essere usato il mio codice. Mi aiuta a pensare a casi limite che non avevo pensato quando stavo originariamente progettando il mio programma.
2. So che ho finito di scrivere il codice di implementazione quando passano tutti i miei casi di test.
3. Prendere 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 (ammesso che tu abbia scritto buoni casi di test).

I find myself writing code for hours, even days without running the compiler for anything but an occasional syntax check.

Da ore a giorni: è un chiaro segno che ti manca la capacità di suddividere il tuo codice in blocchi più piccoli che possono essere verificati e testati da soli. Dovresti assolutamente lavorarci su.

I tend to write bigger chunks of code carefully and test thoroughly only when I'm convinced that the code does what it's supposed to do by analysing the flow in my head.

Invece di scrivere blocchi di codice più grandi - e quindi complicati - che richiedono ore da analizzare nella tua testa, dovresti cercare di creare blocchi di costruzione più piccoli, non così grandi. Questo è chiamato costruire astrazioni - e questo è il succo della buona programmazione, sicuramente non è un segno di essere un principiante.

Una programmazione eccellente è come un eccellente Billard che suona - 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 è buono perché può scrivere codice complicato - è bravo perché può evitare scrivere codice complicato.

Compilo e amp; prova se una delle seguenti condizioni è soddisfatta:

• L'ultima compilazione era 15 minuti fa
• L'ultima compilazione era di 25 righe fa
• È stata implementata una nuova funzione / subroutine
• Modifica principale
• Nuova funzionalità (o bug mascherato come funzione)
• Risoluzione di bug (rimossa una "funzione")
• Sono annoiato

Ogni quanto tempo 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 codificando in Lisp, proverò ogni funzione dopo averlo digitato.

Se sto codificando in Haskell, in genere eseguo una compilazione dopo ogni funzione per rilevare eventuali errori di tipo ed eseguire il codice dopo che è stato eseguito tutto.

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

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

Facciamo test prima di programmare e impegniamo solo codice funzionante per VCS. Il smolderbot va e controlla il repository ogni 20 minuti e esegue la suite di test. Eventuali errori vengono immediatamente inviati a tutto il team di programmazione per la correzione immediata.

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

A volte però, vedere il tuo codice in esecuzione è un enorme incentivo motivazionale, quando non esegui nulla da un po 'è bello vederlo funzionare.

Per me; -
Tempi brevi (non c'è molto tempo per pensare): scrivere codice, compilare, testare. di debug
Tempo sufficiente - while (done) {scrittura di piccoli codici, compilazione}, test, debug

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

Cerco di scrivere test prima del codice. Corro i miei test almeno due volte prima di un commit. Quindi viene eseguito di nuovo con il server di Continuous Integration.