Personalmente non penso che niente batte solo attraverso il codice e imparandolo. Non c'è un modo rapido per capire. Quando vado a un nuovo lavoro, trascorro una settimana, facendo quasi nulla ma comprendendo il design del database (sono uno specialista di database). Se i diagrammi non esistono, li creo. Traccio le cose dal livello più alto delle query fino ai tavoli. Faccio domande quando qualcosa non ha senso. Cerco prima le query più critiche da comprendere (solitamente le query di ricerca, ti daranno una buona idea delle tabelle più importanti). Se possibile, chiedi a qualcuno con qualche esperienza di sederti con me per una buona mezza giornata e mostrami quello che sa.
Dato che hai superato la tua prima settimana (quando è più facile ottenere questa volta) è più difficile. Ma inizia con un modulo su cui hai lavorato o ti stai preparando a lavorare e leggi il codice, seguendo i percorsi nel codice fino a quando non sei arrivato al livello più basso. Prendere appunti. Crea diagrammi se necessario. Basta lavorare su una sezione alla volta, ma esaminarla a fondo. Prova a trovare qualcuno che ha lavorato al design per capire le scelte progettuali. Spesso hanno scelto ciò che era meglio nel momento in cui hanno fatto il design, ma qualcosa che cinque anni dopo ti sembra piuttosto orribile. Aiuta a comprendere i vincoli che hanno portato il design a essere così com'è.
Le applicazioni aziendali tendono ad essere strongmente incentrate sui database. Assicurati di prendere il tempo necessario per comprendere la struttura del database e la struttura dell'applicazione.
Ci sono documenti dei requisiti dal design originale in uscita? Prenditi il tempo di leggere alcuni di essi.
Non è mai facile capire un grande sistema Enterprise. Ci sono un sacco di piccoli disegni differenti in diversi periodi di tempo coinvolti in esso, quindi c'è spesso poca coerenza. È probabile che nessuno nel team comprenda completamente l'intero sistema. Se hai qualcuno che è l'esperto riconosciuto del sistema, ascoltalo attentamente, fai molte domande, chiedi perché hanno fatto le scelte che hanno fatto. BUt fallo rispettosamente, niente bloccherà il sistema onteh degli esperti più velocemente che fare domande in un modo che li faccia sentire difensivi. Sebbene tu possa o meno essere d'accordo con tutte le scelte che hanno fatto (circa il 100% di possibilità che non sarai d'accordo con tutti loro nella mia esperienza) almeno comprendendone i perché ti aiuta a iniziare a vedere il modello di come questo gruppo di persone approccio progettuale che ti indurrà a come hanno fatto la prossima cosa che guardi pure.