In che modo lo sviluppo di applicazioni Web in linguaggio compilato staticamente diventa efficiente?

Lavoro su un codice base in un linguaggio compilato (Scala) che è lungo decine se non centinaia di migliaia di righe. La prima cosa che si fa comunemente in tali situazioni è quella di suddividere l'applicazione in microservizi che di solito raggiungono il massimo di due o tremila righe di codice ciascuna, distribuite tra forse 50 file sorgente. Molti sono molto più piccoli.

Successivamente, come altri hanno menzionato, si utilizza la compilazione incrementale, quindi si sta solo ricompilando una manciata di file ogni volta, non l'intero progetto. Questo tempo di compilazione è generalmente sotto un secondo. Le build pulite sono riservate ai server di integrazione continua.

In terzo luogo, su progetti di queste dimensioni, raramente apri un browser per testare, almeno se non sei un progettista UX e la maggior parte del codice dei progetti più grandi è nel back-end. I miei test di ciclo rapido sono tutti test unitari, che sono assolutamente fondamentali per mantenere la consegna continua su un progetto di queste dimensioni. Se escludo i test di integrazione, di solito riesco a eseguire un ciclo di scrittura / compilazione / test in 5-10 secondi, e questo è il test per l'intero microservizio, non solo per la piccola parte su cui sto lavorando. È più veloce se lo limito solo alla classe su cui sto lavorando.

So che è più veloce di un ciclo di test di scrittura / aggiornamento / manuale del browser, ei miei test di unità stanno testando più cose con più precisione di una lattina umana. Dovrebbe essere al punto in cui i tuoi test unitari sono così buoni, puoi lavorare su di loro tutto il giorno, quindi avere un buon set di test di integrazione automatici e controllarlo manualmente in un browser reale è solo una formalità prima di spingere i cambiamenti.

In altre parole, il flusso di lavoro non è inefficiente a causa del compilatore nel ciclo, ma a causa dell'essere umano nel ciclo. Poiché il tuo codice base è scalabile, è quello che devi tenere in considerazione.

C'è uno strumento ampiamente utilizzato per Java che ti permette di ricaricare le classi al volo quando vengono ricompilate. L'ho usato ed è affidabile per il tipo di cosa di cui stai parlando. Combinalo con un IDE che compila ogni classe in fase di salvataggio (più velocemente di quanto io possa battere le palpebre), è fondamentalmente simile a quello che descrivi. Non so se esiste qualcosa di simile per Go, ma è stato fatto per le lingue compilate.

La nicchia di Go è in realtà servizi di back-end. Mentre Go può certamente gestire il tuo blog, il suo scopo principale è quello di fare il sollevamento più pesante sul back-end in cui la parte di progettazione e codifica del ciclo di sviluppo è in genere più coinvolta. Quindi l''inefficienza' dell'attesa per la compilazione non è un fattore importante.

Inoltre, c'è una certa prospettiva in gioco. Il ciclo di risultati code-compile di Go è più lento di PHP, ma d'altra parte è significativamente più veloce di C ++.

Non compilare tutto dopo aver modificato una singola riga in un singolo file è una parte importante del modo in cui manteniamo i tempi di compilazione bassi. Questo è in parte ciò che rende gli strumenti di gestione delle build come Make o Gradle molto meglio per questo rispetto ai linguaggi di scripting generici come Bash o Groovy. Ovvero, Make and Gradle fornisce una sintassi semplice per definire le dipendenze, mentre Bash e Groovy no. Invece di ricompilare tutto, ricompiliamo solo le cose che sono cambiate e le cose che dipendono (direttamente o in modo transitorio) da ciò che è cambiato.