C'è un vantaggio nel compilare il tuo codice mentre vai avanti?

Is there actually a benefit to compiling as you go along?

C'è. Ti dà un ciclo di feedback più breve - che in generale, quando si progetta (UI, software di scrittura, design visivo ecc ...) è una buona cosa.

Un ciclo di feedback breve significa che puoi correggere rapidamente gli errori nelle fasi iniziali, prima che diventino più costosi da correggere.

Per prendere in prestito il tuo esempio, dì che stavi codificando in un linguaggio simile a C e hai dimenticato un } da qualche parte nel mezzo del programma.

Se compili subito dopo aver finito di scrivere la dichiarazione, puoi essere certo di aver appena introdotto l'errore di compilazione e puoi aggiustarlo lì e poi, in pochi secondi.

Se non lo fai, tuttavia, dovresti trascorrere una buona quantità di tempo leggendo il codice, cercando la posizione esatta che } è e assicurandoti, una volta individuato l'errore che la correzione è davvero quello che era inteso. Questo avrebbe avuto luogo un po 'dopo che avresti lasciato quel pezzetto di codice. Non sarebbe chiaro come nel momento in cui l'hai scritto.

Ora, sì, il risultato finale è lo stesso, ma hai sprecato una buona quantità di tempo sui problemi sintattici che il compilatore è lì per aiutarti - una quantità di tempo che potrebbe essere significativamente più breve se hai compilato mentre procedevi.

Compilare è una forma di test, specialmente nelle lingue che fanno ampio uso di tipi come Haskell o ML . In altre lingue è una scansione sintattica che ti dice poco.

Detto questo, "compilare mentre si va" mi sembra un'abitudine molto situazionale. Si potrebbe anche essere contrassegnati per essere "nervosi" per la compilazione più frequentemente rispetto al pregiudizio personale dell'intervistatore. Sembra un pelo nell'uovo; a nessuno piace ammettere che un intervistato abbia eseguito il test; indica le scale della negoziazione salariale.

Non tutti i sistemi di compilazione sono veloci. Ho lavorato a un progetto (C ++) in cui Crea avrebbe speso 30 secondi solo stat 'ting tutto per determinare se è necessario creare o meno, e la maggior parte dei file richiederebbe un paio di minuti per essere costruita se tu avessi fatto i cambiamenti. Eravamo riluttanti a farlo più frequentemente di ogni 10-15 minuti. Qualcuno fornirà indubbiamente un aneddoto su quando compilare ha coinvolto il prendere il tuo mazzo di carte perforate e portarle in un altro edificio ...

Compilati quando ritieni di avere completato un'unità concettuale nella tua testa e sei pronto per farlo convalidare. Una volta al minuto o una volta alla settimana a seconda del flusso di lavoro.

So my question is this: Is there something I missed?

Sì: la tua mente non è un compilatore. Mentre un compilatore può creare n interruttori di contesto al secondo, la tua mente non può. Il numero di cambi di contesto che la tua mente può rendere in un giorno dipende da una serie di fattori come esperienza / familiarità con la base di codice, quanto mentalmente immerso sei nel codice, quanto è pulito il codice, quanto complesso è il problema che stai affrontando, quanto sei stanco, se vieni frequentemente interrotto o in un ambiente rumoroso e così via.

La compilazione di un codice base (tutto allo stesso tempo), per la prima volta (si pensi a "progetto con 20 file") ti costringerà a cambiare contesto da ciò a cui stai pensando (ad esempio "questo valore è impostato su 5 qui , quindi nel ciclo for blablabla, e l'algoritmo complesso restituisce il valore corretto al ritorno ") a un problema di compilazione completamente non correlato a quello a cui stai pensando (diversi file / modulo / funzione / pre-condizioni / sintassi / nomi di variabili , precondizioni ecc.)

Più codice compilerai contemporaneamente, più cambi di contesto dovresti fare la tua mente. Questo non è un problema per una piccola base di codice, quando tutto il codice che hai scritto è quello che hai scritto in un'ora. È un grosso problema, però, quando si lavora in una base di codice esistente, con interdipendenze multiple (e molte volte non documentate).

