Come assumere correttamente un progetto PHP complesso [duplicato]

1. Se non è rotto, non aggiustarlo. Suppongo che il codice funzioni da un po 'di tempo e il tuo processo aziendale ha assicurato che i precedenti sviluppatori hanno ho incontrato l'SLA per cui stai girando. Il che significa che, in mancanza di bug o nuove richieste di funzionalità, non è necessario toccare mai più nulla. Certo che fai ma è importante capire prima questo punto. Il tuo obiettivo è non di riscrivere o persino di comprendere un progetto complesso. È necessario essere in grado di accertare un numero sufficiente di informazioni sulle richieste che devi fare per correggere i pezzi rilevanti e toccare solo il codice pertinente.

2. Le strategie per apportare modifiche isolate sono molto diverse rispetto alle strategie per la comprensione o la riprogettazione di intere basi di codice. Se ti viene chiesto di apportare piccole modifiche, spesso la cosa migliore da fare è inserisci la tua applicazione, probabilmente tramite una richiesta HTTP nel tuo caso, mentre il tuo server è in esecuzione con un debugger. Ora puoi semplicemente osservare la logica che il codice sta seguendo e avere un'idea dell'architettura pertinente. Il debugger è la tua guida turistica attraverso la nebbia della guerra.

3. Considera di fare una piccola modifica con un certo numero di codice. Spesso sarai in grado di dire: "So che questo cambio di codice funzionerà, anche se probabilmente è un cattivo design". Questa può essere una scelta ragionevole. Ma ovviamente è necessario stabilire che in effetti sai che il cambio di codice funzionerà, quindi dovrai studiare alcuni pezzi rilevanti. Tieni a mente i rischi per la sicurezza: se schiaffi qualcosa insieme e funziona bene su alcuni casi di test, comprendi il sistema abbastanza bene da essere cauto nei casi angosciosi?

4. I tuoi primi passi dovrebbero includere il controllo del codice sotto il controllo del codice sorgente e l'apprendimento delle parti mobili in produzione. Il controllo del codice sorgente è molto importante, ovviamente, e vuoi tenere traccia delle modifiche che apporti molto bene. Se non hai avuto l'abitudine di fare commit di git coeso, questo sarebbe un buon momento per iniziare, perché probabilmente vorrai fare cose come cherry-pick e sottili rollback più di quando lavori su un codice che conosci bene. Branch in modo intelligente: ora in produzione, ho apportato modifiche che ritengo siano sicure, modifiche che ho apportato e che mi stanno solo curiosando per vedere quali cose ma potrei voler riferire in seguito comunque .

   Ma oltre a questo, pensa a domande come: conosci i tuoi ambienti? Se si esegue la sorgente dal proprio laptop, si interromperà la produzione? O c'è un ambiente di sviluppo sicuro? Inoltre, pensa ai componenti esterni al software e dai loro account: sistema di compilazione, test delle unità, registrazione, monitoraggio e notifica degli errori, ecc. Fa male apportare una modifica errata e scoprire che hai anche rotto il monitoraggio su di esso.

5. Siate pronti a dare il caso a una costosa riprogettazione o rearchitecture . Poiché le attività di manutenzione che devi svolgere su questo progetto diventano più ampie o più frequenti, e se sei veramente convinto che il codice su cui stai lavorando sia di scarsa qualità, dovrai semplicemente dimostrare che la sostituzione è più economico nel lungo eseguire piuttosto che mantenerlo. Trova pezzi che possono essere convenientemente riscritti piuttosto che riscrivere il tutto. Ciò può significare isolare un livello dati o un sistema di registrazione, tutto un componente alla volta.

   Il caso estremo è ovviamente quello di buttare via l'intero progetto e riscrivere, diciamo, Ruby da zero, ma se si tratta di questo, è probabilmente più perché non sei stato abbastanza esperto rispetto al fatto che il codice era che orribile. Dovresti essere in grado di identificare i pezzi che capisci perché sono orribili e come trasformarli in componenti manutenibili e riscrivere economicamente quelli con un senso generale della portata di ciò in cui stai entrando. Peggio è il codice o meno esperto, più grande è il pezzo, ma buttare fuori tutto sarà l'ultima risorsa.

Inizierei cercando e correggendo gli errori che dovevo risolvere. Usa la caccia agli insetti per familiarizzare con il funzionamento del codice. Lungo la strada faccio note mentali su eventuali problemi evidenti che potrei vedere. Dato che stai usando le funzioni mysql_, farei particolare attenzione alla risoluzione di eventuali problemi di iniezione.

Resistere all'impulso di lanciare immediatamente in modalità riscrittura. Per cominciare, potresti non avere lo specifico dominio di conoscenza necessario per un tale passo a questo punto. Meglio avere almeno qualche mese con la base di codice esistente prima di iniziare a valutare la possibilità di una riscrittura. Potrebbe essere, ad esempio, che alcuni dei "problemi" che vedi nel codice finiscono per avere più senso per te, man mano che ci si abitua.

Ignorerò la possibilità di una riscrittura e affronterò solo come attaccare questo particolare problema, supponendo che una riscrittura non sia nelle carte.

Prima cosa da fare: dedica del tempo a capire cosa sta facendo e come, e documentalo mentre procedi. Quindi, suddividilo in pezzi più piccoli. Invece di essere sopraffatto dalle dimensioni massicce del progetto, scopri quali sono le cose su cui puoi lavorare atomicamente. Alcuni suggerimenti:

• Estragga le chiamate al database in una classe (tua, PDO o un'altra libreria)
• Ristruttura le risorse in modo che siano più logiche
• Consolida le librerie front-end in modo che utilizzino solo una

Sono sicuro che ci sono una dozzina (o un centinaio) di aree diverse che hanno bisogno di lavoro. Non pensarci; pensa al primo ad attaccare.

Il mio approccio preferito è:

Configura tu stesso la documentazione di base

• diagramma di classe

• ERD dei dati

Successivamente esegui il debug attraverso alcune parti dell'applicazione per ottenere una panoramica dell'architettura. Da ciò puoi costruire una vista astratta. Di nuovo, documentalo.

Quando sarai a questo punto, dovresti essere più familiare con il progetto.

Ho avuto un problema simile un paio di anni fa.

Dopo molte ricerche, ho scoperto che ci sarebbe voluto molto meno tempo per costruire un sistema completamente nuovo piuttosto che provare a sistemare quello che era pronto. La cosa più importante: provare a sistemare quel codice disordinato lascerebbe sicuramente molti buchi nella sicurezza.

Dato che l'unico pensiero veramente pertinente era il db (che era anche un disastro), per prima cosa ho pianificato uno schema db e ho creato uno script per migrare il db per adattarlo allo schema e creare una nuova applicazione nel modo giusto.

Non so se puoi fare qualcosa del genere ma forse questa linea di pensiero potrebbe aiutarti.

Penso che mi piacerebbe affrontarlo in uno di questi modi:

• Parlate con gli sviluppatori precedenti anche se siete in cattive condizioni

• Parla con qualcuno che era in giro quando il sito web è stato sviluppato / in fase di sviluppo

• Esegui una riprogettazione completa

• Leggi tutto il codice e apporta le modifiche a ciascuna linea che deve essere modificata
  (questo richiederà molto tempo)

• Di 'al tuo capo che non sei nella posizione di farlo

• Chiedi al tuo capo di assumere più persone per portare a termine il lavoro con te

• Cerca di scoprire esattamente cosa fa ogni pagina prima di fare qualsiasi cosa

Questo è tutto ciò che posso pensare al momento, ma se avrò altre idee, modificherò la mia risposta.