Qual è la migliore strategia per capire il codice di qualcun altro per un progetto di medie dimensioni, se il codice non è ben documentato e non aderisce a molti standard di codifica?
Il mio approccio:
Suppongo che non ci siano test unitari. Il modo migliore che ho trovato è quello di prendere il tempo per seguire il flusso di lavoro; guarda come interagisce dal punto di vista dell'utente e prova a vedere come viene chiamato il codice, quindi puoi rinominare le cose per renderle più significative.
La prima cosa che farei è leggere il progetto e usarlo, dal punto di vista dell'utente. Leggere la specifica dei requisiti del software (SRS), le storie degli utenti o qualsiasi altra forma di documentazione esistente per i requisiti. Quindi, provare a completare alcune delle attività principali e capire come viene utilizzato il sistema. Sento che se non capisci cosa dovrebbe fare il sistema dal punto di vista dell'utente, è incredibilmente difficile progettare e implementare soluzioni ai problemi che questi utenti stanno affrontando.
Una tecnica sarebbe quella di leggere i documenti di progettazione e seguire il codice. Diagrammi dinamici (modelli UML di sequenza e comunicazione, ad esempio) sono particolarmente utili, se li avete. Questi ti permettono di vedere una rappresentazione grafica della relazione tra moduli di codice (pacchetti, classi e metodi). Ovviamente, i diagrammi statici (classe, pacchetto, oggetto, modelli UML di distribuzione) sono anche utili per capire come si integrano i pezzi di un sistema. Se questi diagrammi non esistono, passare un po 'di tempo a decodificare il sistema potrebbe essere un buon esercizio di apprendimento.
Data la tua situazione, sembra che la documentazione potrebbe non essere disponibile. L'opzione successiva sarebbe utilizzare un debugger. Accendi il debugger e percorri il sistema mentre è in esecuzione per vedere come si adatta. È possibile eseguire diversi casi di utilizzo comuni e utilizzare i metodi. Potrebbe essere una buona idea commentare anche i file. Forse prendi appunti su cose di cui hai bisogno o di cui hai bisogno per saperne di più.
Vorrei iniziare a scoprire cosa dovrebbe fare il codice. È un'applicazione web che elabora le transazioni bancarie? Un'applicazione desktop che HR utilizza per gestire curriculum e candidati?
Il prossimo passo sarebbe provare a eseguirlo. Esplora bene una funzionalità. Quindi inserire i punti di interruzione nel codice corrispondente e passarlo attraverso il debugger, se possibile. Questo ti permetterà di vedere il codice "vivente" - come funziona quando è effettivamente in esecuzione. Se la documentazione è stata mal gestita, il debugger potrebbe essere migliore di qualsiasi documentazione in quanto è possibile che i documenti non siano stati udpati con la modifica del codice.
È anche utile chiedere a qualcun altro nell'organizzazione che ha maggiore esperienza con il codice, supponendo che tale individuo sia disponibile.
Come altri hanno già menzionato, la generazione di diagrammi può essere d'aiuto se si dispone di strumenti validi. Ma tienili piccoli all'inizio. Un diagramma che contiene centinaia di classi e forse migliaia di relazioni tra di loro è piuttosto inutile (almeno all'inizio).
Leggi altre domande sui tag maintenance comments knowledge-transfer