Comprensione del codice, reverse engineering, migliori concetti e strumenti. Java

Question

Uno dei compiti più impegnativi per qualsiasi programmatore, l'architetto è capire il codice di altri.

Ad esempio, sono un appaltatore, assunto per salvare molto rapidamente un progetto. Correggere bug, pianificare il refactoring globale e quindi ho bisogno del modo più efficiente per capire il codice. Qual è l'elenco dei concetti, la loro priorità e i migliori strumenti per questo?

Di ciò che so: il reverse code engineering per creare modelli di oggetti (la creazione di diagrammi per pacchetto non è così conveniente), creare diagrammi di sequenza (lo strumento si collega in modalità di debug al sistema e genera diagrammi dal runtime). Alcune tecniche di visualizzazione, utilizzando alcuni strumenti per lavorare non solo con .java ma anche con ad es. JPA implementatori come Hibernate. Generare diagrammi per non tutti i codebase, ma aggiungere qualche classe e quindi classi usate da esso.

Sparx Enterprise Architect è all'avanguardia nel reverse engineering o lontano da quello? Qualche altro strumento migliore? Idealmente sarebbe quello strumento mi fa capire il codice come se l'avessi scritto io stesso :)

Answer 1

Di gran lunga gli strumenti più importanti sono le tue orecchie, la tua lingua e la tua laringe. Chiedi alle persone che hanno familiarità con il codice: saranno in grado di aiutarti a capire la sua architettura generale molto meglio di qualsiasi strumento software.

I modelli UML completi con retroingegnerizzazione automatica sono in genere quasi inutili perché non sono in grado di distinguere tra astrazioni importanti e dettagli di implementazione - che è il punto centrale di tali modelli.

Gli strumenti software sono più utili per rispondere a domande molto specifiche quando si esaminano i dettagli, ad esempio "da dove viene chiamato questo metodo?" o "quali classi implementano questa interfaccia" - qualsiasi IDE valido sarà in grado di farlo. Anche i debugger possono aiutarti: posizionare i breakpoint ai punti chiave del codice e guardare lo stack delle chiamate quando vengono colpiti è spesso molto illuminante.

Answer 2

Il libro Object-Oriented Reengineering Patterns tratta questo in dettaglio. Sfortunatamente non c'è un proiettile argentato allegato :-)

Tuttavia, elenca un sacco di tecniche utili per rilevare il codice legacy. In breve

• intervista almeno alcuni degli sviluppatori originali (se sono ancora in giro) su
  • storia di sviluppo: le fasi, rilascia
  • stato attuale delle cose
  • squadra struttura sociale, politica , dinamica: quando e perché le persone si uniscono e lasciano
  • bug: tipico, più semplice, più difficile
  • codice qualità: parti più pulite/più brutte
  • dati di configurazione: forma, contenuto e utilizzo
  • unità/integrazione/manuale/...casi di test e dati
  • SCM struttura e l'uso di ramo
  • documentazione: ciò che è documentato in cui, è fino a data
  • persone di contatto per le interfacce esterne
• sviluppatori Guardare/gli utenti durante la demo per trovare
  • caratteristiche principali
  • casi d'uso tipici
  • aneddoti di utilizzo
  • buono/cattivo, mancante/funzionalità superflue
• "leggere tutto il codice in una sola ora"
  • ottenere visione alta livello di gerarchie di classi, interfacce
  • prendere più sessioni, se necessario
  • identificare strutture di grandi dimensioni (spesso contengono funzionalità importanti)
  • cercare modelli di progettazione
  • controllare com menti (possono rivelare molto, ma possono essere anche fuorviante)
• documentazione scremato (se c'è)
  • solo registrare la disponibilità di specifici tipi di documenti per esempio specificazione, diagramma UML, Wiki, Javadoc ecc
  • è utile e perché (non)
  • è aggiornata

Answer 3

Proprio per approfondire Michaels menzionare di buona IDE che può aiutare si:

io uso i seguenti servizi Eclipse molto:

• shift-F2 quando il cursore viene posizionato in un identificatore portare s up the Javadoc per quell'identificatore, se presente. Buono per la navigazione.
• Il passaggio del mouse su un identificatore fa apparire una casella con Javadoc al suo interno, se presente. Buono per ricordare quando si scrive ad es. una chiamata al metodo.
• La vista Dichiarazione mostra la sorgente in cui è definita la parola chiave su cui è posizionato il cursore. Questo è aggiornato quando il cursore si sposta.
• F3 passa alla definizione dell'identificatore corrente.
• Ctrl-T su un identificatore mostra tutte le sottoclassi e le implementazioni in un popup. Molto utile quando si lavora su interfacce.
• F4 su un identificatore visualizza la gerarchia di implementazione di tale identificatore in un pannello, che può essere navigato. Molto utile per imparare come sono connesse le cose. Questo include sia le classi che le interfacce.

Answer 4

EclipseUML Omondo è il miglior strumento di reverse engineering Java. Inverte tutto il codice java, tutti i pacchetti e persino l'interazione di classe con l'interfaccia se non nello stesso pacchetto. Semplicemente fantastico. Si può anche invertire: - .class - hibernate annotazioni - annotazioni APP

Quello che mi piace di questo strumento è che il mio codice è pulito perché tutte le informazioni sul modello viene salvato in un formato XMI e non come tag il mio codice È inoltre possibile creare una piccola documentazione all'interno di ciascun pacchetto esistente utilizzando i diagrammi come una vista del modello. Semplicemente meraviglioso e rispettando le specifiche ufficiali uml 2.2. L'unico problema è che è davvero troppo costoso quindi il prezzo è una fermata per me !!

Answer 5

Uso Enterprise Architect per UML intero (incluso il reverse engineering con Java) e funziona perfettamente.

Answer 6

Non estrae architetture di alto livello, ma rende molto più semplice arrampicarsi intorno al codice Java: il nostro Java Source Code Browser. Questo legge il codice sorgente (e supporta i file di classe) e produce la documentazione in stile Javadoc più il testo sorgente bidirezionalmente collegato ai dati Javadoc. (Sono uno dei principali dietro di esso).