Come posso migliorare le mie capacità di lettura del codice [chiuso]

Bene, la domanda è nel titolo: come posso migliorare le mie capacità di lettura del codice.

L'ambiente software / hardware in cui sto attualmente sviluppando è piuttosto lento rispetto ai tempi di compilazione e ai tempi necessari per testare l'intero sistema. Il sistema è piuttosto vecchio / complesso e pertanto non è possibile dividerlo in diversi sottoprogetti più piccoli e più gestibili in un prossimo futuro.

Ho capito che ciò che ostacola veramente il progresso dello sviluppo sono le mie capacità di lettura del codice. Come posso migliorare le mie capacità di lettura del codice, in modo da poter individuare la maggior parte degli errori e dei problemi nel codice anche prima di premere il tasto "compila", anche prima di avviare il debugger?

Leggi altro codice

Per uno, ho acquisito le mie capacità di lettura del codice in qualche modo decenti dalla lettura delle domande di certificazione, che erano molto difficili da seguire, perché erano scritte male di proposito

Dovrebbero testare la tua conoscenza della lingua (Java nel mio caso) dopo tutto.

Più codice leggi, più esperienza accumulerai, è così semplice

Migliora il tuo ambiente di sviluppo il più possibile in modo che possa darti un feedback che puoi usare.

Gli IDE moderni possono aiutare MOLTO se puoi fornire loro le informazioni necessarie. Esempi sono:

• Colorazione della sintassi: costanti in un colore, commenti in un altro, identificatori in un terzo, stringhe in un quarto, ecc. Ho trovato di recente un pezzo di codice che era ... strano ... Si è scoperto che una variabile era chiamata come costante sarebbe - il colore sbagliato lo ha dato via.
• Cattura semplici errori di compilazione. La maggior parte delle lingue ha una sintassi semplice che può essere insegnata a un editor, quindi può dirti in anticipo che avrai errori.
• Cattura errori di compilazione complessi. Molti compilatori possono generare file informativi che possono essere caricati nell'IDE in modo da sapere quanti argomenti accetta una determinata funzione, ecc.

Esistono anche programmi che possono identificare errori logici nei tuoi programmi, che puoi usare per ottenere ancora più informazioni sul tuo programma da cui puoi imparare.

Inoltre, il tuo IDE può aiutarti a navigare nella tua fonte quando conosce tutte queste cose. Ciò ti consente di cercare facilmente le cose invece di dover memorizzare tutto

Ti suggerisco di modificare la tua domanda per fornire ulteriori informazioni sull'ambiente con cui lavori e sui programmi che scrivi, per suggerimenti migliori.

Oltre a quello che hanno detto tutti gli altri, hai bisogno di pazienza se stai per leggere il codice (specialmente se non è tuo). Sì, la lettura a memoria per riga di codice richiede pratica, ma ne vale la pena e impari anche gli stili / trucchi di codifica degli altri. Ecco cosa cerco per ordine:

1. nomi variabili, parentesi graffe corrispondenti, importazioni ecc.
2. verificare che le condizioni siano correttamente posizionate e che vengano rilevati errori
3. tutto il resto - utilizzo di funzioni, ecc.

Sono abituato a scrivere codice in un editor di testo semplice, quindi Ctrl + F è mio amico, ma un IDE è molto utile soprattutto quando stai leggendo da più file.

Ora, se sei tu a scrivere il codice, non aver paura di inserire spazi bianchi, rientri e commenti. Onestamente, se non sembra piacevole agli occhi, diventa un dolore alla testa.

Anche se potessi individuare tutti gli errori prima di premere do compile, verificherei comunque testando e compilando. Mi fiderei solo di un test positivo e di un programma in esecuzione.

Penso che le buone capacità di lettura del codice possano portarti molto lontano nell'ipotizzare il codice. "Probabilmente questo andrebbe storto!", E provalo. E nella ricerca di bug "questa potrebbe essere la causa lasciamolo testare"

