Metodi consigliati per ottenere una buona conoscenza del software ereditato

Enterprise Architect di Sparx Systems può inoltrare e decodificare PHP, anche se non l'ho usato io stesso.

Per quanto riguarda la creazione di diagrammi, la mia risposta è sì - e no.

Non vorrei (non) usare UML per decodificare basi di codice. Gli strumenti di reverse engineering tendono a fornire solo i bit facili (strutture statiche) e, anche quando cercano di fornire aspetti dinamici, questi sono in genere incompleti.

Ma più che altro, penso che una rappresentazione UML della fonte sia inutile. Il codice sorgente è molto più facile da leggere; qualsiasi editor decente fornirà evidenziazione della sintassi e blocco dei blocchi e non dimenticherà il significato dei file di lingua non di origine (ad es. Makefile, definizioni dei progetti IDE, ecc.) che i reverse engineering UML molto probabilmente non comprenderanno.

Uso UML per documentare la progettazione, in particolare gli aspetti di runtime e distribuzione: quali programmi sono costruiti e come interagiscono? Quali porte apre il server? Quale modello di threading è utilizzato? Come è configurato ciascun programma? E così via. Ma mi riferisco molto raramente a qualsiasi entità sorgente in qualsiasi modello.

Presumendo che questo codebase sia sufficientemente grande, probabilmente non lo diagramò.

Se il codice è troppo aggrovigliato per poterlo afferrare, non sono sicuro che un labirinto di scatole e frecce improvvisamente porterà luce ad esso. Ho trovato che uno strumento UML manca del contesto per darti l'immagine grande che devi iniziare. Potresti passare ore o giorni a cercare di capire una parte del diagramma che è davvero irrilevante per l'intero design, solo perché sembra un buon punto di partenza.

Il primo strumento che afferro in questa situazione è test esplorativi . Tratta il sistema come una scatola nera che non capisci. Se stai per apportare modifiche sostanziali, devi sapere quali output sono generati da un determinato set di input. Dopo averlo bloccato, puoi anche utilizzare questi test per verificare che il tuo progetto progredisca. I test esplorativi ti offrono un modo chiaro per dividere e conquistare la tua strada attraverso il codebase. Una volta che hai eseguito alcuni test, puoi certamente creare UML (o riorganizzare UML generato) per fornire una base per la comprensione del team.

Dopo aver avuto un'idea dei fini del sistema, passerei alla revisione del codice. La mia preferenza qui sarebbe il codice, ma se il tuo team è facilmente distratto da problemi di sintassi e stile, potresti trovare UML generato più produttivo. Indipendentemente dal fatto che lavori con codice o generato UML, trovo che lavorare con un partner con un proiettore e un sacco di lavagne ti sposteranno a una comprensione più veloce di fissare lo schermo da solo.

Non puoi davvero decodificare il codice PHP in UML. L'ingegneria inversa viene generalmente eseguita da C, C ++, C # o Java a UML.

In passato avevo ereditato un enorme progetto di codice java includendo solo la nota java e una piccola documentazione stampata. Non siamo mai stati in grado di scoprire tutto perché nessun team precedente lavorava ancora in azienda. Questo è esattamente ciò che non dovrebbe essere fatto !!

Ora lavoro come consulente e aiuto le aziende a mettere in atto processi agili. Quello che uso è il diagramma delle classi UML solo perché è facile da capire da parte di tutto il team e anche perché incrementale. Voglio dire che un cambio di codice viene immediatamente aggiornato nel modello UML. Posso tracciare il cambio di modello usando la cronologia locale. Se tutti gli sviluppatori lasciano l'azienda, sarà sempre possibile ridefinire rapidamente il progetto perché il diagramma delle classi UML è molto dettagliato. Abbiamo uno o più diagrammi per pacchetti. Ogni metodo importante è spiegato non solo nel codice ma anche con diagrammi di classe e sequenza. ecc. Capisco perfettamente che il modello guidato non è ricercato dagli sviluppatori perché ritengono di poter essere sostituiti da altri team offshore. Detto questo, i manager dovrebbero sempre avere il controllo del progetto e non dipendere dalla manipolazione del codice.

