Come fai a capire il codice degli altri? [duplicare]

1. Chiedere all'autore
2. Proseguendo con il debugger in diversi scenari
3. Salvataggio delle scoperte in forma scritta
4. Imparare cercando di aggiungere / modificare qualcosa e vedere dove porta
5. Fare un paio di programmazione con un collega esperto o l'autore

Uso un mix di:

• Scrittura dei test per questo
• Modifica per vedere come si rompe
• refactoring

Non necessariamente in questo ordine :-) È sorprendente quanto sia più facile capire cosa fa un pezzo di codice dopo un refactoring.

refactoring

il codice, rendendolo così più chiaro, e in standard che h-hock ha stabilito.

Di solito, prima analizzo una parte semplice, ad es. il modulo utilizzato per mantenere un piccolo tavolo. Questo mi insegna lo stile che l'altro programmatore sta usando. Se ho problemi a capire anche questo, è scritto molto male o la mia conoscenza della lingua, delle strutture ecc. È insufficiente. Una volta che ho afferrato la parte semplice, è ora di passare alle parti più complesse del programma.

Prova a correggere un bug

Il miglior modo per conoscere il codice! :)

1. Esegui il programma con un semplice test case
2. Esegui il codice con lo stesso test case
3. Utilizza casi di test più difficili

Vado attraverso gli usi. Ogni caso d'uso inizia da un certo punto e finisce in un altro. Inizia a guardare l'inizio e segui il flusso. Quando hai esaminato tre o quattro punti di utilizzo, conosci la struttura del codice.

Preferibilmente dovresti scrivere dei test quando segui il codice, poiché ti aiuterà a mantenere un ruolo più attivo nell'esaminare il codice piuttosto che leggerlo riga per riga.

Il debugger è un ottimo strumento per seguire il flusso, puoi fare alcuni test rapidi che non affermano nulla ma avvia il codice nel punto da cui vuoi eseguire il debug, per ottenere un rapido punto di partenza per il debugger.

Anche se a seconda di quanto sei comodo con i test, i test potrebbero essere più veloci per verificare i risultati previsti.

questo sta arrivando con l'esperienza. quando sei un principiante, o salti in un altro linguaggio di programmazione è un po 'difficile. quando hai diversi anni di lavoro con una lingua, è più facile da capire.

ma, come regola generale, sto accendendo il debugger e comincio a capire cosa sta succedendo in esso. inoltre è MOLTO IMPORTANTE commentare il tuo codice e lavorare su codice documentato.

Bella domanda, non penso di essermi mai seduta a documentare il processo.

Immagino di pensarci ora, l'ho appena letto:

Riga per riga

Ovviamente questo non funziona sempre, chiedere all'autore di solito è l'ultima risorsa.

Usa una lavagna bianca per scrivere e interagire con diagrammi tra classi o metodi. Questo può aiutarti a vedere il flusso del programma. Una volta ottenuta la vista di 100 piedi, inizia a scavare, tracciare e eseguire il debug per trovare le sfumature del sistema.

Genera / disegna / legge un grafico di chiamata.

Come faccio a capire il codice degli altri?

Bene, la maggior parte non me ne occupo affatto. Cerco solo di capirlo se non funziona, e sto cercando di capire se ho fatto qualcosa di sbagliato o "l'altro" ha fatto. E gli strumenti che uso per questo stanno leggendo il codice e usando il debugger.

Se anche questo non aiuta, scrivo l'autore.

Diverse persone hanno stili di apprendimento diversi, quindi devi scegliere il metodo che funziona meglio per te.

La prima cosa che faccio (dopo aver costruito il progetto) è leggere l'intera base di codice almeno una volta. Questo mi dà un'idea generale di dove sia tutto. Quindi scelgo una sezione per esaminare più in dettaglio. Le strutture dati sarebbero un buon punto di partenza. Una volta che ho un'idea generale di cosa sta succedendo, faccio lo stesso con un'altra parte del codice che interagisce con la prima. Dopo un numero sufficiente di iterazioni, ho una buona idea di come funziona il codice.

Immagino come scriverei il codice e cercare le somiglianze.

Domanda interessante, non penso di aver mai documentato il processo prima, ma qui ci sono alcune cose che mi piace fare.

valutare

• forse sto solo estendendo un aspetto del codice dell'autore. Se posso limitare correttamente il mio compito a una classe oa un gruppo di dipendenze, questo significa che posso usare find / replace all'interno di un file o cercare nel mio sistema operativo per controllare quali cartelle e file contengono una stringa di destinazione (cioè classe, nome var ecc. ) e limita la lettura del mio codice alle parti più essenziali e aiuta a isolare le loro dipendenze.