Il modo migliore per arrivarci è scrivere tu stesso il codice. Il secondo modo migliore è che il codice è semplicemente buono e si spiega da solo (se è davvero difficile il codice non è poi così buono)

Se non è il tuo codice e non è scritto bene, l'unico modo per migliorare è fare, fare, fare. Leggi il codice, prova cose diverse, scrivi dei test contro di esso, conosci la base di codice, refactor. Gli strumenti potrebbero aiutare, strumenti che possono trovare dove vengono utilizzati i metodi, dove vengono implementate le interfacce, dove vengono dichiarate le variabili ecc. E strumenti che offrono una panoramica degli spazi dei nomi, delle loro relazioni e metriche su di essi.

Ho avuto un problema simile in passato - Il mio trucco era quello di scrivere un piccolo test, lasciare la scrivania per un po 'di tempo, tornare indietro e simulare il test su carta. In questo modo, riesci a ripassare il tuo codice con un aspetto nuovo e hai un valore specifico da controllare (a differenza di andare oltre il tuo codice e dire "ahh .. ahh ... ha senso")

Forse sarebbe bene concentrarsi sull'apprendimento di un'abilità di lettura del codice alla volta, proprio come nelle revisioni formali del codice ogni revisore ha una diversa responsabilità. Prendi un corpo di codice e trascorri una settimana (diciamo) alla ricerca di nomi di variabili errati. Premi di nuovo lo stesso codice la prossima settimana cercando potenziali puntatori null; la settimana successiva cerca blocchi di codice duplicati; quindi problemi di multithreading, ecc.

Dopo aver dedicato del tempo dedicato alla messa a punto di diversi rivelatori, potresti scoprire che ora puoi leggere il codice con una coppia - o forse tutti - attivi, in modo da avere un senso del codice più ricco ora in una sola lettura.

Se stai parlando di errori di compilazione, non accadrà. La migliore soluzione per gli errori del compilatore è assegnare la persona che ha interrotto la build a fare da baby-sitter alle build fino a quando qualcun altro non la interrompe. L'hai rotto, l'hai risolto.

Gli errori logici sono molto più difficili da rilevare e permettono di prevenire. Una tecnica per prevenire i casi semplici è quella di scrivere test di unità / regressione.

Un consiglio che ho sentito stamattina (su SE Radio) è stato prendere un file e ridurlo al tipo 3pt, quindi cercare gli schemi nel testo. Non sarai in grado di leggere il testo ma verranno mostrati tutti i tipi di motivi. È piuttosto un bel trucco.

E questo è uno di quei posti in cui la riga di comando è il tuo amico, grep e pipeline possono fare molte cose utili.

Sono stato un istruttore di programmazione per diversi anni. Durante questo periodo ho trascorso molto tempo a leggere il codice e a commentarlo. Ciò comporta l'individuazione di errori di compilazione (non abbiamo sempre compilato il codice degli studenti), errori di logica e di progettazione e problemi di standardizzazione.

Per farlo bene, abbiamo dovuto sviluppare un occhio attento per questo tipo di errori ed essere in grado di "eseguire a secco" il codice. Questo tipo di attività mi ha anche esposto a molti stili di codifica. Oggi le mie capacità di lettura del codice sono abbastanza buone grazie a quel periodo.

Quindi il mio suggerimento per te è questo:

• Esamina il codice con i tuoi colleghi.
• Ti consiglio di leggere il loro codice da solo prima di ripassarlo con loro in modo che tu debba capire cosa fa il codice per te stesso.
• Commenta la struttura del codice e la pulizia, gli standard e la logica.
• Ciò migliorerà la qualità del codice e le tue capacità di lettura del codice.
• Il codice rivede il tuo codice un po 'di tempo dopo aver finito di codificarlo, in questo modo sarai in grado di valutarlo "con occhi nuovi" e imparare dai tuoi errori.

In bocca al lupo!