Ereditato un incubo PHP, da dove cominciare?

voti
40

Ho ereditato un progetto PHP che è svolta a essere un incubo. Ecco i punti salienti:

  1. Tutti gli sviluppatori originali hanno lasciato
  2. Il codice non ha alcun controllo di versione
  3. Tutto lo sviluppo e la sperimentazione è stato fatto sul server di vivere rinominando e modificare i file PHP. Ci sono più copie di ogni file index.php, index2.php, index3.php ecc e non è chiaro quali sono i file realmente utilizzati
  4. Ci sono molteplici include in ogni file per file che includono altri file che includono altri file, etc.
  5. Ci sono stati più sviluppatori sul progetto che ognuno aveva c'è proprio modo di fare le cose. Ad esempio, v'è un miscuglio di framework JavaScript, alcune query di database utilizzano SQL, altri un'interfaccia XML e altri chiamano funzioni procedurali nel database.

A causa di tutti questi problemi, lo sviluppo è frustrante lentezza. Oltre sfogo le mie frustrazioni a Stack Overflow, tutte le raccomandazioni su come iniziare in questo pasticcio? Sono abbastanza nuovo per lo sviluppo di PHP me stesso, ma sembra come la creazione di una sorta di ambiente di sviluppo in modo che le modifiche possono essere testate senza rompere il server di vivere è il primo passo. Eventuali suggerimenti su come iniziare qui? Che cosa è un tipico modo di fare il test? Impostazione di una versione locale del sito sul mio desktop sembra un sacco di lavoro (server è Linux, ma qui ci sono i desktop di Windows). Posso creare una sottodirectory sul server di vivere per il test, o ..? Che dire del database?

In secondo luogo, v'è una sorta di profilazione posso consentire di rintracciare i file sul server vengono effettivamente utilizzati? Mi piacerebbe eliminare le copie rinominati di cose che non sono effettivamente inclusi. Ancora meglio, c'è un modo per dire che non vengono eseguite parti di un file? Ci sono un sacco di funzioni copiate e spazzatura in quanto ho il sospetto che non vengono utilizzati entrambi. Allo stesso modo, per la include, qualche consiglio su raddrizzare il disordine?

Beh, mi fermo qui sfiato e mi butto in balia di tutti i presenti. :)

È pubblicato 09/12/2008 alle 19:48
fonte dall'utente
In altre lingue...                            


27 risposte

voti
56
  1. Prima di tutto, ottenere i file nel controllo di versione come è. Non procedere oltre 1 # fino a quando non viene fatto.
  2. Stabilire un ambiente di test.
  3. Ripulire i file
Risposto il 09/12/2008 a 19:58
fonte dall'utente

voti
30

Ho fatto questo. Hai tutta la mia simpatia. Se il passaporto non è in corso o per qualche altro motivo non si può schivare fare questo, ecco come avrei avvicino:

Fase Zero è quello di ottenere in controllo di versione, non importa quanto sia scadente. Se anche tipo di funziona, e si rompe qualcosa, è necessario essere in grado di tornare alla condizione di funzionamento - o almeno confrontare le modifiche ad esso per capire cosa è andato storto. Fare frequenti, piccoli check-in come si sta refactoring, e avrete meno codice a rotolare indietro quando le cose vanno male misteriosamente. (Le cose si misteriosamente andare male.)

Dopo di che, mi piacerebbe iniziare al database. Assicurarsi che tutto è relativamente ben normalizzato, le colonne sono chiaramente chiamati, etc.

Fare il codice PHP successivo. Se il codice è in realtà che gran parte di un mosaico, mi piacerebbe andare avanti e in forma a un quadro. Guarda nel CakePHP o Symfony - il loro modo Rails-ish delle preoccupazioni che separano fa la domanda "dove dovrebbe questo pezzo di codice andare?" facile rispondere. Non è un compito da poco, ma una volta che hai fatto, sei probabilmente meglio di metà strada per avere un'applicazione in modo sano-costruito. Inoltre, il built-in strutture di prova di un buon framework web rendere il refactoring molto più facile - scrivere un test per coprire un pezzo esistente di funzionalità prima di modificarla, e saprete se hai rotto qualcosa dopo il cambiamento.

Una volta che hai il database ordinato e hanno il codice del modello nei modelli e il codice di controllo nei controllori, allora si può preoccupare di cose a livello di presentazione, come la standardizzazione su una singola libreria JS / AJAX, CSS pulizia, etc.

Come per un ambiente dev: Si dovrebbe assolutamente impostare un ambiente dev locale. Ci sono pacchetti chiavi in mano WAMP là fuori, o si potrebbe installare in una macchina Linux / VM (mi raccomando VirtualBox per la virtualizzazione). Si dovrebbe anche avere un ambiente di test di integrazione separato che imita il server di vivere. Niente ma il codice dal vivo dovrebbe funzionare sul server di vivere.

Per quanto riguarda gli strumenti di debug / profiling, so che Symfony viene fornito con un set piuttosto liscia di strumenti, tra cui una piccola barra degli strumenti di JS che si apre sulle tue pagine (solo in modalità debug) con registrazione e le informazioni di profilazione.

In bocca al lupo.

Risposto il 09/12/2008 a 20:25
fonte dall'utente

