Reverse Engineering Applicazione PHP senza leggere il (brutto) codice

So, is there any tool to log/record Http Request/Responses and what call graph of the php app it triggered? Preferably something that would not have to get written into the code?

La funzionalità di analisi della copertura del codice di xdebug ti aiuterà a capire cosa viene eseguito su ogni richiesta:

Code coverage tells you which lines of script (or set of scripts) have been executed during a request. With this information you can for example find out how good your unit tests are.

il profiler di xdebug genera informazioni di profilazione sotto forma di un file compatibile con Cachegrind, quindi in teoria non devi fare un molto in codice, dato che puoi configurare xdebug tramite php.ini e htaccess .

Questo è l'approccio pratico, non fermarti qui, dovresti seguire i consigli forniti da ChrisF e Morons .

Se vuoi riscrivere l'applicazione, non devi sapere come fa ciò che fa, ma devi sapere cosa fa.

Siediti con il manager e passa attraverso il sistema evidenziando le funzionalità che il sistema deve avere. Questo ti darà un elenco di funzioni (ad esempio supponendo che l'applicazione sia un sistema di blogging):

• Crea utente
• Aggiungi post di blog
• Pubblica post sul blog in futuro.
• Commento sul post del blog
• ecc.

Fai screenshot di ogni pagina in modo da avere un documento di come appare il sistema. Ciò fornirà anche gli oggetti e i campi che devono avere la tua datamodel.

Quindi vai via e specifica quanto tempo ci vorrà per implementare queste funzioni usando il tuo framework di scelta.

In nessuna fase hai bisogno di guardare il codice esistente. Stai mappando la funzionalità utente , non sistema .

Hai sbagliato l'anno. Era il 2001 ... Aspetta, non sei il mio vecchio collega. Questo deve succedere ovunque.

Quando dovevo scegliere tra riscrivere o rattoppare Frankenstein, era assolutamente chiaro che non ci sarebbe stata una riscrittura. Non tutto in una volta, comunque. Invece, abbiamo proceduto al refactoring delle pagine per pagina dall'alto verso il basso (questa non era esattamente un'architettura basata su modelli, quindi pensare al sito come una raccolta di pagine era ragionevole). Il "quadro" nel nostro caso è iniziato in modo semplice. %codice%. Ma quando sono sorti i casi speciali, questa funzione è diventata Draw_Info_Box(some_object) ... beh, hai capito. Abbiamo iniziato con il refactoring di questi per eliminare un parametro aggiuntivo alla volta. Per alcuni, abbiamo preso la decisione di duplicare il codice ed eliminare il caso speciale tra le due versioni (nomi come "DoSomethingOrSomethingElse" verrebbero suddivisi in "DoSomething" e "DoSomethingElse"). Per altri, li abbiamo avvolti in oggetti semplici e trasformato i parametri aggiuntivi in variabili di stato dell'oggetto. Ciò ha permesso un più facile refactoring in seguito.

La sua suddivisione in unità gestibili (nel nostro caso, pagine individuali) ha permesso di rendere più gestibili alcune parti del sistema mentre il sistema era ancora in uso. Ciò consentiva anche correzioni di bug più semplici durante il refactoring (che era il caso contro la riscrittura - c'erano ancora cose che dovevano essere fatte al sistema in uso).

In realtà mi sono lasciato prima che l'intero sistema fosse riscritto. A quel punto, alcune parti erano state riscritte più di una volta (eliminando un livello di caos organizzativo ne rivelava spesso un'altra, ma avevamo un approccio metodologico che ci consentiva di gestirlo).

Se oggi stessi iniziando una cosa simile, inizierei con i test Selenium sull'applicazione e proverei a ottenere una sorta di metrica di copertura del codice dai test. Poi farei lo stesso lavoro di refactoring, ma mi sentirei un po 'più fiducioso che gli errori e le differenze comportamentali sarebbero stati scoperti.

Fondamentalmente è necessario documentare i sistemi in termini di Use Cases \ User Screens. Assicurati di coprire ogni schermata del sistema in almeno uno dei casi d'uso.

Quindi è necessario passare attraverso tutte le schermate e utilizzare i casi durante l'esecuzione di un profilo DB. Documento Tutte le transazioni Db su ciascuna schermata. Prova ogni campo per la convalida dei dati.

Chiedi agli utenti informazioni sull'integrazione del sistema, in pratica qualsiasi cosa possa accadere dietro lo schermo che non si riflette nell'interfaccia utente o con un'interazione Db. (Invio e Email. FTPing qualcosa, qualunque cosa)

Chiedi Informazioni su tutte le corse su un programma. Guarda tutti gli SQL dietro i principali report nel Sistema. Crea un ERD.

Documento, documento, documento .. Quindi, infine, una volta ottenute tutte le informazioni possibili in questo modo. Inizia a guardare il codice per le aree in cui hai bisogno di chiarimenti.

Mi piacerebbe costruire su ciò che ChrisF e Morons hanno già detto.

Da risposta di ChrisF :

If you want to rewrite the application then you don't need to know how it does what it does but you do need to know what it does.

Sono d'accordo al 100%.

Da risposta di Morons :

Ask users about System integration, basically anything that may be happening behind the screen that is not reflected in the UI or with a Db interaction. (Sending and Email. FTPing something, whatever)

Ask About anything the runs on a schedule. Look at all the SQL behind the major reports in the System.

D'accordo. Ottimo punto sui lavori programmati.

Document, Document, Document.. Then Finally, once you got all the info you can this way. Start looking at the code for areas where you need clarification.

A destra.

Test every Field for data validation.

OK.

Then you need to go though all the screens and use cases while running an DB profile. Document All the Db transactions on each screen.

Non sono d'accordo.

• Estrapolare proficuamente il database non è un buon uso del tuo tempo.
• Potrebbe anche essere fuorviante.
• Enfasi: come ha detto ChrisF, concentrati su cosa fa l'applicazione, non su come lo fa.

Inoltre, sappi che: Farai degli errori! :)

Ovviamente, in qualità di lead tecnico, è tua responsabilità minimizzare questi errori nella misura in cui il nuovo sistema imita le funzionalità di base del vecchio sistema.

Detto questo ...

• Sembra che questo sia uno sforzo utile perché stai rendendo il sistema mantenibile e stai cancellando una grande quantità di debito tecnico.
• Semplicemente non penso che sia utile, produttivo, efficiente o addirittura fiscalmente responsabile di caricarsi di un atteggiamento eccessivamente perfezionista in questo lavoro.