Il modo più veloce e più istruttivo per imparare una nuova base di codice, che sia elegante o spaghetti, e quando non hai risorse come documentazione o persone esperte da chiedere, è di cambiare qualcosa. Questo potrebbe anche essere un cambiamento nella direzione delle esigenze del business. Ma tieni una piccola modifica all'inizio.
Il refactoring di qualcosa di piccolo è un buon modo per iniziare. Per esempio. una classe che sembra avere un comportamento "tacked on" (ad esempio una classe che gestisce la gestione di alcuni dati, ma scrive anche tali dati in un formato di file) e la tiene in un sottomodulo (che scrive i dati dati nel formato richiesto ).
Rimuovere il codice è divertente: cerca di eliminare una variabile globale o elimina una variabile membro che può essere locale. Cerca di eliminare un'intera classe che sembra fare molto poco per le linee di codice che occupa.
Se il codice non è commentato, non si tratta necessariamente di una perdita totale. Può essere che i nomi delle variabili siano stati scelti bene. Altrimenti, avrai del lavoro extra da fare. Rinomina le variabili seguendo la tua convenzione di denominazione che ha senso e non aver paura di usare nomi di variabili lunghi. Ci sono molte opinioni sulla denominazione delle variabili, ma penso sempre "capisci il senso, non scrivi". Rinominare le variabili con un nome errato ti costringerà a capire a cosa serve ogni variabile (che è qualcosa che l'autore originale era troppo pigro per fare).
Come compito di per sé , disegnare diagrammi di ciò che pensi sta succedendo è una perdita di tempo ed è solo una diversione da ciò che devi fare che è, e non c'è modo di allontanarsi da questo, leggere il codice. Può essere meglio incollare piccoli estratti di codice da classi e moduli diversi in un documento di testo e descrivere cosa sta succedendo in quel modo. Potrebbe essere necessario fare diagrammi in seguito per chiarire le cose ad alto livello o per aiutare a spiegare il codice a qualcun altro. Spiegare il codice a qualcun altro è un buon modo per aumentare la tua comprensione.
Questi suggerimenti sono già stati fatti: scrivere test di unità e contattare l'autore precedente sono sicuramente una parte dell'attacco di una base di codice ereditata.