voti
17

Bene, andiamo con ordine. Sono stato nella situazione ci si trovi, e fa schifo. Penso che tu sia sulla strada giusta con la voglia di ottenere un ambiente di sviluppo attivo e funzionante.

Sviluppo dell'ambiente

Ciò includerà una pila motore / motore di database web server / script, e un IDE più probabile.

Per un LAMP installatore pila , mi consiglia di utilizzare uno di questi:

Ulteriore lettura sullo stack LAMP:

sito ONLamp di O'Reilly

Per un buon IDE PHP , mi consiglia di utilizzare uno di questi:

Articolo sul sito per sviluppatori di IBM confrontando diversi IDE

Per il controllo di origine , è possibile utilizzare Team Foundation Server, SVN o Git - basta usare qualcosa che si sa. Consiglio di prendere tutto in controllo del codice sorgente prima (per qualsiasi manutenzione di emergenza si potrebbe avere), ma poi intenzione di fare una bella grande revisione.

la revisione

Lei ha detto che non sapeva nemmeno quali file si stanno abituando, e che hanno usato un file convenzione di denominazione come una pseudo-versione-controllo. Si potrebbe desiderare di iniziare la revisione lì, una volta che si dispone di un ambiente di sviluppo attivo e funzionante. Ci sono alcune cose che possono aiutare a:

  • I vostri clienti / utenti app
  • Meticoloso e organizzata prendere appunti
  • Un buon quadro di registrazione

I vostri clienti / utenti sono importanti , perché suona come siete nuovi al progetto e che stanno andando a conoscere come l'applicazione dovrebbe comportarsi meglio di te (più probabile).

Meticolosa prendere appunti è importante , perché si sta andando ad essere essenzialmente ri-scrittura di qualsiasi documentazione di requisiti / disegno / utente finale da zero. È necessario comprendere i meccanismi interni, se avete intenzione di farlo. E se si sta andando a capire nulla di questo sistema, è necessario scrivere in giù da soli (o si sarebbe indagando documentazione premade in questo momento invece di leggere Stack Overflow) ;-)

E, infine, un quadro di registrazione è importante perché è necessario sistemare le cose, e non si può sistemare le cose che non si conoscono sono rotti. Un quadro di registrazione vi dà visibilità sulle parti del app che non hanno alcuna ovvia UI. Inserimento in varie parti del app e poi guardando i log ti dà una buona idea di quando il codice viene eseguito e in quale ordine.

Avrai voglia di concentrarsi sulla cattura (sulla carta) come l'applicazione dovrebbe funzionare, e poi lentamente rimuovendo i file non necessari durante il tentativo di non rompere nulla. Tenete d'occhio i registri per aiutare con il debug. Assicurati che i tuoi clienti non sono urla che qualcosa si è rotto. Assicurarsi che le note sono d'accordo con quello che sta ottenendo il login e ciò che i clienti stanno dicendo.

Prevenire questo in futuro

Ricontrollare tutto di nuovo in controllo del codice sorgente . Speriamo che siete arrivati ad una, più sano, una migliore struttura di directory più recente da questo punto.

Ottenere una struttura di prova sul posto . Anche se questo significa solo ottenere un framework di test unità di base a posto e facendo alcuni test di fumo di base dopo ogni implementazione, è meglio di niente. Idealmente, si dovrebbe avere un ingegnere di prova o di un cliente competente e affidabile in grado di passare il test tempo dopo ogni deploy.

Mettere un processo di distribuzione in atto se si cresce più di uno sviluppatore. Controllo del cambiamento nell'ambiente di produzione dovrebbe essere la vostra prima priorità. (L'ultima cosa che ci si vuole fare è passare attraverso questo nuovo, giusto?) Si dovrebbe avere un processo chiaro e semplice per muoversi tra i confini di ambiente (come Dev -> Prova allora Test -> Produzione).

Risposto il 09/12/2008 a 20:23
fonte dall'utente

voti
16

Il più delle volte si può dire se un file viene utilizzato da utilizzando grep.

grep -r "index2.php" *

È inoltre possibile utilizzare il parser PHP per aiutare la pulizia. Ecco uno script di esempio che stampa le funzioni che vengono dichiarate e chiamate di funzione:

#!/usr/bin/php
<?php
class Token {
    public $type;
    public $contents;

    public function __construct($rawToken) {
        if (is_array($rawToken)) {
            $this->type = $rawToken[0];
            $this->contents = $rawToken[1];
        } else {
            $this->type = -1;
            $this->contents = $rawToken;
        }
    }
}

$file = $argv[1];
$code = file_get_contents($file);

$rawTokens = token_get_all($code);
$tokens = array();
foreach ($rawTokens as $rawToken) {
    $tokens[] = new Token($rawToken);
}

function skipWhitespace(&$tokens, &$i) {
    global $lineNo;
    $i++;
    $token = $tokens[$i];
    while ($token->type == T_WHITESPACE) {
        $lineNo += substr($token->contents, "\n");
        $i++;
        $token = $tokens[$i];
    }
}

function nextToken(&$j) {
    global $tokens, $i;
    $j = $i;
    do {
        $j++;
        $token = $tokens[$j];
    } while ($token->type == T_WHITESPACE);
    return $token;
}