Is there actually a benefit to compiling as you go along?

Riduci al minimo i cambiamenti di contesto che la tua mente deve fare, permettendoti di concentrarti maggiormente sull'impatto e gli effetti collaterali delle modifiche che apporti. Ti rende anche meno stanco (e meno incline agli errori) e aumenta la qualità del tuo output (ovvero puoi garantire effetti collaterali minimizzati più facilmente quando cambi e compili un file alla volta, rispetto a quando lo compili e ne modifichi dieci).

Se si compila in iterazioni molto brevi (questo presuppone che il processo di compilazione sia ottimizzato per richiedere un breve periodo di tempo) è possibile correggere gli errori di compilazione senza uscire dalla "zona".

Or is this some sort of myth propagated by the software community that you must compile your code frequently?

È propagato anche dalla comunità del software, ma ha buone ragioni dietro di esso.

In my understanding that's an invalid argument, because "getting code to compile" for a given length of code generally involves fixing a constant number of compile errors and takes a fairly constant amount of time

Mi sembra che tu abbia poca (o nessuna) esperienza, nel mantenimento di basi di codice legacy medio-grandi (centinaia o migliaia di file sorgente). È qui che questo atteggiamento (ad esempio "compila come vai") ti aiuterà di più, ed è qui che formi questo tipo di abitudine.

Immaginerei che le persone che ti hanno intervistato abbiano tratto una conclusione simile ("hai poca o nessuna esperienza in basi di codice di grandi dimensioni").

Penso che qui ci sia più che un po 'di snobismo professionale. L'implicazione sembra essere "se non hai mai avuto la necessità di compilare regolarmente, quindi non hai mai lavorato con qualcosa di così complicato - vai a fare esperienza e torna quando hai imparato a lavorare esattamente come facciamo noi".

Ma ovviamente c'è un altro lato in questo. Alcuni progetti richiedono un'età da compilare. Ho lavorato con framework che impiegano 30 minuti o più per compilare anche dopo modifiche minori. Il cielo ti aiuta se hai mai bisogno di modificare un file di intestazione. Le ricompense complete vengono in genere eseguite durante la notte e, se ti affidi al compilatore per cogliere i tuoi errori, ci sono ancora errori rari che non verranno rilevati durante una compilazione parziale. Non ti ricompilare ogni 5 minuti in queste condizioni: a meno che non ti senta pigro .

Il compilatore non può aiutarti con errori logici o semantici e gli errori di sintassi non sono così difficili da evitare che spendere la metà della tua giornata di compilazione diventi utile. Ovviamente, farai l'errore di battitura occasionale, ma suppongo che tu possa sia digitare sia leggere. Se hai la libertà di scegliere, usa uno stile di codifica che faccia buon uso del layout per evidenziare visivamente gli errori e non abbandonerai mai più una parentesi graffa, parentesi o punto e virgola. Ci vuole un po 'di pratica e un po' più di disciplina a cui la maggior parte è abituata, ma è possibile. Posso scrivere codice per un paio d'ore alla volta, in un editor di testo semplice, e compilarlo per la prima volta meglio di nove volte su dieci. Certo, potrei compilare più spesso, ma non riesco a ricordare l'ultima volta che ho avuto un errore che sarebbe stato più facile da correggere come risultato.

Se non sei un fan della costante ricompilazione, sei in buona compagnia. Ecco Donald Knuth:

As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about.

Tutto ciò detto ... se stai lavorando in un contesto in cui la compilazione è un'azione gratuita, perché no? A casa, su progetti personali, premo ctrl-S circa una volta ogni 30 secondi e la scorciatoia "compile" quasi altrettanto spesso, in un IDE che esegue costantemente il codice attraverso il front-end del compilatore per fornire l'evidenziazione degli errori in tempo reale. Perché passare un pranzo gratis?

Ci sono dei meriti da compilare man mano che vai. Ma sono assolutamente d'accordo sul fatto che rimanere in attività sia una strategia di codifica OK.

