Quali sono alcuni buoni approcci per leggere il codice Javascript?

Utilizza i test.

Ho letto il codice con le dita. Stampa il codice e consegnalo a me e vado a occhi sbarrati. Certo, puoi scarabocchiarlo, evidenziarlo, annotarlo e disegnare vignette ai margini, ma soprattutto, eseguo il codice. I test.

Oh, certo che posso dirti cosa fa il mondo strano. Forse decodificare un livello di 3 profondità se non altro labirinto. Ma leggi abbastanza codice e sanguina insieme. Potrei esprimere la mia fiducia nei commenti, ma il debugger non mi ha mai mentito. Mi ha sorpreso da morire, ma non ha mai mentito. Quindi eseguo i test.

Aiuta a leggere la documentazione di tanto in tanto ma in realtà mi aiuta solo a trovare le cose giuste da chiamare, ereditare o chiedere di essere iniettato nei miei test.

Se tutto ciò non riesce, puoi lanciarlo e ottenere la tua copia del codice da eseguire. Poi puoi andare in città a smentire le lunghe sciocchezze in sciocchezze succinte. Farlo mi fa sempre sentire bene, ma soprattutto mi costringe a prestare attenzione a quello con cui sto giocando, quindi non sogno giorno le chimichangas. E se hai intenzione di farlo, ti servono ... test.

CandiedOrange nomina il più importante strumento per capire il codice: il codice stesso. Non puoi sempre fidarti della documentazione, e comunque i documenti sono indirizzati a persone che vogliono semplicemente utilizzare i metodi pubblici dei framework, quindi devi eseguire il codice, ispezionare i valori delle variabili o i valori di ritorno delle funzioni e usare tecniche di debug per capire cosa succede quando il codice non si comporta come ti aspetti. È esattamente giusto.

Ma questo non offre molte indicazioni per un approccio generale al codice. I framework possono variare nello scopo e nella costruzione abbastanza da non applicare un singolo consiglio in tutte le situazioni e ciò che mi aiuta a capire che il codice potrebbe non funzionare per voi, ma ecco cosa farei quando osservo un grande e complesso codice:

1. Decidi quanto hai davvero bisogno di capire. A volte è più semplice aggirare il codice piuttosto che approfondirne i dettagli, e non c'è vergogna nella scrittura di codice che risolva il problema che effettivamente si ha. Se hai davvero bisogno o vuoi capire di più (ad es. Se hai intenzione di realizzare lo sviluppo sul framework stesso), allora ...

2. Guarda il paio di livelli in basso. Se il tuo framework effettua chiamate di rete, i livelli inferiori probabilmente costruiranno le richieste di rete. Se crea oggetti, i livelli inferiori potrebbero occuparsi di come gli oggetti vengono creati, aggiornati e mantenuti. Capire approssimativamente come funzionano le operazioni di alto livello al livello più basso può essere molto utile.

3. Guarda i primi due livelli. Molto spesso un'API avrà una serie di metodi pubblici che chiamano un numero inferiore di metodi privati con alcune opzioni extra. Un ipotetico framework con makeGreenBox e makeBlueBox metodi che chiamano _makeBox(color='green', ...) e _makeBox(color='blue', ...) sarebbe un tipico esempio. Se sai come funzionano, puoi approfittarne quando i metodi pubblici non soddisfano le tue esigenze.

4. Se il framework è scritto in un modo che ha senso per te, questo è probabilmente sufficiente per avere una buona panoramica di come funziona una singola azione: "Faccio una richiesta a foo che delega a _bar con alcune opzioni impostate e alla fine chiama _makeThingy con un bucket di opzioni e restituisce il risultato. " Anche se non puoi farlo ogni volta, dovresti essere in una buona posizione per capire il flusso generale del codice.

5. Inizia a lavorare con il codice. Probabilmente hai avuto qualche motivo per cui volevi capire il framework, in primo luogo, e niente ti farà tanto bene come iniziare a lavorare con il codice e vedere dove ti imbatti nei bordi taglienti. Il dolore è come impariamo. :)

Comprendere assolutamente tutto ciò che riguarda una singola richiesta sembra bello in teoria, ma come hai notato lo stack delle chiamate potrebbe essere molto profondo e potrebbero esserci effetti collaterali complessi. Il potere dell'astrazione è che non abbiamo bisogno di capire ogni linea di codice. È sufficiente iniziare a trattare tutto nel mezzo come una scatola nera che fa quello che dice, quindi ispezionarlo in modo più dettagliato quando necessario.

Il costo iniziale della comprensione (diciamo) di centomila codebase di linee è più grande di quanto è probabile che tu voglia pagare, e probabilmente non ne vale la pena. Avvicinandoti ai bordi e inserendo le tue istruzioni in base alle tue esigenze puoi farti conoscere il codice nel giro di poche ore anziché giorni o settimane. Alla fine imparerai i dettagli se continui a lavorare con esso - e se non continui a lavorare con esso, hai risparmiato un sacco di sforzi inutili.