for ($i = 0, $n = count($tokens); $i < $n; $i++) {
    $token = $tokens[$i];
    if ($token->type == T_FUNCTION) {
        skipWhitespace($tokens, $i);
        $functionName = $tokens[$i]->contents;
        echo 'Function: ' . $functionName . "\n";
    } elseif ($token->type == T_STRING) {
        skipWhitespace($tokens, $i);
        $nextToken = $tokens[$i];
        if ($nextToken->contents == '(') {
            echo 'Call: ' . $token->contents . "\n";
        }
    }
}
Risposto il 09/12/2008 a 23:56
fonte dall'utente

voti
10

Se è il caso peggiore, il codice è tutto scrampled, e tutta la visualizzazione si mescola con la logica e le chiamate al database, si potrebbe fare quello che ho dovuto fare con un progetto PHP.

Ho dato tre inizia a cercare l'approccio refactoring. E 'stato come in salita su una moto e ottenere il 10% del modo in cui di volta in volta. Così ho preso un altro approccio che ha finito per lavorare fuori molto meglio.

  1. Mi sono collegato come utente,
  2. e lavorato attraverso ogni schermo ed ogni caso d'uso sono riuscito a trovare.
  3. Ho salvato il codice html ai file statici,
  4. e ha preso appunti sul funzionamento procedurale e regole di business evidenti.

Ho fatto questo per 3 giorni solidi, e poi ha preso i miei appunti e ha avuto un lungo colloquio con gli stakeholder.

Dopo avere trovato un accordo su alcuni primi passi, ho reimplementato tutta l'interfaccia utente HTML correttamente, utilizzando buon design coerente e l'astrazione. Dopo aver ottenuto rotolamento, ho potuto fare un paio di schermi al giorno.

Poi ho preso il risultato di nuovo agli stakeholder e corse attraverso un mazzo di casi d'uso. (I soggetti interessati sono stati immensamente contento di punti 1 e 2, perché a loro non piaceva la prima implementazione a tutti in ogni caso (sorpresa) e ora sembrava che ci fosse speranza di miglioramento, non solo per il recupero di sane-vecchio-app.

Che si è rivelato essere la fine del duro lavoro (e anche la fine del rischio di progetto percepito per gli stakeholder.)

Si è scoperto che il primo equipaggio aveva ottenuto così legato nelle loro gli spaghetti Misbegotten che c'era in realtà relativamente poco contenuto al lavoro, in modo da duplicare aveva meno possibilità di chiunque sospettato.

Ma la decisione chiave era che il codice originale, sia il contenuto e la struttura, erano unrefactorable e avevo bisogno di lavorare da una visione del tutto esterno con un nuovo quadro che è stato progettato correttamente.

Risposto il 10/12/2008 a 00:24
fonte dall'utente

voti
10
  1. Impostare un server di sviluppo (come detto Greg Hewgill, VirtualBox e Virtual PC sono buone scelte per questo).

  2. Mettere i file del sito correnti (incluse le configurazioni di server web e PHP importanti!) Nel controllo della versione.

  3. Scopri quali vengono utilizzati i file - utilizzare la configurazione server di sviluppo per testare rimuovendo tutti i file fooN.php e vedere se funziona ancora.

  4. Pregate ... lotti (OK, questo non è necessario, ma suona come ne avrete bisogno).

Risposto il 09/12/2008 a 19:57
fonte dall'utente

voti
7

Una cosa che si potrebbe prendere in considerazione è quello di installare il PHP "xdebug" estensione in un ambiente di sviluppo, impostarla per tracciare tutte le chiamate di funzione, e quindi il più possibile (possibilmente attraverso test UI automatico) esercitare l'intera applicazione. Sarete quindi in grado di analizzare / analizzare i file xdebug traccia per trovare tutti i file / funzioni utilizzate dall'applicazione.

Risposto il 09/12/2008 a 20:38
fonte dall'utente

voti
6

Altre persone su questa discussione hanno ottimi consigli. Sono stato in questa situazione anche. Probabilmente ognuno di noi in una sola volta nella loro carriera entrò in un progetto che sembra sia stata colpita da un tornado.

Un suggerimento che vorrei aggiungere è che prima di fare qualsiasi della pulizia descritto da altre persone, è necessario ottenere management buy-in.

  • Fare un piano sulla base di suggerimenti su questo thread.
  • Descrivere qualsiasi nuovo hardware o software è necessario creare un ambiente di sviluppo e test, e il prezzo questi fuori.
  • Capire quale nuovo le competenze necessarie per essere addestrati a impostare e utilizzare l'ambiente di sviluppo e testing. Stimare il tempo e le spese necessarie per voi per ottenere tali competenze. Ad esempio libri o formazione retribuita.
  • Stimare un programma di lavoro da fare per voi la pulizia. Quanto tempo per ottenere il codice sotto il controllo del codice sorgente? Quanto tempo per capire il database? Quanto tempo per capire il PHP e JavaScript codice?
  • Presentare questo al vostro responsabile, e la frase l'obiettivo in termini di beneficio per la sua linea di fondo. Ad esempio, una volta che tutto è ripulito, apportare modifiche o implementare nuove funzionalità sarà più veloce, gli errori di debug saranno più prevedibili, e dilagare nuovo personale sarà più facile.

