Come abbattere un nuovo progetto con un sito mega PHP esistente?

Ho fatto la stessa domanda di recente. Mi piacerebbe rispondere con il mio contributo ora con un mese e mezzo in.

Ecco la domanda originale: "Qual è il tuo approccio per assumere il progetto di qualcun altro?

1. Leggi la documentazione, se ce n'è. Se sei fortunato, dovresti essere in grado di ottenere alcune informazioni sulle funzioni e le sfumature del progetto. Il codice nel mio caso (a proposito, questo è un sito di file 15000) è abbastanza ben documentato, ma c'è ancora qualche stranezza in proposito.
2. Imposta il tuo ambiente di debug. Qualunque sapore possa essere. Impostare i breakpoint e tracciare il codice e vedere cosa è previsto. Questo è stato fondamentale per me - la maggior parte degli errori che riesco a trovare attraverso il messaggio di errore, ma altri in cui mi sento perso. Ecco dove avviene il debug.
3. Prova qualcosa per imparare. Aggiungi una nuova versione di jQuery. Crea un modulo di prova. Fai qualcosa al di fuori dell'elenco delle attività in modo che tu possa familiarizzare con i metodi e l'architettura.
4. Assicurati di essere coperto nel caso in cui qualcosa vada storto tramite codice. Supponiamo che un errore possa causare un impatto sui processi mission-critical. Nel tuo codice di infanzia, potresti non sapere come risolverlo immediatamente. Per lo meno, utilizza il software di controllo delle versioni in modo da poter riportare tutto al suo stato di esecuzione il più rapidamente possibile.
5. Se puoi, prendi il tuo parco giochi personale dove puoi fare quello che vuoi. Distruggi quella classe - ottimizza quelli inclusi. Solo da qualche parte puoi esplorare in modo indipendente. È molto importante avere le mani sul codice e lavorarci sopra.

Spero che questo aiuti. Sono ancora in procinto di rilevare il mio progetto e, a volte, può essere difficile. Ma le sfide rendono la giornata più veloce.

Per quanto riguarda la struttura del codice originale, è possibile iniziare eseguendo PhpDocumentor tramite il codice base. Anche se non hanno usato la sintassi di docblock, questo dovrebbe almeno mappare funzioni e classi e presentarlo in un formato ragionevole.

Una recensione in black box delle funzionalità del sito web dovrebbe darti qualche indizio su come è stata costruita. Chiaramente, una tale recensione non ti darà alcuna informazione esplicita su come è strutturato il codice sorgente, ma dovresti essere in grado di mappare una pagina per pagina cosa fa tutto (cioè operazioni CRUD).

La recensione della scatola nera è anche utile perché ti permetterà di capire cosa funziona attualmente e cosa no (sia dal punto di vista tecnologico che di usabilità), che puoi trasformare in feedback costruttivo se / quando richiesto.

Questo dovrebbe essere sufficiente per iniziare e farti superare la riunione.

Nel tuo incontro hai dovuto ascoltare attentamente ciò che dice il tuo cliente. Importante sapere è qualcosa che sottolinea.

Dopodiché, quando ti trovi di fronte al codice, ottieni l'elenco dei file coinvolti e prova a capire che cos'è il codice creato appositamente per l'app e che cos'è il codice esterno (per esempio le librerie).

Tutto ciò che apprendi non dovrebbe essere solo scritto sulla carta, ma anche graficamente con un diagramma. All'inizio sarà utile solo un diagramma di flusso. Lasciare diagrammi UML più strutturati per una seconda e più approfondita recensione.

Sarà scoraggiante a prima vista, e potrebbe anche essere molto difficile se il codice è scritto male, ma ricorda sempre che ciò che stai facendo è possibile e sarà finalmente raggiunto.

L'anno scorso ho assunto il ruolo di sviluppatore di un'applicazione web PHP / MySQL con circa 350 file PHP e 50 tabelle SQL. L'autore originale non ha avuto precedenti esperienze di programmazione. Nonostante ciò, l'organizzazione del database era abbastanza normalizzata, ma in fondo ogni decisione presa dopo era sub-ottimale. Date memorizzate come stringhe "DD/MM/YY" , ad esempio (le parti dell'app dipendono molto dal tempo) e un'API basata su RPC in cui tutti gli input non erano salvati e le modifiche al database (CRUD) erano consentite tramite chiamate GET, accessibili tramite <a> link! Sono stupito che un robot non abbia indicizzato tutte le delete*.php?id= pagine:)

Dopo nove mesi di pulizia del codice, aggiunta di nuove funzionalità, riparazione di quelli vecchi, ottimizzazione SQL, sanificazione dei database, riscrittura degli URL e migrazione dell'API a REST (non ancora completata), il codice è ora in una posizione dove sarei orgoglioso di far vedere agli altri.

Intendo questa risposta come una sorta di riassunto dei casi studio. Fondamentalmente 1 sviluppatore, 350 file PHP, 50 tabelle, ha impiegato 9 mesi. Spero che questo possa aiutarti, o chiunque segua, a valutare quanto tempo potrebbe richiedere un progetto.