Il vantaggio più significativo della compilazione incrementale è la mentalità che molti entrano se aspettano la fine per compilare e testare : siamo più preoccupati alla fine nell'ottenere il codice per l'esecuzione di qualsiasi cosa altrimenti a quel punto. Diciamo "Oh, ho solo bisogno di aggiungere questa parentesi in modo che il compilatore smetta di lamentarsi" o "oh, solo bisogno di capitalizzare questo" senza pensare se c'è un errore semantico sottostante che questo errore di sintassi nasconde. Trovo davvero che gli errori sintattici spesso si annidano negli errori semantici (il contrario non è vero).

Ad esempio, diciamo che ho cambiato il significato di una variabile e, di conseguenza, ho cambiato il suo nome. La modifica del nome genera un errore di sintassi più avanti nel codice, ma se mi limito a compiacere il compilatore correggendo il nome, ho ignorato perché quell'errore è venuto alla luce.

In realtà sono d'accordo con te che gli errori del compilatore non dovrebbero essere un grosso problema per uno sviluppatore esperto. Non credo che il costo di fissarli aumenti in modo significativo nel tempo da preoccupare. Se fosse possibile posticipare la correzione di tutti gli errori del compilatore fino a poco prima di un push, lo farei, poiché presenterebbe un'interruzione molto più piccola e più consolidata.

Sfortunatamente, trovare gli errori del compilatore non è l'unica cosa che fanno i compilatori. A rischio di affermare l'ovvio, è richiesta la compilazione per eseguire il programma, e l'esecuzione del programma è necessaria per trovare tutti i bug di runtime più complessi, sottili e interessanti che persino gli sviluppatori esperti hanno creato. E quei tipi di bug sono più difficili e quindi più costosi da sistemare, più rimandano il debugging, perché possono svilupparsi o mascherarsi a vicenda.

Tuttavia, non necessariamente contrassegnerei qualcuno durante un colloquio per posticipare la compilazione fino alla fine. Gli esercizi di intervista tendono ad essere molto semplici e gli sviluppatori esperti di solito conoscono i loro limiti. Più sei sicuro di ciò che hai scritto, più a lungo andrai tra le compilazioni. Questa è solo la natura umana.

Tuttavia, per non contraddistinguerla, la fiducia dovrebbe essere giustificata. Se avessi passato 45 minuti a scrivere qualcosa senza compilare, quindi ho impiegato altri 45 minuti per eseguirne il debug, avrei pesato così pesantemente contro di te.

I understand the benefits of testing your code as you go along, but why compiling?

Ma come testerai il tuo codice mentre vai avanti quando non lo compilerai di conseguenza?

Il caso estremo è sviluppo basato sui test (TDD). È ovvio che TDD non funziona con la tua strategia, dal momento che TDD significa cicli estremamente brevi di write-test, compilazione (dovrebbe fallire), scrivere codice, compilare di nuovo, eseguire test, correggere bug, compilare di nuovo, refactoring, compilare -again, run-test, and-so-on ...

Quindi non tutti fanno TDD, almeno non sempre (anche io, lo ammetto). Con la tua strategia attuale, non avrai mai la possibilità di provare TDD. Ma anche quando non stai facendo TDD, è IMHO estremamente utile testare il tuo codice in modo più regolare, cosa che non è possibile quando non lo compili regolarmente. E quando il tuo test fallisce, stai eseguendo il debug di esso (che può aiutarti a capire perché l'algoritmo di bell'aspetto che hai scritto qualche minuto prima non si comporta in modo così bello come pensavi dovesse fare). E più codice scrivi senza compilarlo, più codice scrivi senza test, quindi più è probabile che ti imbatti in un caso in cui non puoi prevedere che il tempo per risolvere il problema è " O (1) ", come hai scritto.

L'unica cosa importante della compilazione spesso, mancante da altre risposte per quanto posso vedere è questa: se si compila raramente e si ottiene una grande quantità di errori del compilatore, la maggior parte di questi non ha senso, perché sono generati dal primo errore. Potrebbe essere perché hai sbagliato tipo, o errore di digitazione, o errore di sintassi normale che rende una dichiarazione non valida.

È sempre possibile correggere il primo, ricompilare, correggere quello successivo e così via, ma con un codice di grandi dimensioni può essere lento. Ma se cerchi di sfogliare la lunga lista di errori del compilatore e di errori spot che sono indipendenti, passi molto tempo a leggere messaggi irrilevanti o a navigare dal punto di errore secondario a una vera causa.