Naturalmente è necessario continuare a lavorare con l'attuale caos, perché è un luogo vivo. Gestione del sito in diretta ha la priorità, quindi il lavoro di pulizia deve essere un task in background. Ciò significa che ci vorrà ancora più a lungo. Le mie esperienze pulizia di un progetto di moderata grandezza come attività in background di solito hanno preso sei a dodici mesi. Dal momento che il sito continuerà ad evolversi nel corso di questo periodo, alcune delle vostre operazioni di pulitura completate può avere bisogno di essere rivisto o ri-fatto. Assicurati che il tuo manager capisce tutto questo.

Se il gestore esita a vostro piano per ripulire questo pasticcio, o non apprezzi pulirlo, almeno allora saprete perché tutti gli altri sviluppatori hanno lasciato questa azienda!

Ho un paio di suggerimenti specifici su come procedere:

  • In aggiunta a tutti gli altri ottimi consigli, io suggerirei di utilizzare il test Joel come punto di riferimento. Il vostro piano per la pulizia dovrebbe tradursi in un ambiente di lavoro che avrebbe segnare bene sul test Joel.
  • Leggi la mia risposta a " Quali sono i modi migliori per capire un database sconosciuto? "
  • Abilitare la registrazione sul sito web in modo da poter analizzare quali pagine PHP sono effettivamente chiamato. Almeno che ti dice quale delle index2.php, index3.php, index4.php, ecc sono davvero obsoleti.
  • PHP ha una funzione get_included_files()che restituisce un array di tutti i file inclusi nella richiesta corrente. Accedendo queste informazioni, è possibile scoprire quali file PHP sono in uso, anche se non si presentano nel registro del server web.
  • Hai davvero bisogno di avere un ambiente di test e di sviluppo che corrisponde al proprio server di produzione. Non va bene per testare su Windows e distribuire su Linux. Non è bene usare MySQL 5.0 durante lo sviluppo e MySQL 4.0 in produzione. Probabilmente si può ottenere via con una piattaforma hardware che è più modesta (se compatibile).
Risposto il 09/12/2008 a 21:29
fonte dall'utente

voti
5

È possibile visualizzare un elenco di tutti i file inclusi / richieste mettendo questo vicino al fondo della pagina:

<?php var_dump(get_included_files()); ?>
Risposto il 12/12/2008 a 02:45
fonte dall'utente

voti
5

Vorrei:

  1. Sedersi e prendere un respiro profondo;
  2. Decidere se è davvero dove si desidera lavorare;
  3. Supponendo che sì, allora avrei rimboccarsi le sleaves, scegliere una mensa per lavorare su in un momento e mettersi al lavoro.

So che non possiamo limitarci a un solo compito alla volta; tuttavia, è possibile limitare il vostro lavoro per risolvere uno disordine alla volta mentre si lavora sui compiti quotidiani che vengono in.

Risposto il 09/12/2008 a 20:09
fonte dall'utente

voti
3

Prendere in considerazione una ri-scrittura e utilizzare il vecchio sito come una specifica funzione

Sorprendentemente, nessuno anche detto questo, per quanto posso vedere, ma c'è un'altra alternativa: rinunciare a codice e basta usare la funzionalità del sito stesso come una specifica nuova serie di funzionalità (ad esempio, il primo in assoluto per questo progetto) e poi ri-costruire il sito, sulla base di tali caratteristiche, con un quadro stabilito (come Symfony, laravel o Drupal).

Sì, ci sono coloro che rabbrividire al termine del male ri-scrivere ... ma ci sono casi in cui questo è in realtà un modo migliore per andare, e si accennate alcuni motivi:

  • sei abbastanza nuovo per PHP per lo sviluppo da soli,
  • si sarà probabilmente essere meglio partire con qualcosa di pulito al posto del codice merda pura hai ereditato
  • in ultima analisi, la maggior parte degli utenti non danno una maledizione circa il codice sorgente , e se sembra che "funziona" a loro, essi possono guardare come se fossi pazzo se si cerca di dire loro qualcosa è terribilmente sbagliato
  • si avrà più divertimento e vivere una vita più a lungo se si prende in mano le pratiche di controllo di revisione sorgente e progettazione di database all'interno di un quadro unitario che sembra che qualcuno in realtà curato abbastanza per avere il loro nome collegato ad esso

Certo, tutti in questa posizione ha dovuto lavorare con il codice di simile prima, ma a volte troppo è troppo ed è meglio di rottamare gli spaghetti e iniziare con un piatto fresco.

Se andate a leggere l'articolo di Joel sul motivo per cui è male fare una ri-scrittura, si noterà quasi nessuna delle circostanze egli cita applicano a voi qui.

Risposto il 10/12/2008 a 01:02
fonte dall'utente

voti
2
  1. Avere sotto controllo di revisione.

  2. Decidere su convenzioni di denominazione e struttura dei file / directory.

  3. Assicurarsi di avere decente strumenti / IDE.

  4. Impostare un ambiente di sviluppo / testing separato se non l'hai già

