Come leggi il codice di altri? [chiuso]

Do you read it or not?

Sì.

If you do, how often

Daily. Costantemente. Lavoro con numerosi progetti open source (principalmente relativi a Python) e deve leggere la fonte perché è la documentazione più accurata.

and what's the procedure of reading the code?

Um. Apri e leggi.

Also, it's a bit difficult for newbies to deal with SVN - a bunches of files. What's the solution?

Apri e leggi. Quindi leggi di più.

Non è facile. Niente lo rende facile. Non c'è una strada reale da capire. Ci vuole lavoro.

Ci sono molti livelli nell'enigma che hai. Per prima cosa, inizia all'altezza, per così dire, a volo d'uccello. Una volta verificato un progetto, ci sarà un mucchio di file in una struttura di directory. È lo stesso se stai guardando l'open source o il closed source (il codice sorgente è tutto sommato il codice sorgente). Quindi inizia con questo:

• Come sono organizzati i file sorgente? Puoi dire con il nome del file o il nome della directory che contiene quello che potresti trovare all'interno? Noi programmatori tendiamo ad apprezzare i nomi prevedibili e la struttura logica. Dovresti essere in grado di avere un'idea approssimativa di dove cercare un problema specifico.
• Qual è la natura dell'applicazione, è basata sul web, riga di comando, GUI? La ragione per cui è importante è che vuoi sapere da dove iniziare a tracciare l'esecuzione. Se è basato sul Web, si desidera iniziare da dove inizia l'elaborazione della richiesta. Se è costruito su un quadro, tanto meglio. Una volta che conosci il framework, di solito riesci a capire il codice che c'è. Altrimenti inizierai con il rispettivo punto di ingresso per la riga di comando / l'applicazione GUI.
• Prendi un foglio di carta e una matita, o se sei fortunato con una lavagna e pennarelli cancellabili a secco. Dare i nomi dei componenti (o utilizzare quelli forniti nel codice) e tracciare linee tra le caselle con le frecce in modo da poter vedere come vengono elaborate le cose. In alternativa, se stai guardando un algoritmo, disegna le strutture dei dati in modo da capire e delineare come viene manipolato.

Ci vuole pratica, ma è sicuramente fattibile. Più conosci le librerie e i framework utilizzati dall'applicazione, più sai come deve essere organizzato il codice e dove cercare le risposte a domande specifiche. Alcuni codici sono un po 'più difficili da seguire, in particolare se sono abbastanza indiretti. Ecco perché hai bisogno di carta e matita. Alla fine una lampadina si spegne nella tua testa e tu capisci. Questo è il momento in cui leggere il resto del codice ha molto più senso.

Non legge come leggi un romanzo, ma più come leggi un libro di riferimento. Un buon modo è scegliere un bug risolto di recente da un messaggio di check-in, fare una differenza tra ciò che è cambiato e leggere le parti rilevanti fino a quando non si capisce sia il problema che la soluzione. Le vulnerabilità di sicurezza ben pubblicizzate sono dei bug divertenti da scegliere perché ci sono molte discussioni su di loro sui forum. Quindi seleziona uno dei bug "low hanging fruit" dal bug tracker e leggi fino a quando non capisci come risolverlo da solo. La maggior parte dei professionisti di lettura del codice è incidentale nel risolvere bug o aggiungere funzionalità.

Di solito i migliori esempi di codice sono appena visibili. Li capirai all'istante senza leggerli più di una volta. Fanno sembrare che sia estremamente facile da scrivere, anche se il codice di solito va bene in molte bozze. Produce la sensazione paradossale che ovviamente il codice dato sia il modo più ovvio per farlo, anche se non è il primo modo a cui hai pensato.

Quando ti imbatti in un codice del genere, prova a capire l'intuizione che è stata scritta e i principi di progettazione coinvolti, quindi quando ti ritrovi in una situazione simile in futuro puoi sperare di applicare gli stessi principi.

Un trucco che uso abbastanza spesso durante la lettura di alcune funzioni complicate, il segmento di codice è quello di iniziare a refactoring in qualcosa di più leggibile senza cambiare la logica.

Come è difficile gestire "un mucchio di file"? Non è diverso da quando scrivi il tuo codice, tranne che non hai una conoscenza preliminare della sua organizzazione a meno che non sia documentato.

Se tu, come programmatore affermato, non riesci a capire la struttura del progetto da "un mucchio di file" o è un progetto estremamente mal organizzato, o sei un programmatore incapace (o, in casi estremi, entrambi) .

Inizia a leggere, prova a trovare alcuni punti di ingresso o altre classi / metodi pivot essenziali, e costruisci una comprensione di come tutto si unisce da lì. Non sarà istantaneo, ci vorrà del tempo, ma può essere fatto anche se non c'è affatto documentazione.

La cosa migliore che puoi sperare quando leggi il codice di un altro progetto, che si tratti di un'API o di un software, è che le variabili, le funzioni e i nomi macro non sono abbreviati in modo ambiguo o nominati in modo che tu possa capire il loro intento .

Ma a parte questo, ci vuole una discreta quantità di conoscenza diffusa attraverso il linguaggio, le tecniche di programmazione e anche lo scopo del codice stesso di essere in grado di immergersi in un codice complesso.

Al momento sto provando a vedere come Lua fa parte della sua magia, ma sto arrivando al punto in cui molti degli identificatori sono nominati vagamente e piuttosto abbreviati al punto in cui non riesco a capire quale linea sta cercando di fare la cosa che so deve essere fatta ad un certo punto nel codice funzione ... Le variabili a singola lettera frequente e i nomi di macro / funzioni piuttosto abbreviati stanno facendo di testa.

Dopo aver guardato il "Primo, inizia al livello più alto, una vista a volo d'uccello" come suggerito da @Berin Loritsch, puoi cercare gli unittests e / oi test di integrazione, se ce ne sono.

unittests sono interessanti per vedere come funzionano i (api-) dettagli.

integrationtest di solito offre una buona panoramica sui processi di busine.