Questo è il mio penny per oggi, ma continuo a considerare che gli sviluppatori dovrebbero essere protetti e non utilizzati come carne dalle aziende. Il problema è il livello di investimenti nell'istruzione e nella formazione della squadra. Uno sviluppatore dovrebbe pensare e non solo il codice. Lui / lei dovrebbe anche essere in grado di fare un'architettura avanzata? Infine, se lascia l'azienda dovrebbe essere possibile ripristinare e rifattorizzare immediatamente i progetti esistenti.

È possibile decodificare il codice PHP in UML (ad es. Class Diagrams). Ma di solito non è possibile ottenere tutte le informazioni possibili, ad es. Codice Java Nelle classi PHP le variabili membro normalmente non hanno alcun tipo nella definizione (anche se è possibile con le versioni PHP recenti). Quindi un'analisi statica non può dire a quali altre classi si fa riferimento (anche per uno sviluppatore è abbastanza dispendioso dirlo). Quindi i diagrammi che stai ricevendo "dallo scaffale" mostrano pochissime dipendenze.

La nostra azienda sta eseguendo il reverse engineering con UML Lab che consente di aggiungere modelli e regole specifici per l'analisi di un software. Puoi provare tu stesso (con la versione di prova di 30 giorni). E il team di supporto è molto reattivo;)

Generalmente un buon IDE (con o senza UML) aiuta molto nella comprensione del software PHP. Vorrei raccomandare almeno di usare Eclipse PDT (Open Source) o Zend IDE (commerciale) per avere un'idea di gli interni del software. È quindi possibile disegnare diagrammi del software da soli e / o migliorare i diagrammi generati passo dopo passo.

Sei molto ottimista. Se il codice base non ha già una documentazione adeguata e non è così facile da leggere, dubito che abbia una gerarchia organizzata e strutturata. Quindi UML potrebbe semplicemente rendere tutto come un grande casino (che potrebbe essere).

Se vuoi fare i conti con quel codice base (o qualsiasi altro nuovo codice base), ti consiglio di leggere il libro link

Software Engineering Radio ha trattato questo argomento in Episodio 148: Software Archeology con Dave Thomas (di Programmatore pragmatico fama). Il podcast ha avuto alcuni modi penetranti per ottenere un controllo su basi di codice estranee che includevano l'analisi del codice in caratteri minuscoli in un editor a schermo intero, il passaggio del codice in un debugger con asserzioni e l'attenzione ai commenti (che potrebbero non essere più preciso). Non riesco a ricordare se ha toccato gli strumenti per analizzare la fonte, ma le sue idee mi hanno colpito come (beh) pratico.

Lo schema può aiutarti perché devi impegnarti attivamente nel codice. In realtà tutto ciò che richiede di leggere il codice e sintetizzare qualcosa da esso aiuta. Può essere un diagramma UML o può essere solo uno schizzo con alcune bolle e frecce.

Un altro modo per comprendere il software ereditato è quello di attingerlo. Puoi aggiungere messaggi di registrazione o divertirti con un debugger.

C'è una tecnica che mi piace di più, perché combina entrambi gli approcci in cui è possibile sintetizzare qualcosa di nuovo e attingere a esso: Cercare di adattare il codice a qualche harness di test. Se la base del codice viene fornita insieme a alcuni test unitari, quindi sei fortunato. Puoi leggere i test per capire il codice produttivo e aggiungere altri test per interagire attivamente con la base del codice senza danno. Se non ci sono test, allora devi iniziare da qualche parte. Devi attirare il codice e sintetizzare qualcosa che è molto più prezioso dei diagrammi: test che sono in sincronia con il codice reale e ti forniscono una rete di sicurezza per i cambiamenti futuri.

La conoscenza dei test unitari, delle tecniche di refactoring e della progettazione del software è molto utile per l'esecuzione di test attorno al codice esistente. Esiste un sacco di libri per ogni argomento isolato, ma ce ne sono pochissimi che trattano tutti e tre gli argomenti nel contesto di un codice esistente. Ho trovato molto utile seguire due libri:

• Funzionante in modo efficace con il codice legacy di Feather
• Sviluppo applicazioni brownfield in .Net di Belcham & Baley