POI ...

  1. Purtroppo, è necessario passare al setaccio tutti quei 1, 2, 3 file e determinare quali sono in uso, e che possono essere smaltiti. Nessun altro modo oltre ad una forza bruta macinare attraverso, file per file.

  2. Anche se ho un RCS a posto, ho ancora spesso spostare quello che penso sono gli script non utilizzati in una posizione nascosta, dire .mausoleum e quindi avere la RCS ignorare quella posizione. Bello essere in grado di dare uno sguardo a livello locale, senza tornare al repo.

  3. HTML separato e PHP, nella maggior misura possibile . Non lo ripeterò mai abbastanza! Se questo viene fatto in ogni file, bene. Proprio così finché si dispone di pezzi separati di PHP e HTML. Naturalmente, HTML sarà condito con echi qua e là, ma cercare di avere tutti i test, gli interruttori, tutto il resto portate fuori dal blocco HTML e nel blocco di PHP. Questo da solo può essere enorme quando si tratta di fare le cose risolto.

  4. Se il codice è in primo luogo procedurale - presumo nel tuo caso si tratta - è probabilmente meglio a fare un po 'ripulire prima, prima di fare qualsiasi refactoring gravi o refactoring in classi.

  5. Come trovare i file / script che possono essere combinati logicamente, lo fanno. (Ho visto i progetti - probabilmente non dissimile vostro - dove il numero totale di file sopravvissuti è circa 1/4 di quello che abbiamo iniziato con).

Una volta che sei andato fino a questo punto, allora si può iniziare un refactoring proprio o refactoring in classi.

Bonne chance!

Risposto il 02/03/2009 a 18:50
fonte dall'utente

voti
2

Un sacco di posti utili su come affrontare la questione.

Senza cercare di ripetere ciò che è già stato detto:

  1. Ottenere una copia dell'ambiente prod esecuzione. Può essere una macchina virtuale, o un'altra macchina reale. Ma è necessario essere Dio su di esso. Se il database prod è su un altro box, avrete bisogno di una versione dev, anche.
  2. Buttare tutto in controllo di versione. In un'altra scatola. Uno che viene eseguito il backup almeno settimanalmente.
  3. Assicuratevi di sapere come ramificazione opere nell'applicazione controllo di versione. Avrete probabilmente bisogno.
  4. Ottenere il server prod bloccato. Se non si desidera ulteriori modifiche ad essa apportate che non escono di controllo di versione.
  5. Creare le istruzioni per il rilascio del codice dal controllo di versione per il server prod. La più piccola unità di cambiamento rilasciabile dovrebbe essere l'intera base di codice.

I passi successivi dipendono da come collegato ad esso gli utenti sono. Se non può essere modificato a molto per qualsiasi motivo, è necessario un approccio progressivo. Se lo sviluppo e la manutenzione deve ancora accadere, allora questo è probabilmente l'unica opzione. Ricordate di usare questa funzione diramazione per separare tali mods lontano dai tuoi sforzi ri-scrittura.

Per mettere senso nella struttura, è necessario creare fondamentalmente una nuova struttura a fianco quello che c'è. Un nuovo gestore DB di solito è un buon punto di partenza, incluso da un generico file include che ogni pagina dovrebbe caricare. L'obiettivo qui è quello di creare un minimo includono struttura che può essere ampliata in seguito senza dire ogni pagina per caricare i file aggiuntivi.

Ora è necessario iniziare a muoversi funzionalità rispetto ai tuoi nuovi file include. Avrete bisogno di un modo per avere diversi file aperti contemporaneamente, come ad esempio un editor multi-file, o lo schermo + VI (o emacs). Inizia con funzioni di utilità e il codice-blocchi che si ripetono in vari luoghi. Cercate di non distrarsi nella fissazione di un sacco in una volta. Alcuni tipi di problemi sono costrette a muoversi solo luoghi come altri problemi vengono risolti. Tornerai a loro più tardi.

Non sentite il bisogno di aggiungere un framework di terze parti. L'aggiunta di una cosa del genere in fretta porta a una completa ri-scrittura. A questo punto, questo sarà un bel po 'più lavoro che solo domare la sua struttura di inclusione. Così ordinare che fuori prima.

Mentre ci si sposta la funzionalità sopra, è necessario avere i file utilizzare il nuovo file di inclusione. Le prime file si fa questo per voi saranno a caccia di conflitti per un po '. Si sente sconfortante e senza senso, ma questa è probabilmente la parte più difficile. Dopo un paio di file, sarà più facile ottenere. Ci saranno momenti in cui è possibile migrare una mezza dozzina di pagine per il nuovo file include sostituendo una dozzina include con un solo. Il rovescio della medaglia di tale azione è che ci saranno file si può semplicemente cancellare.

Se ti infili a esso, alla fine arriva al punto in cui tutti i file include sono quelli che hai scritto e ti verrà su tutto il territorio includono layout. A quel punto, sarà molto più facile da fare cambiamenti molto più invasivi, come mettere in un quadro di terze parti.

Risposto il 10/12/2008 a 05:31
fonte dall'utente