Un altro aspetto delle build regolari è che nulla ti impedisce di iniziare a compilare non appena hai un blocco completo di codice scritto, che dovrebbe essere compilato. È quindi possibile continuare a scrivere altro codice mentre la compilazione continua, finché non si salvano le nuove modifiche fino al termine della compilazione. Quindi non c'è praticamente tempo perso nell'attesa della costruzione. Se aspetti di aver scritto tutto ciò che scrivi in quel momento, dovrai aspettare la compilazione senza nulla da fare. Questa è fondamentalmente la versione manuale di ciò che gli IDE moderni possono fare in background automaticamente.

Per un programmatore sufficientemente esperto la compilazione del codice non è mai il collo di bottiglia.

Una volta che conosci una lingua abbastanza bene (cioè quando non devi più pensare alla sintassi e invece basta codificare per la funzionalità) tendi a non fare semplici errori sintattici. Quelli che fai sono di solito errori di battitura o di copia-incolla, e possono essere ripuliti in breve tempo con pochi passaggi di compilazione.

Scrivo regolarmente il codice tutto il giorno senza compilare, quindi compilerò e correggerò solo gli errori di sintassi e gli avvisi che il compilatore segnala prima di eseguire il commit del codice (con una nota che dice "deve essere testato!" ). Non ho problemi a pulire oltre 1.000 righe di codice C o C ++ in pochi minuti.

Il debug e il test d'altra parte sono ciò che richiede un po '. Gli errori logici sorgono per tutti i tipi di motivi e devo ancora incontrare un compilatore che mi descriva la subroutine che ho completamente dimenticato di scrivere, o noterò che il mio albero binario non funziona perché ho incollato node->left quando avrebbe dovuto stato node->right .

Anche se penso che generalmente non sia saggio combattere con un intervistatore, direi se ritenessi che il tuo stile meritasse di essere difeso, dovresti aver sottolineato che ti sei lasciato abbastanza tempo per eseguire il debug del codice che Ho scritto. Questa è la cosa che nessun buon programmatore trascura mai.

P.S. - Se ti stessi guardando mentre leggi il codice leggendolo, ti avrei assunto sul posto. Questo è ciò che fa un professionista, ogni volta.

No, non è irragionevole tenere a bada la compilazione finché non hai fatto una quantità sufficiente di codice (e una "quantità sufficiente" dipende dal codificatore e dal codice che stai scrivendo).

Ad esempio, se sei un programmatore fantastico che si prende il tempo per farlo bene e non stai scrivendo grandi quantità o codice complicato, compilare regolarmente è uno spreco e probabilmente anche una distrazione. Se non lo sei, compilare ogni funzione può essere una buona cosa. Dipende dalla persona.

Come contro-esempio, immagina di scrivere codice JavaScript - non c'è compilatore. Invece (data la natura della maggior parte del codice JavaScript) dovresti eseguire il programma (o aggiornare la pagina) per vedere i risultati della tua codifica. Ora, non puoi farlo finché non hai scritto abbastanza codice per avere un senso. Di conseguenza, gli sviluppatori di JavaScript tendono a "compilare" tutte le volte che possono, il che non è necessariamente molto spesso.

In breve, non c'è una risposta corretta qui - l'intervistatore non ha torto, ma nemmeno tu. Fai ciò che ti rende produttivo e dimentica ciò che qualcuno ti dice che dovresti fare. Ci sono fattori molto più importanti sulla codifica rispetto alla tendenza a colpire F7 regolarmente (o meno) è assolutamente senza conseguenze.

Con un buon ambiente di sviluppo vedo pochi motivi per essere compilato a meno che tu non stia pianificando di testare il codice. Gli strumenti di controllo della sintassi in background catturano la maggior parte di ciò di cui sembra parlare l'intervistatore, anche se ammetterò che ci sono ancora alcuni casi (che implicano modifiche che si propagano tra file) che non sono sempre completamente identificati.

