Quasi ogni programmatore avanzato afferma che è molto utile leggere il codice di altri professionisti. Di solito consigliano open source.
Lo leggi o no? In tal caso, con quale frequenza e qual è la procedura di lettura del codice? Inoltre, per i neofiti è un po 'difficile gestire SVN - un mucchio di file. Qual è la soluzione?
Risposte:
Lo leggi o no?
Sì.
Se lo fai, quanto spesso
Quotidiano. Costantemente. Lavoro con numerosi progetti open source (principalmente relativi a Python) e devo leggere la fonte perché è la documentazione più accurata.
e qual è la procedura per leggere il codice?
Um. Apri e leggi.
Inoltre, per i neofiti è un po 'difficile gestire SVN - un mucchio di file. Qual è la soluzione?
Apri e leggi. Quindi leggi di più.
Non è facile. Niente lo rende facile. Non c'è Royal Road da capire. Ci vuole lavoro.
Ci sono diversi livelli nell'enigma che hai. Innanzitutto, inizia da un livello elevato, una visione a volo d'uccello per così dire. Dopo aver verificato un progetto, ci sarà un mucchio di file in una struttura di directory. È lo stesso se stai guardando open source o closed source (dopotutto il codice sorgente è il codice sorgente). Quindi inizia con questo:
Ci vuole pratica, ma è sicuramente fattibile. Più conosci le librerie e i framework utilizzati dall'applicazione, più sai come organizzare 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 la ottieni. Questo è quando leggere il resto del codice ha molto più senso.
Non è come leggere un romanzo, ma più come leggere un libro di consultazione. Un buon modo è quello di scegliere un bug risolto di recente da un messaggio di check in, fare una diff di 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 bug divertenti da individuare perché nei forum si discute molto su di loro. Quindi scegli uno dei bug "frutta bassa" dal tracker dei bug e leggi fino a quando non capisci come risolverlo da solo. La maggior parte dei professionisti della lettura del codice è incidentale nel corso della correzione di bug o dell'aggiunta di funzionalità.
Di solito i migliori esempi di codice sono appena percettibili. Li capirai all'istante senza leggerli più di una volta. Lo fanno sembrare estremamente facile da scrivere, anche se il codice buono di solito passa attraverso molte bozze. Produce la sensazione paradossale che ovviamente il codice dato sia il modo ovvio per farlo, anche se non è il primo modo in cui hai pensato.
Quando ti imbatti in un codice del genere, cerca di capire l'intuizione che è stata introdotta per scriverlo e i principi di progettazione coinvolti, quindi quando ti trovi in una situazione simile in futuro, puoi sperare di applicare gli stessi principi.
Un trucco che uso abbastanza spesso quando leggo alcune funzioni complicate, il segmento di codice è iniziare a refactoring in qualcosa di più leggibile senza cambiare la logica.
Come è difficile affrontare "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 inetto (o, in casi estremi, entrambi).
Inizia a leggere, prova a trovare alcuni punti di accesso o classi / metodi pivot essenziali e costruisci una comprensione di come tutto procede da lì. Non sarà istantaneo, ci vorrà del tempo, ma può essere fatto anche se non c'è alcuna documentazione.
La cosa migliore che puoi sperare quando leggi il codice di un altro progetto, sia esso un'API o un software, è che le variabili, le funzioni e i nomi delle macro non sono abbreviati in modo ambiguo o nominati in modo da poter 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 per essere in grado di immergersi in un codice complesso.
Attualmente sto cercando di vedere come Lua fa un po 'della sua magia, ma sto arrivando al punto sopra dove molti identificatori sono nominati vagamente e piuttosto abbreviati al punto in cui non riesco a capire quale linea sta provando per fare ciò che so deve essere fatto ad un certo punto nel codice della funzione ... Le frequenti variabili a lettera singola e i nomi di macro / funzioni piuttosto abbreviati mi stanno facendo impazzire.
Dopo aver esaminato il "Primo, inizia dall'alto, una visione a volo d'uccello" come suggerito da @Berin Loritsch puoi cercare unittest e / o test di integrazione se ce ne sono.
gli unittest sono interessanti per vedere come funzionano i (api-) dettagli.
il test di integrazione di solito offre una buona panoramica dei processi aziendali.