voti
2
  1. Fare un back-up del codice ora.

  2. Il controllo delle versioni.

  3. Creare un sito di prova. Il sito è in esecuzione in Apache? È anche possibile installare Apache + MySQL + PHP sul proprio computer, e l'uso che per i test.

  4. Trattare con problemi di sicurezza. Assicurarsi che il sito è protetto da SQL injection, e dall'iniezione di posta elettronica. Per lo meno, si può fare una ricerca di chiamate al database e aggiungere le chiamate a mysql_real_escape_string()(beh, se si sta usando un database MySQL) ... si può fare una vera e propria correzione in seguito una volta capito il codice migliore. Per l'iniezione di posta elettronica ... scrivere la funzione di filtro che filtra il codice di spammer, e assicurarsi che tutti i campi modulo che vengono utilizzati in una e-mail vengono filtrati. (Sì aggiunge più spaghetti code, ma sta andando a prendere un po 'prima si è pronti a refactoring in modo significativo il codice.)

  5. Dopo di che, vi suggerisco di aggiornamenti incrementali. Tu sei nuovo e il codice è un pasticcio higgleypiggley, quindi ci vorrà un po 'per capire tutto ... e per comprendere appieno il dominio. Quindi basta andare circa il vostro lavoro per un po ', fissare ciò che deve essere riparato, l'aggiunta di quello che deve essere aggiunto. Come si sta facendo così, si sta imparando come funziona il sistema è messo insieme. Una volta che si sa come è organizzato il codice (o non organizzata) un po 'meglio, si può iniziare a pianificare un importante refactoring / riscrittura del sistema. Speriamo che si può farlo componente per componente in modo che hai sempre avuto un nuovo traguardo in vista.

Risposto il 10/12/2008 a 00:06
fonte dall'utente

voti
2

So come ti senti. Ho ereditato lo sviluppo di un progetto del genere. E 'rimasto con me per un anno e ad essere sinceri, mi ha fatto lo sviluppatore che sono oggi. Non c'è occasione migliore per l'avanzamento personale che lavora al ginocchio profondo nella merda.

Qui ci sono le cose che mi hanno aiutato a più:

  • identificare quali sono i file chiave del sistema. Troverete loro perché la maggior parte del lavoro sarà fatto in loro
  • creare una versione locale del progetto (incluso il database) e metterla sotto il controllo di versione
  • funziona solo su una piccola quantità di file con piccoli cambiamenti
  • non inserire nulla all'interno della versione di produzione prima di aver testato a fondo, e poi essere pronti a mettere la vecchia versione posteriore
  • scoprire come gli utenti del sistema sono gestite (sessioni, biscotti). Creare un utente super e poi quando hai bisogno di testare il codice in diretta sul sistema di metterlo in un blocco come questo:

    if($_POST['your_registered_user_name']{
       //Your live code being tested, which will be visible only to you when you are logged in
    }
    

    gli altri utenti non sarà in grado di sentire i cambiamenti. Questa tecnica mi ha aiutato molto quando ero in grado di sostituire lo stato del sistema sulla mia macchina locale

  • scrivere di prova, e seguire le rigide linee guida di ingegneria per tutto il codice che si sta scrivendo

Risposto il 09/12/2008 a 23:09
fonte dall'utente

voti
2

Questo è davvero un disastro. Ma iniziare a ricevere creativo su dove tagliare alcuni dei tentacoli su questa cosa:

  1. Prendi il controllo di versione. Vi consiglio Git.
  2. Impostare un server di sviluppo locale. Trova un WAMP, LAMP o MAMP pacchetto per iniziare dal momento che siete nuovi a questo.
  3. Trova i punti di ingresso (index.php, etc.). Controllare i log di accesso del server per vedere che cosa si tratta.
  4. Rimboccarsi le maniche su qualche magia nera espressione regolare e scartare un include / richiedono albero su tutti i file. Ma attenzione di qualsiasi include ($ filename) dinamico include. Se avete uno di questi sarà necessario fare un po 'la registrazione su $ nomefile per scoprire cosa eventualmente viene incluso, anche se il codice intorno ad esso dovrebbe darvi indizi. Con un po 'di fortuna si possono abbattere tutti i file non utilizzati in questo modo.
  5. Usare la magia nera più regex per controllare funzioni e metodi vengono riferimento in altre parti del codice di base. Ci può essere un IDE che può aiutare con questo. Prova NetBeans (ho usato per aiutarmi a refactoring un progetto C ++, una volta, in modo che può aiutare qui.)
  6. Come qualcun altro ha risposto: "scoprire, se necessario, se si utilizzano alcune classi e alcuni non lo sono, è possibile utilizzare in combinazione con get_declared_classes get_defined_vars e GetType per vedere quali tipi vengono istanziati." Si potrebbe anche solo scrivere del codice per trovare tutte le nuove istruzioni nella base di codice.
  7. E così via ... basta pensare a come si può whittle questo mostro verso il basso. E cercare di riorganizzare il codice dove si può.
Risposto il 09/12/2008 a 20:31
fonte dall'utente

voti
2

Ecco alcune idee:

  • PHP e Apache funzionano bene anche su Windows. Forse si può fare un'installazione di Windows tutto, dopo tutto?
  • Prova grep'ing (o qualche alternativa di Windows) per 'includere' e 'richiede' in tutti i file PHP. Poi fare una lista di tutti i file inclusi trovati. Confrontare l'elenco con i file presenti nella cartella. Si dovrebbe essere in grado di sbarazzarsi di almeno alcuni dei file senza riferimenti.
  • In alternativa, fare una lista di tutti i nomi di file e cercare tutti i file per loro. Si potrebbe fare qualcosa di simile a un grafico dipendenza come questo.
Risposto il 09/12/2008 a 20:30
fonte dall'utente

voti
2

Credo che tutti e 5 i punti colpiti su alcuni progetti ASP classico che ho ereditato, e PHP uno di troppo ...

Sono completamente d'accordo con gli altri sul farlo in controllo del codice sorgente ASAP e utilizzare VMware, VirtualBox, ecc per un ambiente di test.

Assicurarsi di avere il database di versione troppo, soprattutto se le procedure hanno una logica più in loro (non solo inserto dritto, aggiornamento, cancellazione). DB versioning richiede più attenzione quindi le pagine php. È necessario generare tutti gli oggetti di script SQL e mettere questi script in controllo del codice sorgente. Allora come si cambia la struttura db, procedure, ecc è necessario aggiornare gli script in modo da avere una storia di tali modifiche troppo.

Quanto a capire che cosa sta usando quello sul lato del database vorrei suggerire guardando ApexSQL Clean . Ho usato questo su un progetto con diverse centinaia di file ASP, oltre 200 tabelle e circa 400 stored procedure. Sono stato in grado di identificare 20 o giù di lì le tabelle che non erano in uso e circa il 25% delle stored procedure. Con ApexSQL Clean è possibile aggiungere tutti i file php nel controllo delle dipendenze con le tabelle, viste e stored procedure. Afferra la prova di 30 giorni e check it out, ti farà risparmiare un sacco di tempo.

Per quello che i file erano in uso per il sito web, ho avuto log del server web per il mese precedente e corsi ricerche contro di loro per qualsiasi cosa ero sicuro su. Faccio anche come una variazione su quello Aistina suggerito sulla modifica dei file per accedere quando vi si accede. Forse hanno vai a una tabella nel database di configurazione che è il nome del file e l'accesso conteggio e per ogni volta che viene caricato il file si incrementa il conteggio. Poi, dopo un periodo di tempo si può guardare oltre i conteggi e determinare ciò che può andare.

Risposto il 09/12/2008 a 20:24
fonte dall'utente

voti
2

Il primo passo, naturalmente, sarebbe quello di mettere sotto controllo di versione. In questo modo almeno si può tornare indietro alla versione originale di lavoro. In secondo luogo, potrebbe essere una buona idea per sovrascrivere l'inclusione, richiedono, ecc funzioni, ad esempio, scrivere il nome del file che viene incluso in qualche file di log, in questo modo si può scoprire quali file sono effettivamente inclusi (in tal modo si spera escludendo un sacco di index2.php, index3.php, etc.

Per scoprire, se necessario, se si utilizzano alcune classi e alcuni non lo sono, è possibile utilizzare in combinazione con get_declared_classes get_defined_vars e GetType per vedere quali tipi vengono istanziati.

Per quanto riguarda la questione 4 e 5, questi sono probabilmente un po 'più difficile da risolvere, ma questo dovrebbe iniziare spera.

Risposto il 09/12/2008 a 20:01
fonte dall'utente

voti
2

È sicuramente bisogno di un ambiente di sviluppo. Se non si vuole fare confusione con la gestione del sito sulla propria macchina Windows, si potrebbe prendere un'immagine VMWare di alcune distro Linux.

Risposto il 09/12/2008 a 19:53
fonte dall'utente

voti
2

La prima cosa che vorrei fare è impostare un ambiente di test utilizzando una macchina virtuale di qualche tipo. VirtualBox o Virtual PC sarebbero scelte belle. In questo modo è possibile iniziare a cambiare le cose senza paura di rompere l'ambiente di produzione. Non importa quanto lavoro questo sembra che sarà (con il server di database e web e tutto), alla fine ne sarà valsa la pena. Uno dei grandi vantaggi è che si può copiare la VM e darlo a qualcun altro, se trovate avete bisogno di assistenza.

Risposto il 09/12/2008 a 19:50
fonte dall'utente

voti
1
  1. iniziare a utilizzare il controllo di versione nel progetto (mi raccomando git)
  2. scrivere unit test per tutto il codice
  3. iniziare ad usare ORM (consiglio vivamente dottrina)
  4. iniziare a utilizzare un quadro di riferimento (vi consiglio di symfony / nette)
  5. iniziare il refactoring del codice php
Risposto il 02/12/2010 a 08:54
fonte dall'utente

voti
1

Sì, il controllo della versione è sicuramente un passo # 0.

Consiglio anche un buon codice strumento di ricerca .

Agente Ransack è piuttosto buona (supponendo che si sta su Windows) http://www.mythicsoft.com/agentransack/Page.aspx?page=download

Sarei cieca, senza ricerca del codice.

Risposto il 11/01/2009 a 20:55
fonte dall'utente

voti
1

Ho appena passato attraverso questo io stesso.

Il mio numero uno suggerimento è quello di non cercare di cambiare tutto il giorno uno. Hai bisogno di amici, se vuole veramente essere in grado di risolvere questa cosa. È necessario il rispetto colleghi prima di lei suggerisce come cambiare tutto quello che hanno lavorato per mesi (anni?).

In primo luogo, ottenere il codice sotto controllo di versione il più presto possibile. Se questo non sara 'facile per voi, almeno iniziare a fare i backup giornalieri, anche se questo significa semplicemente zippare i file e nominando il file zip con la data. Se nessuno ci conosce il controllo di versione, comprare il libro di un programmatore Pragmatic su CVS o SVN, e impostarlo su voi stessi. I libri possono essere letti in un giorno, e si può essere rapidamente operativi. Se nessun altro vuole utilizzare il controllo di versione, è possibile utilizzare da soli ... poi quando qualcuno perde un file è possibile salvare la giornata con una copia dal vostro repo. Prima o poi gli altri vedranno la sapienza che è il controllo di versione.

In secondo luogo, analizzare il codice così difficile come è possibile. Live it e respirare per un mese. Mostra le persone che sono lì che si sta per imparare il loro codice.

In terzo luogo, come si passa attraverso il codice, prendere appunti. Annotare ogni cosa che ti dà fastidio sul codice. Basta avere i vostri pensieri sulla carta. È possibile organizzare un secondo momento, dopo il Mese One.

In quarto luogo, installare un profiler di codice (come xdebug). Questo ti dirà quali file e funzioni sono chiamati in ogni pagina, e per quanto tempo ogni pezzo di codice necessario per eseguire. È possibile utilizzare questo per capire il vostro include problemi, e trovare pezzi lenti di codice. Ottimizzare quelli prima.

Dopo il mese di duro lavoro, spulciando il codice, e prendere appunti, trasformare le note in un documento corretto. Le diverse sezioni potrebbero variare dalla sicurezza, alla cache, all'architettura, per qualsiasi altra cosa ti dà fastidio. Per ogni critica si effettua, di offrire una soluzione migliore, e una stima di quanto tempo ci sarebbe voluto per risolvere. Questo è dove si sbarazzarsi di tutti i concorrenti framework JavaScript etc.

Rivedere questo documento il più possibile. Non posso sottolineare che sufficiente.

Assicurati che il tuo pubblico può dire che stai facendo per il bene della società, non solo le preferenze personali.

Presentarlo al tuo capo, di persona. Set-up un tempo per discuterne.

Essi potrebbero licenziarti per aver scritto. Se lo fanno, si sta meglio senza di loro, perché non vogliono migliorare, e la tua carriera sarà ristagnare.

Essi potrebbero decidere di implementare tutte le vostre raccomandazioni. Non è probabile, ma è possibile. Allora si sarebbe felice (a meno che le vostre raccomandazioni fallire).

Molto probabilmente vorranno implementare alcune delle vostre raccomandazioni, e che è meglio di niente. Per lo meno, vi aiuterà ad alleviare le vostre preoccupazioni.

Per quanto riguarda i test, impostare un altro "ospite virtuale" in Apache (supportato sia su Windows e Linux). Host virtuali consentono di eseguire più siti su un singolo server. La maggior parte dei siti più grandi hanno almeno 3 host virtuali (o server effettivi): dev.domain.com (per lo sviluppo al giorno), staging.domain.com (per QA le persone a fare test su poco prima di un rilascio), e www.domain. com (server di produzione). Si dovrebbe anche impostare dev, staging e produzione le versioni del database, con differenti dati di accesso e le password in modo da non confondere accidentalmente.

Una soluzione alternativa potrebbe essere quella di dare ad ogni sviluppatore proprio host virtuale sul server Linux, e possono lavorare via FTP / SCP o condivisione di rete utilizzando Samba.

In bocca al lupo!

Risposto il 11/12/2008 a 03:29
fonte dall'utente

voti
0

Oltre al grande roba altre persone hanno detto, per ottenere un primo passo a quali file sono attivamente in uso, è possibile installare una cache codice operativo come APC o eAccelerator sul server dev (o anche un server di produzione, questo non si rompe nulla). Quindi, fare clic intorno al web app sul vostro server dev (o lasciare che gli utenti fanno sul vostro server di produzione).

Ora guardate la lista dei file memorizzati nella cache nella tua pagina cache di amministrazione. Se un file non è elencato come cache per la cache codice operativo, c'è una buona probabilità che non viene caricata da nulla.

Questa non è una soluzione tutta, ma se ogni directory ha 10 file index.php (ad esempio index.php, index2.php, ecc), almeno saprete quale è utilizzato da vostra applicazione.

Risposto il 11/12/2008 a 03:35
fonte dall'utente

voti
0

Fai quello che ha detto Harper Shelby ...

Ma, Vorrei anche aggiungere che, se non si ottiene il supporto di gestione per pulire questo in su, è possibile accettare il fatto che questo può essere come questo per un motivo. ... solo dicendo. ;-)

Risposto il 09/12/2008 a 20:29
fonte dall'utente

voti
0

Cercare di ottenere statistiche dettagliate sul sito e scoprire dove i punti di ingresso e di uscita sono. Un modo decente per scoprire quali file sono colpiti fuori della parte superiore (e quindi cercare in quei file per vedere che comprende vengono tirati).

Risposto il 09/12/2008 a 19:58
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more