Detto questo, cercherò di compilare ed eseguire praticamente la più piccola unità di codice che possa effettivamente produrre un risultato. Mezz'ora fa stavo creando un mezzo per stampare alcuni risultati di ricerca e ho fatto una mezza dozzina di stampe di prova (in formato .pdf, non in carta) apportando modifiche al risultato per renderlo migliore - un tasso di circa 1 compilazione per 10 linee.

In my opinion and in my experience, whether or not a piece of code compiles is essentially random, involving things like whether or not semicolons are missing, and has little to do with the correctness of the underlying program. (To me, focusing on compiling is like running an article through a spell-check without proofreading to check the grammar.)

La mia esperienza è molto diversa: meno del 5% degli errori di compilazione che ottengo riguardano la sintassi . Conosco bene il linguaggio, quando ricevo errori è per lo più errori di battitura, dicendomi che la semantica non è corretta.

Ecco perché sono felice di beneficiare il più rapidamente possibile dal feedback del mio compilatore. Hai mai provato a utilizzare un IDE che sottolinea gli errori di compilazione in tempo reale? Avere un ciclo di feedback più breve può essere molto prezioso.

If you give me a piece of incomplete code, the first thing I do will be to read it. I won't even try to compile it until I know what the code is doing and I know the algorithm is correct.

Se ti aspetti di lavorare su un codice scritto da qualcun altro, non hai sempre il tempo di leggere tutto. La buona notizia è che il codice ben scritto ha un basso accoppiamento e dovrebbe consentire di ragionare in modo indipendente solo sulla parte del codice di cui hai bisogno.

In questi casi devi presupporre che il codice che non hai ancora letto sia corretto e investigare pigramente quando c'è un problema.

"getting code to compile" for a given length of code generally involves fixing a constant number of compile errors and takes a fairly constant amount of time, which should be the same whether you do it after you finish writing the code, or if you interleave it with your coding time.

Il cambio di contesto è costoso per il tuo cervello, pertanto correggere piccoli errori non appena li scrivi può essere più efficiente.

EDIT: Posso anche fare un'analogia con il controllo del codice sorgente, quando un'intera squadra sta lavorando alle stesse fonti. Compilare mentre si va avanti è come fare frequenti commit, aiuta ad evitare di avere molto dolore alla fine quando si deve unire e risolvere tutto.

Dici di disabilitare le cose come le linee rosse sotto il tuo testo. Lo fai anche quando scrivi un'e-mail o scrivi un documento tecnico? Quindi devi rileggere di nuovo tutte le pagine invece di correggere gli errori man mano che fai.

Un altro vantaggio è che, quando si lavora sul codice, se si continua a compilare o quasi a compilare in qualsiasi momento, è possibile trarre vantaggio da molte funzionalità IDE basate su semantica (ridenominazione sicura, refactoring, ricerca dell'uso di un simbolo. ..).

Se vuoi avere una migliore comprensione di come queste funzionalità ti aiutano, puoi provare a metterle in pratica e a esercitarti, a sperimentare te stesso i loro benefici. Potresti anche provare a fare un paio di programmazione con chiunque sia abituato a loro, e vedere come loro possono trarne beneficio.

Ci ho pensato un po 'più a lungo, perché sentivo che c'era qualcosa di molto, molto sbagliato con l'intervistatore e non sapevo esattamente cosa fosse. Ecco il problema: per qualsiasi codice che ho scritto negli ultimi venti anni, la quantità di tempo necessaria per trasformare un algoritmo lavorabile in codice che compila è stata minima. Qualsiasi guadagno di efficienza in quell'area ha un impatto così scarso sui tempi di sviluppo totale che è del tutto trascurabile, e un intervistatore che rifiuta un candidato per inefficienze percepite in quell'area non ha idea di cosa sia un buon sviluppatore.

La maggior parte del tempo dovrebbe essere speso per raccogliere informazioni su ciò che il codice dovrebbe fare, raccogliere informazioni e specifiche sui servizi esterni che devono essere utilizzati, creando un progetto globale che porterà a codice corretto e gestibile invece di codice hackerato, e trovare algoritmi che porteranno a un codice funzionante al posto del codice che viene aggiornato insieme fino a quando non funziona (codice che ovviamente non ha errori rispetto al codice che non ha errori evidenti).

Quindi arriva una piccola quantità di tempo per scrivere il codice che viene compilato.

Quindi viene impiegata una quantità maggiore di tempo per assicurarsi che il codice funzioni, e per assicurarsi che sappiamo che il codice funziona e funzionerà. Che viene fatto scrivendo unit test, passando attraverso il codice e in larga misura avendo un codice ben progettato in primo luogo.

Questo intervistatore si è concentrato su qualcosa che è coperto da dieci parole nella mia risposta. Che rappresentano il 10 percento o meno dell'orario di lavoro effettivo. E ha quasi zero influenza sulla capacità di tale sviluppatore di produrre codice affidabile e funzionante.

Le altre risposte qui montano una buona difesa per compilare frequentemente sul lavoro , ma poiché la tua domanda è incentrata su interviste , mi piacerebbe affrontare quell'angolo di esso.

Nelle mie interviste faccio esattamente l'opposto: i candidati non possono usare un compilatore. Scrivono brevi programmi sulla lavagna e poi li discutiamo. Ho scoperto che troppi sviluppatori usano il compilatore (o l'interprete) come una stampella, e questa è una perdita di tempo molto più grande della compilazione troppo rara. Se ti sto offrendo un sacco di soldi e non riesci nemmeno a scrivere FizzBuzz correttamente senza un compilatore, non lo taglierai mai a lungo termine, lavorando su problemi che sono 100 volte più difficili degli esercizi giocattolo nell'intervista. Eppure questi semplici esercizi hanno eliminato più candidati di qualsiasi altra parte dell'intervista.