fare grep -l [text to find] [files to look in] è dolce per questo genere di cose in Mac o Linux. Non ho idea di come sarebbe stato realizzato in Windows.

• Potrebbero esserci documenti API o dev, anche se si tratta di un piccolo progetto. Se ci sono punteggio . Altrimenti, è il momento di cercare davvero commenti utili nel codice.

ricerca

Prendendo ad esempio che si tratta di un progetto interno che ho ereditato, forse da un collega defunto che non ho mai incontrato:

• Dopo aver letto il codice e la documentazione. Mi rendo conto che è super fastidioso farlo, ma ora è forse il momento giusto per guardare i biglietti, il monitoraggio dei problemi, i bug reports o qualsiasi strumento / sistema di gestione dei progetti che stavi utilizzando in quel momento il codice dell'autore è stato creato. Forse il problema che ti è stato chiesto di risolvere è un problema di vecchia data con un thread cronologico documentato.

manodopera

I passaggi precedenti sono stati tutti progettati per prepararti all'intensa quantità di lavoro manuale che è intrinsecamente coinvolto nel reverse engineering del codice di qualcun altro. Fino ad ora, la maggior parte del lavoro si è concentrata sulla lettura.

• Come altri hanno suggerito, spostando le cose in giro e rompendole in modo controllato (cioè ctrl + z è tuo amico nei test del compilatore falliti), eseguendo il debugger. Estendere classi, plug-in, ecc. Tutte le grandi strategie che è possibile utilizzare per limitare la quantità di riscrittura e ri-factoring che è necessario eseguire.
• il refactoring su larga scala dovrebbe essere quasi sempre evitato. Detto questo, il refactoring di piccole sezioni di codice con commenti ben documentati potrebbe anche affermare che non sei lo sviluppatore originale può essere molto utile.

Il refactoring sostanziale dovrebbe essere condotto solo se lo stato del sistema di codice lo richiede effettivamente (cioè sta funzionando molto lentamente, è diventato un " grande palla di fango ", ecc.) Quello che vuoi evitare è semplicemente scambiare un bug per uno nuovo. Secondo la mia esperienza, il refactoring di un progetto solo per avvolgere la mente attorno a esso ha conseguenze impreviste, e queste conseguenze possono solo diventare evidenti in una data molto successiva. Anche con test unitari automatizzati, in un sistema di grandi dimensioni può essere difficile riesaminare ogni singolo aspetto di un ciclo di sviluppo.

Durante la lettura di una classe, guarda gli attributi e i comportamenti che ha (metodi + campi). Per i metodi, prendere nota del nome del metodo, dei parametri di input e del tipo restituito. Se non si conosce il nome del metodo (perché è offuscato), a volte è possibile ottenere queste informazioni osservando l'input, l'output e l'implementazione.

Prendi questo metodo parzialmente offuscato come esempio:

public double f(double d0, double d1, double d2)
  {
    double d3 = this.locX - d0;
    double d4 = this.locY - d1;
    double d5 = this.locZ - d2;

    return MathHelper.sqrt(d3 * d3 + d4 * d4 + d5 * d5);
  }

Accetta tre doppi, restituisce un doppio, ma la parte significativa è l'equazione matematica: radice quadrata di a-quadrato più b-quadrato più c-quadrato: Quella è distanza!

Ora, dovrai refactoring f() in distance() . Decifra i facili prima. Una volta che avrai risolto un numero sempre maggiore di rompicapo, darà suggerimenti in aree più difficili da decifrare.

Il mio trucco preferito è control + F. Questa è la funzione di ricerca. E puoi usare anche per cercare interi progetti (non solo singoli file). Come fai a sapere cosa cercare, chiedi? Bene, usando l'applicazione o la libreria in qualche modo ... ti darò suggerimenti su cosa cercare. In primo luogo, hai un'idea generale di quale caratteristica particolare desideri cercare. Quindi, se hai utilizzato il progetto anche solo un po ', puoi ottenere indizi più specifici per restringere la tua ricerca.

Ad esempio, sto lavorando a un progetto ora che ho ereditato da un autore inattivo (un plug-in Minecraft open source con 418 file e 46k righe di codice). E abbiamo chiesto a un utente di aprire un ticket: "Qual è il nodo di autorizzazione per utilizzare i segni di join?" Diamine, non ne ho idea. E nemmeno la documentazione lo menzionava. Nessun sudore, controllo + F per il salvataggio. (La mia arma preferita).

Una delle cose che non puoi sempre decifrare al 100% è la domanda del loro design : "Perché l'hanno progettata in questo modo?" Si può solo speculare.