L'obiettivo di un colloquio è valutare l'idoneità reciproca del candidato e dell'azienda. Una buona domanda di intervista dovrebbe indicare gli obiettivi della domanda e il modo in cui verrà valutato l'intervistato. Sorgere una domanda trabocchetto sull'intervistato e poi penalizzarli per non sapere la risposta nascosta non aiuta l'intervistatore o l'intervistato. Sfortunatamente, la maggior parte dei programmatori - anche quelli di alto livello - non sono addestrati ad intervistare altri programmatori, quindi si affidano solo ai cliché e fanno lo stesso tipo di domande quando intervistarono, senza troppi dubbi sul fatto che si tratti di tecniche efficaci per valutare i candidati oppure no.

Non sto affermando che il mio approccio sia "l'unico vero modo", ma mi è servito molto bene. Come molte metodologie software che iniziano con una lettera maiuscola, ci sono altrettanti "mandati" per l'intervista. Sono tutti a castello. Devi fare ciò che funziona per te e per la tua attività.

Nei progetti più grandi, con diverse subroutine, si desidera testare queste parti, prima di utilizzarle nello schema più grande, poiché è molto più semplice eseguire il debug se si conoscono già determinate parti.

Per testare questi pezzi più piccoli, è necessario compilare.

Potrebbe essere che l'intervistatore confonda questa situazione con un piccolo programma che non è stato progettato in questo modo.

Per quanto riguarda la seconda intervista, un vantaggio della compilazione è che puoi osservare, in pochi secondi, ciò che i programmi fanno (o no). Da lì è più facile leggere il codice e concentrare i tuoi sforzi sulle parti pertinenti. Forse questo è ciò che l'intervistatore si aspettava.

La lettura di una base di codice sconosciuta come questa dall'inizio alla fine può essere abbastanza improduttiva (non sei un compilatore), mentre compilare / eseguire l'applicazione ti darà rapidamente un'immagine più grande.

Il vantaggio di "compilare mentre procedete" è che ottenete un feedback costante e non avrete la possibilità di andare molto lontano prima di essere spinti nella giusta direzione. Per un programmatore competente come te, questa non è una considerazione enorme, ma per molti altri lo è. In altre parole, "compilare mentre procedi" è un modo per "ridurre al minimo la perdita massima", anche se nel tuo caso ci sono alcune potenziali perdite di efficienza.

Le aziende di questi tempi non sono solo interessate a un prodotto finito. Vogliono sapere che è stato "sotto controllo" da sempre. Per loro, "arrivarci è per metà divertente".