
Έχω κληρονομήσει ένα έργο PHP που είναι φαίνεται να είναι ένας εφιάλτης. Εδώ είναι τα βασικά σημεία:


1. Όλοι οι αρχικοί προγραμματιστές έχουν απομείνει
2. Ο κωδικός δεν έχει κανέναν έλεγχο έκδοσης
3. Όλα ανάπτυξη και δοκιμή έγινε στο live διακομιστή από τη μετονομασία και την επεξεργασία των αρχείων της PHP. Υπάρχουν πολλαπλά αντίγραφα του κάθε index.php αρχείο, index2.php, index3.php κλπ και δεν είναι ξεκάθαρο ποια αρχεία που χρησιμοποιούνται πραγματικά
4. Υπάρχουν πολλές περιλαμβάνει σε κάθε φάκελο με τα αρχεία που περιλαμβάνουν άλλα αρχεία που περιλαμβάνουν άλλα αρχεία, κ.λπ.
5. Έχουν υπάρξει πολλούς προγραμματιστές για το έργο που ο καθένας είχε το δικό του εκεί τον τρόπο αντιμετώπισης των πραγμάτων. Για παράδειγμα, υπάρχει ένα συνονθύλευμα των πλαισίων JavaScript, μερικά ερωτήματα βάσεων δεδομένων χρησιμοποιούν SQL, άλλοι μια διεπαφή XML και άλλοι καλούν διαδικαστικές λειτουργίες στη βάση δεδομένων.


Λόγω όλων αυτών των προβλημάτων, η ανάπτυξη είναι απογοητευτικά αργή. Εκτός από τον εξαερισμό απογοητεύσεις μου για να υπερχείλιση στοίβας, οποιεσδήποτε προτάσεις για το πώς να ξεκινήσετε σε αυτό το χάλι; Είμαι αρκετά νέος για την ανάπτυξη της PHP εαυτό μου, αλλά φαίνεται ότι για τη δημιουργία κάποιου είδους περιβάλλον ανάπτυξης, έτσι ώστε οι αλλαγές μπορεί να ελεγχθεί χωρίς να σπάσει το live server είναι το πρώτο βήμα. Κάθε συμβουλές για το πώς να ξεκινήσετε εδώ; Τι είναι ένα τυπικό τρόπος για να γίνει έλεγχος; Η δημιουργία ενός τοπική έκδοση του site στην επιφάνεια εργασίας μου φαίνεται σαν μια πολλή δουλειά (server είναι το Linux, αλλά επιτραπέζιους υπολογιστές εδώ είναι τα Windows). Μπορώ να δημιουργήσω ένα υποκατάλογο στο live διακομιστή για τη δοκιμή, ή ..; Τι γίνεται με τη βάση δεδομένων;


Δεύτερον, είναι ένα είδος προφίλ μπορώ να μπορέσει να παρακολουθείτε ποια αρχεία στο διακομιστή που χρησιμοποιούνται πραγματικά εκεί; Θα ήθελα να διαγράψετε τα μετονομαστεί αντίγραφα πράγματα που δεν έχουν περιληφθεί στην πραγματικότητα. Ακόμα καλύτερα, είναι ένας τρόπος να πει κανείς ποια μέρη του αρχείου δεν εκτελούνται εκεί; Υπάρχουν πολλά αντιγραφεί λειτουργίες και τα σκουπίδια από το γεγονός ότι υποψιάζομαι δεν χρησιμοποιούνται ούτε. Ομοίως, για την περιλαμβάνει, οποιεσδήποτε συμβουλές για το ίσιωμα από το χάος;


Λοιπόν, εγώ θα σταματήσει τον εξαερισμό εδώ και να ρίξει τον εαυτό μου στο έλεος του καθενός εδώ. :)

 
Κληρονόμησε έναν εφιάλτη PHP, από πού να αρχίσω;
================================================



1. Πριν απ 'όλα, να πάρει τα αρχεία στον έλεγχο έκδοσης, όπως είναι. **Μην προχωρήσετε παρελθόν # 1 μέχρι να γίνει.**
2. Δημιουργία ενός περιβάλλοντος δοκιμών.
3. Καθαρίστε τα αρχεία

 

Έχω κάνει αυτό. Έχετε τη συμπάθειά μου. Αν το διαβατήριό σας δεν είναι εν ενεργεία ή για κάποιο άλλο λόγο δεν μπορείτε να αποφύγει να γίνει αυτό, εδώ είναι το πώς θα το προσεγγίσει:


Βήμα Zero είναι να μπει σε έλεγχο έκδοσης, δεν έχει σημασία πόσο μίζερη είναι. Αν ακόμα και το είδος των έργων, και θα σπάσει κάτι, θα πρέπει να είναι σε θέση να επιστρέψει στην κατάσταση εργασίας - ή τουλάχιστον να συγκρίνετε τις αλλαγές σας στο να καταλάβω τι πήγε στραβά. Κάνετε συχνά, μικρά check-ins, όπως είστε refactoring, και θα έχετε λιγότερο κώδικα για να κυλήσει πίσω όταν τα πράγματα πάνε στραβά μυστηριωδώς. (Τα πράγματα θα μυστηριωδώς πάει στραβά.)


Μετά από αυτό, θα ήθελα να ξεκινούν από τη βάση δεδομένων. Βεβαιωθείτε ότι τα πάντα είναι σχετικά καλά-κανονικοποιημένη, στήλες έχουν ξεκάθαρες ονομασίες, κ.λπ.


Κάντε το κωδικό PHP επόμενη. Εάν ο κωδικός είναι πραγματικά τόσο πολύ από ένα συνονθύλευμα, θα ήθελα να προχωρήσει και τοποθετήστε το σε ένα πλαίσιο. Κοιτάξτε σε [CakePHP](http://cakephp.org/ "CakePHP") ή [Symfony](http://www.symfony-project.org/ "Symfony") - Κάγκελα-ish τρόπο τους χωρίζει τις ανησυχίες κάνει το ερώτημα «πού θα πρέπει αυτό το κομμάτι του κώδικα πάει;» εύκολο να απαντηθούν. Δεν είναι μια εύκολη υπόθεση, αλλά από τη στιγμή που έχετε κάνει, είστε μάλλον καλύτερα από ό, τι στα μισά του δρόμου για να έχουν μια σωφρονώς κατασκευασμένο app. Επίσης, το ενσωματωμένο σε εγκαταστάσεις δοκιμών ενός καλού πλαισίου web κάνουν refactoring πολύ πιο εύκολο - γράψει ένα τεστ για να καλύψει ένα υπάρχον κομμάτι λειτουργικότητας, πριν να το αλλάξετε, και θα το μάθετε αν έσπασε τίποτα μετά την αλλαγή.


Μόλις έχετε τη βάση δεδομένων σας ταξινομούνται και να έχουν τον κωδικό μοντέλου στα μοντέλα και τον κωδικό ελέγχου των ελεγκτών, τότε μπορείτε να ανησυχείτε για τα πράγματα παρουσίαση επιπέδου όπως τυποποίηση σε μια ενιαία βιβλιοθήκη JS / AJAX, τον καθαρισμό των CSS, κ.λπ.


Όσο για ένα περιβάλλον dev: Θα πρέπει οπωσδήποτε δημιουργήσει ένα τοπικό περιβάλλον dev. Υπάρχουν ετοιμοπαράδοτα πακέτα WAMP εκεί έξω, ή θα μπορούσατε να εγκαταστήσετε σε ένα κουτί Linux / VM (συστήνω [το VirtualBox](http://www.virtualbox.org/ "VirtualBox") για virtualization). Θα πρέπει επίσης να έχουν ένα ξεχωριστό περιβάλλον δοκιμής ολοκλήρωσης που μιμείται το live server. Τίποτα δεν αλλά ζωντανή κώδικας θα πρέπει να τρέξει στο live server.


Όσον αφορά τον εντοπισμό σφαλμάτων / προφίλ εργαλεία, ξέρω ότι Symfony έρχεται με ένα αρκετά λείο σύνολο εργαλείων, συμπεριλαμβανομένων μια μικρή γραμμή εργαλείων JS που εμφανίζεται στις σελίδες σας (μόνο στη λειτουργία εντοπισμού σφαλμάτων) με την καταγραφή και προφίλ πληροφοριών.


Καλή τύχη.

 

Λοιπόν, πρώτα πράγματα πρώτα. Έχω πάει στην κατάσταση που είστε μέσα, και είναι χάλια. Νομίζω ότι είστε στο σωστό δρόμο με την επιθυμία να πάρει ένα περιβάλλον ανάπτυξης και λειτουργεί. 


Ανάπτυξη περιβάλλον
-------------------


Αυτό θα περιλαμβάνει ένα webserver / script στοίβα κινητήρα / μηχανισμό διαχείρισης βάσεων δεδομένων, και ένα IDE πιο πιθανό.


Για **[LAMP](http://en.wikipedia.org/wiki/LAMP_(software_bundle)) εγκατάστασης στοίβα** , σας προτείνουμε να χρησιμοποιήσετε ένα από αυτά:


* <http://www.apachefriends.org/en/xampp-windows.html>
* <http://www.easyphp.org/>
* <http://www.nucleex.com/nucserv/>


Περαιτέρω ανάγνωση στη στοίβα LAMP:


[ιστοσελίδα OnLamp του O'Reilly](http://www.onlamp.com/)


Για μια καλή **PHP IDE** , σας προτείνουμε να χρησιμοποιήσετε ένα από αυτά:


* [Zend Studio](http://www.zend.com/en/products/studio/)
* [ActiveState Komodo](http://www.activestate.com/Products/komodo_ide/index.mhtml)
* [Jetbrains PhpStorm](http://www.jetbrains.com/phpstorm/)


[Το άρθρο στην ιστοσελίδα προγραμματιστών της IBM](http://www.ibm.com/developerworks/opensource/library/os-php-ide/index.html) συγκρίνοντας διάφορα IDE του


Για **τον έλεγχο πηγή** , μπορείτε να χρησιμοποιήσετε Team Foundation Server, SVN ή Git - απλά χρησιμοποιήστε κάτι που ξέρετε. Θα ήθελα να συστήσω να πάρει τα πάντα στον έλεγχο πηγής πρώτη (για οποιαδήποτε συντήρηση έκτακτης ανάγκης που μπορεί να έχετε), αλλά στη συνέχεια το σχέδιο για να κάνει μια αρκετά μεγάλη αναμόρφωση. 


η Γενική επισκευή
-----------------


Είπατε ότι δεν γνωρίζουν καν τι αρχεία να συνηθίσει, και ότι χρησιμοποίησε ένα αρχείο σύμβαση ονομασίας ως ψευδο-έκδοση-ελέγχου. Μπορεί να θέλετε να ξεκινήσετε την αναμόρφωση εκεί, αφού έχετε ένα περιβάλλον ανάπτυξης και λειτουργεί. Υπάρχουν μερικά πράγματα που μπορούν να σας βοηθήσουν:


* Σας πελάτες app / χρήστες
* Σχολαστική και οργανωμένο σημειώσεων
* Ένα καλό πλαίσιο υλοτομία


**Οι πελάτες σας / χρήστες είναι σημαντικό** , γιατί ακούγεται σαν να είστε νέοι στο έργο και θα πάμε να ξέρει πώς η εφαρμογή θα πρέπει να συμπεριφέρονται καλύτερα από ό, τι (το πιο πιθανό). 


**Σχολαστική σημειώσεων είναι σημαντικό** , γιατί θα πάμε να είναι ουσιαστικά εκ νέου γραπτώς οποιαδήποτε τεκμηρίωση προδιαγραφές / σχεδίασης / τελικού χρήστη από το μηδέν. Θα πρέπει να κατανοήσουν τα εσωτερικά αν πρόκειται να το κάνουμε αυτό. Και αν θέλει κάποιος να καταλάβει κάτι σχετικά με αυτό το σύστημα, θα πρέπει να το γράψετε μόνοι σας (ή που θα πρέπει να λάβει γνώση προκατασκευασμένα τεκμηρίωση αυτή τη στιγμή, αντί της ανάγνωσης Υπερχείλιση στοίβας) ;-)


Και τέλος, **ένα πλαίσιο καταγραφής είναι σημαντικό** γιατί θα πρέπει να καθορίσει τα πράγματα, και δεν μπορείτε να διορθώσετε τα πράγματα που δεν ξέρετε είναι σπασμένα. Ένα πλαίσιο καταγραφής σας δίνει ορατότητα σε τμήματα της εφαρμογής που δεν έχουν καμία προφανή UI. Τοποθέτηση του σε διάφορα μέρη της εφαρμογής και στη συνέχεια εξετάζει τα αρχεία καταγραφής σας δίνει μια καλή ιδέα όταν ο κώδικας εκτελείται και με ποια σειρά.


Θα ήθελα να επικεντρωθεί στην καταγραφή (σε χαρτί) πώς η εφαρμογή θα πρέπει να εργαστεί, και στη συνέχεια αφαιρώντας αργά περιττά αρχεία, ενώ προσπαθεί να μην σπάσει τίποτα. Κρατήστε ένα μάτι για τα αρχεία καταγραφής για να βοηθήσει με τον εντοπισμό σφαλμάτων. Βεβαιωθείτε ότι οι πελάτες σας δεν κραυγάζει ότι κάτι έχει σπάσει. Βεβαιωθείτε ότι τις σημειώσεις σας συμφωνούν με αυτό που γίνεται όλο και καταγράφεται και τι λένε οι πελάτες σας.


Η πρόληψη στο μέλλον
--------------------


**Ελέγξτε ξανά τα πάντα πίσω τον έλεγχο πηγή** . Ας ελπίσουμε ότι θα έχουν φθάσει σε ένα νεότερο, saner, καλύτερη δομή του καταλόγου από αυτό το σημείο.


**Πάρτε μια δομή δοκιμή στη θέση του** . Ακόμα κι αν αυτό σημαίνει απλά να πάρει ένα βασικό πλαίσιο δοκιμής μονάδα στη θέση του και να κάνει κάποιες βασικές δοκιμές καπνό μετά από κάθε Ανάπτυξη, είναι καλύτερο από το τίποτα. Στην ιδανική περίπτωση, θα πρέπει να έχετε ένα μηχανικό έλεγχο ή καταρτισμένο και αξιόπιστο πελάτη που μπορούν να περάσουν τη δοκιμή του χρόνου μετά από κάθε αναπτύξετε.


**Βάλτε μια διαδικασία ανάπτυξης στη θέση του** , αν αυξηθεί πάνω από ένα προγραμματιστή. Έλεγχος αλλαγών στο περιβάλλον παραγωγής σας θα πρέπει να είναι η πρώτη σας προτεραιότητα. (Το τελευταίο πράγμα που θα θέλατε να κάνετε είναι να πάτε μέσω και πάλι αυτό, έτσι δεν είναι;) Θα πρέπει να έχουν μια σαφή και απλή διαδικασία για τη μετακίνηση μεταξύ περιβάλλοντος όρια (όπως Dev -> Δοκιμή στη συνέχεια Test -> Παραγωγή). 

 

Οι περισσότεροι από τη στιγμή που θα μπορεί να πει εάν ένα αρχείο που χρησιμοποιείται από τη χρήση grep.



```
grep -r "index2.php" *

```

Μπορείτε επίσης να χρησιμοποιήσετε το πρόγραμμα ανάλυσης PHP για να σας βοηθήσει καθαρισμού. Εδώ είναι ένα παράδειγμα σενάριο που εκτυπώνει τις λειτουργίες που έχουν δηλωθεί και λειτουργία κλήσεις:



```
#!/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";
        }
    }
}

```
 

Αν είναι η ίδια η χειρότερη περίπτωση, ο κωδικός είναι όλα scrampled, και όλα οθόνη αναμιχθεί με τη λογική και τις κλήσεις της βάσης δεδομένων, μπορείτε να κάνετε ό, τι είχα να κάνω με ένα έργο PHP.


Μου έδωσε τρεις ξεκινά την προσπάθειά της προσέγγισης refactoring. Ήταν σαν αναρρίχηση λόφων σε μια μοτοσικλέτα και να πάρει το 10% της τρόπο κάθε φορά. Έτσι πήρα μια άλλη προσέγγιση, η οποία κατέληξε να εργάζεται πολύ καλύτερα.


1. Έχω συνδεθεί ως χρήστης,
2. και εργάστηκε μέσα από κάθε οθόνη και κάθε χρήση περίπτωση θα μπορούσα να βρω.
3. Έσωσα την html για στατικά αρχεία,
4. και πήρε τις σημειώσεις σχετικά με τη διαδικαστική πράξη και προφανείς επιχειρηματικούς κανόνες.


Το έκανα αυτό για 3 ημέρες στερεών, και στη συνέχεια πήρε τις σημειώσεις μου και είχε μακρά συζήτηση με τους ενδιαφερόμενους φορείς.


Μετά την επίτευξη συμφωνίας σε ορισμένα πρώτα βήματα, θα επαναυλοποιηθεί όλα τα html UI σωστά, χρησιμοποιώντας την καλή συνεπή σχεδιασμό και την αφαίρεση. Μετά από να πάρει τροχαίο, θα μπορούσα να κάνω ένα ζευγάρι οθόνες ημέρα.


Στη συνέχεια, πήρα το αποτέλεσμα πίσω στα ενδιαφερόμενα μέρη και έτρεξε μέσα από μια δέσμη των περιπτώσεων χρήσης. (Οι ενδιαφερόμενοι ήταν πάρα πολύ ευχαριστημένοι με τα βήματα 1 και 2, επειδή δεν του άρεσε η πρώτη εφαρμογή σε όλα έτσι κι αλλιώς (έκπληξη) και τώρα έμοιαζε υπήρχε ελπίδα για βελτίωση, όχι μόνο για την ανάκτηση της sane-old-app.


Αυτό αποδείχθηκε ότι ήταν το τέλος της σκληρής δουλειάς (και το τέλος του αντιληπτού κινδύνου του έργου για τους ενδιαφερόμενους.)


Αποδείχθηκε ότι το πρώτο πλήρωμα είχε πάρει τόσο δεμένο με το δικό τους λανθάνοντα σπαγγέτι ότι υπήρχε στην πραγματικότητα σχετικά μικρή περιεκτικότητα στο έργο, έτσι διπλασιάζοντας είχε μικρότερη έκταση από ό, τι ο καθένας ύποπτο.


Αλλά η βασική απόφαση ήταν ότι το αρχικό κώδικα, τόσο το περιεχόμενο και τη δομή, ήταν unrefactorable και είχα ανάγκη να εργαστούν από μια εντελώς εξωτερική όψη με ένα νέο πλαίσιο που σωστά σχεδιασμένο.

 

1. Ρύθμιση ενός εξυπηρετητή ανάπτυξης (όπως αναφέρεται Greg Hewgill, το VirtualBox και Virtual PC είναι καλές επιλογές για αυτό).
2. Βάλτε τα τρέχοντα αρχεία ιστοσελίδα (συμπεριλαμβανομένων και των σχετικών web server και PHP διαμορφώσεις!) Σε έλεγχο έκδοσης.
3. Μάθετε τι αρχεία που χρησιμοποιούνται - χρησιμοποιήστε τη ρύθμιση του server ανάπτυξη σας για να ελέγξετε αφαιρώντας όλα τα αρχεία fooN.php και δείτε αν εξακολουθεί να λειτουργεί.
4. Προσευχήσου ... παρτίδες (ΟΚ, αυτό δεν είναι απαραίτητο, αλλά ακούγεται σαν θα σου χρειαστεί).

 

Ένα πράγμα που θα μπορούσε να εξετάσει είναι να εγκαταστήσετε την PHP «xdebug» επέκταση σε ένα περιβάλλον ανάπτυξης, που να εντοπίζουν όλες τις κλήσεις λειτουργία, και στη συνέχεια, όσο το δυνατόν πληρέστερα (ενδεχομένως μέσω αυτοματοποιημένων UI) να ασκήσει το σύνολο της αίτησης. Στη συνέχεια, θα είστε σε θέση να αναλύσει / αναλύσει τα αρχεία xdebug ίχνος για να βρείτε όλα τα αρχεία / λειτουργίες που χρησιμοποιούνται από την εφαρμογή.

 

Άλλοι λαοί σε αυτό το νήμα έχουν μεγάλη συμβουλές. Έχω πάει σε αυτή την κατάσταση πάρα πολύ. Πιθανώς ο καθένας σε ένα χρόνο στην καριέρα τους, μπήκε σε ένα έργο που μοιάζει να χτυπήθηκε από έναν ανεμοστρόβιλο.


Μια πρόταση θα ήθελα να προσθέσω είναι ότι πριν κάνετε οποιαδήποτε από τις καθαρισμού που περιγράφεται από άλλους λαούς, θα πρέπει να πάρετε management buy-in.


* Κάντε ένα σχέδιο βασισμένο σε προτάσεις σχετικά με αυτό το νήμα.
* Περιγράψτε νέο υλικό ή λογισμικό που θα χρειαστείτε για να δημιουργήσετε ένα περιβάλλον ανάπτυξης και δοκιμών, καθώς και των τιμών αυτά τα εμπόδια.
* Καταλάβουμε ποιες νέες δεξιότητες θα πρέπει να εκπαιδευτούν για να ρυθμίσετε και να χρησιμοποιήσετε το περιβάλλον ανάπτυξης και δοκιμών. Υπολογίστε το χρόνο και τα έξοδα που απαιτούνται για να μπορείτε να πάρετε αυτές τις δεξιότητες. Για παράδειγμα, τα βιβλία ή επί πληρωμή εκπαίδευση.
* Υπολογίστε ένα πρόγραμμα εργασίας για να κάνετε το καθάρισμα. Πόσο καιρό για να πάρει τον κώδικα υπό έλεγχο πηγή; Πόσο καιρό να καταλάβουν τη βάση δεδομένων; Πόσο καιρό να κατανοήσουμε την PHP και JavaScript κώδικα;
* Παρουσιάστε αυτό στον διευθυντή σας, και η φράση του στόχου όσον αφορά την παροχή προς τα κάτω γραμμή του. Για παράδειγμα, μια φορά τα πάντα είναι καθαριστεί, να κάνετε αλλαγές ή να ξεδιπλώσει νέες λειτουργίες θα είναι πιο γρήγορα, σφάλματα εντοπισμού σφαλμάτων θα είναι πιο προβλέψιμη, και να αναδιατάσσουν το νέο προσωπικό θα είναι ευκολότερη.


Φυσικά θα πρέπει να συνεχίσει να συνεργάζεται με το σημερινό χάος, γιατί είναι μια ζωντανή περιοχή. Διαχείριση της ζωντανή περιοχή έχει προτεραιότητα, έτσι ώστε το έργο καθαρισμού πρέπει να είναι μια εργασία στο παρασκήνιο. Αυτό σημαίνει ότι θα πάρει ακόμα περισσότερο. Οι εμπειρίες μου τον καθαρισμό μια μέτρια μεγέθους του έργου ως εργασία στο παρασκήνιο έχουν συνήθως έξι έως δώδεκα μήνες. Δεδομένου ότι η ιστοσελίδα θα συνεχίσει να εξελίσσεται κατά τη διάρκεια αυτής της περιόδου, μερικά από ολοκληρωμένες εργασίες καθαρισμού σας μπορεί να χρειαστεί να αναθεωρηθούν ή εκ νέου. Βεβαιωθείτε ότι ο διευθυντής σας κατανοεί όλα αυτά πάρα πολύ.


Αν ο διαχειριστής καδρονιών στο σχέδιό σας για να καθαρίσει αυτό το χάλι, ή δεν εκτιμούν τον καθαρισμό επάνω, τουλάχιστον τότε θα ξέρετε γιατί όλοι οι άλλοι κατασκευαστές έχουν εγκαταλείψει την εν λόγω εταιρεία!


Έχω μερικές συγκεκριμένες προτάσεις για το πώς θα προχωρήσει:


* Εκτός από όλα τα άλλα μεγάλα συμβουλές, θα πρότεινα τη χρήση του [τεστ Joel](http://www.joelonsoftware.com/articles/fog0000000043.html) ως σημείο αναφοράς. Το σχέδιό σας για τον καθαρισμό θα πρέπει να οδηγήσει σε ένα περιβάλλον εργασίας που θα καταφέρνουν καλά στο τεστ Joel.
* Διαβάστε την απάντησή μου στο « [Τι είναι οι καλύτεροι τρόποι για να καταλάβει ένα άγνωστο βάση δεδομένων;](https://stackoverflow.com/questions/278430/what-are-the-best-ways-to-understand-an-unfamiliar-database#278458) »
* Ενεργοποιήστε τη σύνδεση με την ιστοσελίδα ώστε να μπορείτε να αναλύσετε ποιες σελίδες PHP πραγματικά να ονομάζεται. Τουλάχιστον αυτό σας λέει ποια από index2.php, index3.php, index4.php, κλπ είναι πραγματικά ξεπερασμένη.
* PHP έχει μια συνάρτηση [`get_included_files()`](http://php.net/manual/en/function.get-included-files.php)που επιστρέφει έναν πίνακα όλων των αρχείων που περιλαμβάνονται κατά τη διάρκεια της τρέχουσας αίτησης. Με την είσοδο αυτές τις πληροφορίες, μπορείτε να βρείτε ποια αρχεία PHP είναι σε χρήση, ακόμη και αν δεν εμφανίζονται στο αρχείο καταγραφής web server.
* Θα πρέπει πραγματικά να έχουν μια δοκιμή και ανάπτυξη περιβάλλον που ταιριάζει διακομιστή παραγωγής σας. Δεν είναι καλό να δοκιμάσει σε Windows και να αναπτύξετε σε Linux. Δεν είναι καλό να χρησιμοποιήσετε MySQL 5.0 κατά τη διάρκεια της ανάπτυξης και MySQL 4.0 στην παραγωγή. Μπορείτε πιθανώς να ξεφύγει με μια πλατφόρμα υλικού που είναι πιο μέτρια (αν και συμβατή).

 

Μπορείτε να δείτε μια λίστα με όλα τα περιεχόμενα / απαιτούμενα αρχεία από τη θέση αυτή στο κάτω μέρος της σελίδας: 



```
<?php var_dump(get_included_files()); ?>

```
 

Θα:


1. Κάτσε κάτω και να πάρει μια βαθιά ανάσα?
2. Αποφασίστε αν αυτό είναι πραγματικά όπου θέλετε να εργαστείτε?
3. Υποθέτοντας ότι ναι, τότε θα σηκώσουμε τα μανίκια μου, επιλέξτε ένα χάος για να εργαστούν σε μια στιγμή και να πάμε στη δουλειά μας.


Ξέρω ότι δεν μπορούμε να περιοριστούμε σε ένα μόνο έργο σε μια στιγμή? Ωστόσο, μπορείτε να περιορίσετε την εργασία σας για την επίλυση ενός χάος σε μια στιγμή, ενώ εργάζονται για τις καθημερινές εργασίες που μπαίνουν.

 

Σκεφτείτε μια ξαναγράψει και να χρησιμοποιήσετε το παλιό site ως προδιαγραφές λειτουργία
----------------------------------------------------------------------------------------


Παραδόξως, κανείς ακόμα και *αναφέρθηκε* αυτό, όσο μπορώ να δω, αλλά δεν υπάρχει άλλη εναλλακτική λύση: **να εγκαταλείψει σχετικά με τον κώδικα και να χρησιμοποιήσουν τη λειτουργικότητα του ίδιου του τόπου, όπως ένα νέο σύνολο χαρακτηριστικών γνωρισμάτων προδιαγραφές** (δηλαδή, το πρώτο ποτέ γι 'αυτό του έργου) και στη συνέχεια εκ νέου την κατασκευή του site, με βάση αυτά τα χαρακτηριστικά, με έδρα πλαίσιο (όπως Symfony, Laravel, ή Drupal).


Ναι, υπάρχουν και εκείνοι που θα μαζεύομαι στη κακό λέξη *ξαναγράψουν* ... αλλά εκεί *είναι* περιπτώσεις που αυτό είναι πραγματικά ένας καλύτερος τρόπος να πάει, και άφησε να εννοηθεί σε ορισμένα λόγους:


* είστε αρκετά νέα για την PHP ανάπτυξη, τον εαυτό σας
* μάλλον θα είναι καλύτερα να ξεκινάμε με κάτι *καθαρό* , αντί του καθαρού κώδικα χάλια που έχετε κληρονομήσει
* σε τελική ανάλυση, *οι περισσότεροι χρήστες δεν δίνουν δεκάρα για τον πηγαίο κώδικα* , και αν αυτό μοιάζει να «δουλεύει» για να τους, που μπορεί να σε κοιτάζουν σαν να είσαι τρελός αν προσπαθήσετε να τους πω κάτι είναι τρομερά λάθος
* θα έχετε περισσότερη διασκέδαση και να ζήσουν μια μεγαλύτερη διάρκεια ζωής, αν πάρει τις πρακτικές ελέγχου αναθεώρησης πηγή και το σχεδιασμό της βάσης δεδομένων σε ένα ενιαίο πλαίσιο που μοιάζει με κάποιον που πραγματικά νοιαζόταν αρκετά για να έχουν το όνομά τους που συνδέονται με το


Σίγουρα, ο καθένας στη θέση αυτή είχε να συνεργαστεί με κωδικό όπως αυτό πριν, αλλά αρκετά μερικές φορές είναι αρκετό και είναι καλύτερο να καταργήσει τα μακαρόνια και να ξεκινήσετε με ένα νέο πιάτο. 


Αν διαβάσετε [το άρθρο του Ιωήλ](http://www.joelonsoftware.com/articles/fog0000000069.html) σχετικά με το γιατί είναι κακό να κάνει μια ξαναγράψει, θα παρατηρήσετε σχεδόν καμία από τις περιστάσεις που παραθέτει ισχύουν για εσάς εδώ.

 

1. **Αποκτήστε το υπό έλεγχο αναθεώρηση.**
2. **Αποφασίστε σχετικά με τις συμβάσεις ονομασίας και τη δομή του αρχείου / καταλόγου.**
3. **Βεβαιωθείτε ότι έχετε αξιοπρεπή εργαλεία / IDE.**
4. **Δημιουργήστε ένα ξεχωριστό περιβάλλον ανάπτυξης / δοκιμή, αν δεν το έχετε κάνει ήδη**


ΕΠΕΙΤΑ ...


5. Δυστυχώς, θα πρέπει να κοσκινίσει μέσω όλων αυτών των 1, 2, 3 αρχεία και να καθορίσει ποια από αυτά είναι σε χρήση, και τα οποία μπορούν να διατεθούν. Κανένα άλλο τρόπο εκτός από την ωμή βία αλέσει μέσω, το αρχείο από το αρχείο.
6. Ακόμα κι αν έχω μια RCS στη θέση του, εξακολουθώ να κινούνται συχνά αυτό που νομίζω ότι είναι αχρησιμοποίητα σενάρια σε ένα κρυφό σημείο, λένε .mausoleum και στη συνέχεια να έχουν το RCS αγνοήσει αυτήν την τοποθεσία. Νίκαια για να είναι σε θέση να λάβει μια ματιά σε τοπικό επίπεδο, χωρίς να επανέλθω στο repo.
7. **Ξεχωριστή HTML και PHP στο μεγαλύτερο δυνατό βαθμό** . Δεν μπορώ να το τονίσω αυτό αρκεί! Αν αυτό γίνεται σε κάθε αρχείο, μια χαρά. Ακριβώς εφ 'όσον έχετε ξεχωριστά κομμάτια της PHP και HTML. Φυσικά, HTML θα διανθιστεί με Echos εδώ και εκεί, αλλά να προσπαθήσουμε να έχουμε όλες τις δοκιμές, διακόπτες, ό, τι άλλο κινείται έξω από το μπλοκ HTML και στο μπλοκ PHP. Αυτό από μόνο του μπορεί να είναι *τεράστια* , όταν πρόκειται να πάρει τα πράγματα διευθετηθεί.
8. Εάν ο κωδικός είναι κυρίως διαδικαστικά - υποθέτω ότι στην περίπτωσή σας δεν είναι - είναι μάλλον καλύτερο να κάνετε κάποια καθαρίσει πρώτα, πριν κάνετε οποιαδήποτε σοβαρή refactoring ή refactoring σε κατηγορίες.
9. Όπως μπορείτε να βρείτε τα αρχεία / σενάρια που μπορεί λογικά να συνδυαστούν, να το πράξουν. (Έχω δει έργα - κατά πάσα πιθανότητα δεν σε αντίθεση με τη δική σας - όπου ο συνολικός αριθμός των επιζώντων αρχείων είναι περίπου το 1/4 από αυτό που ξεκίνησε με).


Μόλις περάσει αυτό το μέτρο, τότε μπορείτε να ξεκινήσετε μια σωστή refactoring ή refactoring σε κατηγορίες.


Bonne ευκαιρία!

 

Πολλά χρήσιμα δημοσιεύσεις σχετικά με το πώς να ασχοληθεί με αυτό. 


Χωρίς να προσπαθεί να επαναλάβω αυτά που είπαν όλοι οι άλλοι:


1. Πάρτε ένα αντίγραφο της prod περιβάλλον λειτουργίας. Μπορεί να είναι μια εικονική μηχανή, ή άλλη πραγματική μηχανή. Αλλά θα πρέπει να είναι ο Θεός σε αυτό. Εάν η βάση δεδομένων prod είναι σε ένα άλλο πλαίσιο, θα χρειαστείτε μια έκδοση dev, πάρα πολύ.
2. Πέτα όλα στον έλεγχο έκδοσης. Σε ένα άλλο κουτί. Ένας που υποστηρίζεται τουλάχιστον σε εβδομαδιαία βάση.
3. Βεβαιωθείτε ότι γνωρίζετε πώς διακλάδωση έργων στην εφαρμογή τον έλεγχο έκδοσή σας. Θα χρειαστεί κατά πάσα πιθανότητα.
4. Πάρτε ο διακομιστής prod κλειδωμένος. Δεν θέλετε οποιεσδήποτε περαιτέρω αλλαγές που έγιναν σε αυτό που δεν προέρχονται από τον έλεγχο έκδοσης.
5. Δημιουργήστε οδηγίες για την απελευθέρωση κώδικα από τον έλεγχο έκδοσης στο διακομιστή prod. Η μικρότερη μονάδα απελευθερώσιμης αλλαγή θα πρέπει να είναι ολόκληρη η βάση κώδικα.


Τα επόμενα βήματα εξαρτώνται από τον τρόπο που επισυνάπτονται σε αυτήν οι χρήστες. Αν δεν μπορεί να αλλάξει σε πολύ για οποιοδήποτε λόγο, θα χρειαστείτε μια προοδευτική προσέγγιση. Αν την ανάπτυξη και τη συντήρηση πρέπει ακόμη να συμβεί, τότε αυτό είναι ίσως η μόνη επιλογή σας. Θυμηθείτε να χρησιμοποιήσετε αυτή την διακλάδωση δυνατότητα να διαχωρίσει όπως mods μακριά από τις προσπάθειες ξαναγράψιμο σας.


Για να το θέσουμε νόημα στη δομή, θα πρέπει να δημιουργήσετε ουσιαστικά μια νέα δομή, παράλληλα με ό, τι υπάρχει. Ένα νέο πρόγραμμα χειρισμού DB είναι συνήθως ένα καλό μέρος για να ξεκινήσετε, περιλαμβάνεται από ένα γενικό περιλαμβάνουν αρχείου που κάθε σελίδα θα πρέπει να φορτώσει. Ο στόχος εδώ είναι να δημιουργήσετε μια ελάχιστη περιλαμβάνουν δομή που μπορεί να επεκταθεί αργότερα χωρίς να λέει σε κάθε σελίδα να φορτώσει πρόσθετα αρχεία.


Τώρα θα πρέπει να αρχίσει να κινείται λειτουργικότητα πάνω σε νέα αρχεία περιλαμβάνουν σας. Θα χρειαστείτε έναν τρόπο για να έχουν πολλά αρχεία ανοιχτά ταυτόχρονα, όπως ένα πρόγραμμα επεξεργασίας πολλαπλών αρχείων, ή την οθόνη + vi (ή emacs). Ξεκινήστε με τις λειτουργίες κοινής ωφελείας και τον κωδικό-μπλοκ που επαναλαμβάνονται σε διάφορα μέρη. Προσπαθήστε να μην πάρετε αποσπούν την προσοχή σε καθορισμό πολλά ταυτόχρονα. Μερικά είδη των προβλημάτων που θα πρέπει να κινηθεί ακριβώς θέσεις και να πάρει άλλα προβλήματα σταθερά. Θα επανέλθω σε αυτό αργότερα.


Μην αισθάνεστε ότι χρειάζεστε για να προσθέσετε ένα πλαίσιο από τρίτους. Προσθέτοντας ένα τέτοιο πράγμα γρήγορα οδηγεί σε πλήρη ξαναγράψει. Σε αυτό το σημείο, αυτό θα είναι ένα πάρα πολύ περισσότερη δουλειά από ό, τι ακριβώς εξημέρωση του περιλαμβάνουν τη δομή. Έτσι ταξινομήσετε ότι έξω πρώτα.


Καθώς μετακινείτε λειτουργικότητα πάνω, θα πρέπει να έχετε τα αρχεία χρησιμοποιήσετε το νέο σας περιλαμβάνει το αρχείο. Οι πρώτες αρχεία που κάνει αυτό για σας, θα πρέπει να κυνηγούν συγκρούσεις για λίγο. Θα αισθανθείτε απογοητευτικό και άσκοπη, αλλά αυτό είναι ίσως το πιο δύσκολο κομμάτι. Μετά από μερικά αρχεία, θα γίνει ευκολότερο. Θα υπάρξουν στιγμές που μπορείτε να μεταναστεύσουν μισό-α-ντουζίνα σελίδες για το νέο περιλαμβάνει τα αρχεία, αντικαθιστώντας μια ντουζίνα περιλαμβάνει με ένα μόνο. Η άλλη πλευρά αυτής της δράσης είναι ότι θα υπάρξει αρχεία μπορείτε απλά να διαγράψετε.


Αν θέλετε να παραμείνετε σε αυτό, θα πάρουν τελικά στο σημείο όπου όλα τα αρχεία που περιλαμβάνουν είναι αυτά που έχετε γράψει και θα είστε σε ολόκληρη περιλαμβάνουν διάταξη. Από εκείνο το σημείο, θα είναι πολύ πιο εύκολο να κάνει πολύ πιο επεμβατικές αλλαγές, σαν να βάζουμε σε ένα πλαίσιο από τρίτους.

 

1. Κάντε ένα back-up του κώδικα τώρα.
2. ελέγχου έκδοσης.
3. Δημιουργήστε ένα χώρο δοκιμών. Είναι η ιστοσελίδα λειτουργεί υπό Apache; Μπορείτε ακόμη και να εγκαταστήσετε Apache + PHP + MySQL στον υπολογιστή σας, και να τις χρησιμοποιούν για τη δοκιμή.
4. Ασχολείται με θέματα ασφαλείας. Βεβαιωθείτε ότι η περιοχή προστατεύεται από το SQL ένεση, και από την ένεση ηλεκτρονικού ταχυδρομείου. Τουλάχιστον, μπορείτε να κάνετε μια αναζήτηση για τις κλήσεις βάση δεδομένων και να προσθέσετε κλήσεις σε `mysql_real_escape_string()`(καλά, αν είναι χρησιμοποιώντας μια βάση δεδομένων MySQL) ... μπορείτε να κάνετε μια πραγματική λύση αργότερα μόλις καταλάβετε τον κωδικό καλύτερα. Για την ένεση email ... γράφετε λειτουργία φίλτρου που φιλτράρει τον κωδικό spammer, και βεβαιωθείτε ότι όλα τα πεδία της φόρμας που χρησιμοποιούνται σε ένα μήνυμα ηλεκτρονικού ταχυδρομείου φιλτράρονται. (Ναι, προσθέτει περισσότερα κωδικό μακαρόνια, αλλά πρόκειται να πάρει λίγο χρόνο προτού να είστε έτοιμοι να refactor σημαντικά τον κώδικα.)
5. Μετά από αυτό, προτείνω σταδιακή αναβάθμιση. Είσαι νέος και ο κωδικός είναι higgleypiggley χάος, γι 'αυτό πρόκειται να πάρει λίγο χρόνο για να τα καταλάβουν ... και να κατανοήσουν πλήρως την περιοχή. Έτσι πήγαινε για τη δουλειά σας για λίγο, για τον καθορισμό αυτό πρέπει να καθοριστεί, προσθέτοντας το τι πρέπει να προστεθεί. Όπως μπορείτε να κάνετε έτσι, μαθαίνετε πώς το σύστημα μαζί. Μόλις ξέρετε πώς ο κώδικας είναι οργανωμένη (ή μη οργανωμένη) λίγο καλύτερα, μπορείτε να αρχίσετε να σχεδιάζετε ένα σημαντικό refactoring / αναμόρφωση του συστήματος. Ας ελπίσουμε ότι μπορείτε να το κάνετε συνιστώσα ανά συνιστώσα, ώστε να έχετε πάντα ένα νέο ορόσημο στον ορίζοντα.

 

Ξέρω πώς αισθάνεστε. Έχω κληρονομήσει την ανάπτυξη ενός τέτοιου έργου. Θα μείνει μαζί μου για ένα χρόνο και για να είμαι ειλικρινής μου έκανε ο κύριος του έργου που είμαι σήμερα. Δεν υπάρχει καλύτερη ευκαιρία για προσωπική εξέλιξη από το γόνατο που εργάζονται στο βάθος σκατά.


Εδώ είναι τα πράγματα που με βοήθησαν στα περισσότερα:


* προσδιορίσει ποια είναι τα βασικά αρχεία του συστήματος. Θα τους βρείτε γιατί το μεγαλύτερο μέρος της εργασίας σας θα πρέπει να γίνει σε αυτές
* δημιουργήσετε μια τοπική έκδοση του έργου (συμπεριλαμβανομένης της βάσης δεδομένων) και το βάζουμε κάτω από τον έλεγχο έκδοσης
* λειτουργούν μόνο σε ένα μικρό ποσό των αρχείων με μικρές αλλαγές
* δεν βάζουν τίποτα στο εσωτερικό του έκδοση παραγωγής έως ότου έχετε δοκιμάσει καλά, και στη συνέχεια να είναι έτοιμος να βάλει την παλιά έκδοση πίσω
* μάθετε πώς οι χρήστες του συστήματος χειρισμός (συνεδρίες, μπισκότα). Δημιουργήστε μια υπερ-χρήστη και στη συνέχεια, όταν θα πρέπει να ελέγξετε τον κωδικό σας ζωντανά από το σύστημα το βάζουμε σε ένα μπλοκ σαν αυτό:



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

```

άλλοι χρήστες δεν θα είναι σε θέση να αισθάνονται τις αλλαγές. Η τεχνική αυτή με βοήθησε πολύ όταν ήμουν σε θέση να αντικαταστήσει την κατάσταση του συστήματος στον τοπικό υπολογιστή μου
* γράφουν τεστ, και ακολουθούν αυστηρές κατευθυντήριες γραμμές της μηχανικής για όλους τον κώδικα που γράφετε

 

Αυτό είναι πράγματι ένα χάος. Αλλά αρχίσετε να πάρει δημιουργική για το πού να κόψει μερικά από τα πλοκάμια σε αυτό το πράγμα:


1. Πάρτε τον έλεγχο έκδοσης. Θα ήθελα να συστήσω Git.
2. Ρύθμιση ενός server τοπικής ανάπτυξης. Βρείτε ένα WAMP, LAMP ή mAmp πακέτο για να ξεκινήσετε από τη στιγμή που είστε νέοι σε αυτό.
3. Βρείτε τα σημεία εισόδου (index.php, κλπ). Ελέγξτε τα αρχεία καταγραφής πρόσβασης του διακομιστή σας για να δείτε τι είναι αυτά.
4. Ανασκουμπωθούμε σας σε κάποια κανονική έκφραση μαύρη μαγεία και χωματερή έξω ένα περιλαμβάνουν / απαιτούν δέντρο σε όλα τα αρχεία. Αλλά προσέξτε οποιαδήποτε περιλαμβάνουν ($ filename) δυναμικές περιλαμβάνει. Αν έχετε κάποιο από αυτά θα χρειαστεί να κάνετε κάποια καταγραφή για $ όνομα αρχείου για να μάθετε τι ενδεχομένως παίρνει περιλαμβάνονται, αν και ο κώδικας γύρω από αυτό θα πρέπει να σας δώσει ενδείξεις. Με λίγη τύχη μπορείτε να θανατώσουν όλα τα αχρησιμοποίητα αρχεία σας με αυτό τον τρόπο.
5. Χρησιμοποιήστε πιο regex μαύρη μαγεία για να ελέγχουν οι λειτουργίες και οι μέθοδοι που αναφέρονται σε άλλα σημεία του βάση κώδικα. Μπορεί να υπάρχει ένα IDE που μπορεί να σας βοηθήσει με αυτό. Δοκιμάστε το NetBeans (Θα χρησιμοποιηθεί για να με βοηθήσει να refactor ένα πρόγραμμα C ++ μια φορά, γι 'αυτό μπορεί να βοηθήσει εδώ.)
6. Όπως κάποιος άλλος απάντησε, «μάθετε, αν είναι απαραίτητο, εάν ορισμένες κατηγορίες χρησιμοποιούνται και κάποιες άλλες δεν είναι, μπορείτε να χρησιμοποιήσετε get\_declared\_classes σε συνδυασμό με get\_defined\_vars και gettype για να δείτε ποιοι τύποι που τεκμηριώθηκε.» Θα μπορούσατε επίσης να γράψετε κάποιο κώδικα για να βρείτε όλα τα νέα δηλώσεις στον κώδικα βάσης.
7. Και ούτω καθεξής ... απλά σκεφτείτε για το πώς μπορείτε να περιοριστούν αυτό το τέρας κάτω. Και να προσπαθήσουμε να αναδιοργανώσει κώδικας όπου μπορείτε.

 

Εδώ είναι μερικές ιδέες:


* PHP και Apache δουλεύουν μια χαρά στα Windows πάρα πολύ. Ίσως μπορείτε να κάνετε μια εγκατάσταση όλων των Windows μετά από όλα;
* Προσπαθήστε `grep`«σης (ή κάποια εναλλακτική λύση των Windows) για“περιλαμβάνουν”και“απαιτούν”σε όλα τα αρχεία PHP. Στη συνέχεια, κάνει μια λίστα με όλα τα αρχεία που συμπεριλαμβάνονται βρέθηκε. Συγκρίνετε τη λίστα με τα αρχεία του φακέλου. Θα πρέπει να είναι σε θέση να απαλλαγούμε από τουλάχιστον κάποια unreferenced αρχεία.
* Εναλλακτικά, κάνει μια λίστα με όλα τα ονόματα των αρχείων και να αναζητήσετε όλα τα αρχεία τους. Θα μπορούσατε να κάνετε κάτι σαν ένα γράφημα εξάρτηση σαν αυτό.

 

Νομίζω ότι και τα 5 σημεία σας χτυπήσει σε κάποια κλασικά έργα ASP έχω κληρονομήσει, και ένα PHP μία πάρα πολύ ...


Συμφωνώ απολύτως με τους άλλους για να πάρει τον έλεγχο πηγή ASAP και να χρησιμοποιήσετε VMWare, το VirtualBox, κλπ για ένα περιβάλλον δοκιμής.


Σιγουρευτείτε για να πάρετε τη βάση δεδομένων σας εκδόσεων πάρα πολύ, ειδικά εάν οι διαδικασίες έχουν επιπλέον λογική μέσα τους (και όχι μόνο ευθεία εισαγωγή, ενημέρωση, διαγραφή). DB εκδόσεων χρειάζεται περισσότερη προσοχή στη συνέχεια τις σελίδες php. Θα πρέπει να δημιουργήσει όλα τα αντικείμενα σε SQL scripts και να θέσει αυτά τα σενάρια σε έλεγχο πηγή. Στη συνέχεια, όπως μπορείτε να αλλάξετε τη δομή db, διαδικασίες, κλπ θα πρέπει να ενημερώσετε τα σενάρια, έτσι ώστε να έχουν μια ιστορία αυτών των αλλαγών πάρα πολύ.


Όσο για υπολογισμό τι χρησιμοποιεί ό, τι στην πλευρά της βάσης δεδομένων θα πρότεινα κοιτάζοντας [ApexSQL Καθαριότητα](http://www.apexsql.com/sql_tools_clean.asp) . Θα χρησιμοποιηθεί αυτό για ένα έργο με αρκετές εκατοντάδες αρχεία ASP, 200 + πίνακες και περίπου 400 αποθηκευμένες διαδικασίες. Ήμουν σε θέση να προσδιορίσει 20 περίπου πίνακες που δεν ήταν σε χρήση και περίπου το 25% των αποθηκευμένων διαδικασιών. Με ApexSQL Καθαριότητα μπορείτε να προσθέσετε όλα τα αρχεία php σας στο check εξάρτηση μαζί με τους πίνακες, τις απόψεις και τις αποθηκευμένες procs. Αρπάξτε την δοκιμή 30 ημερών και να δεις, θα σας εξοικονομήσει πολύ χρόνο.


Για ποια αρχεία ήταν σε χρήση για την ιστοσελίδα, είχα αρχεία καταγραφής διακομιστή ιστού για τον προηγούμενο μήνα και έτρεξε αναζητήσεις εναντίον τους για οτιδήποτε ήμουν σίγουρος για. Κάνω επίσης, σαν μια παραλλαγή σε ό, τι Aistina πρότεινε σχετικά με την τροποποίηση των αρχείων για να συνδεθείτε όταν η πρόσβαση. Ίσως πρέπει να πάει σε έναν πίνακα στη βάση δεδομένων σας εγκατάστασης που είναι όνομα και η πρόσβαση μετράνε και κάθε φορά που το αρχείο φορτώνεται αυτό αυξάνει την καταμέτρηση. Στη συνέχεια, μετά από ένα χρονικό διάστημα, μπορείτε να κοιτάξουν πέρα ​​από τις μετρήσεις και να κρίνει τι μπορεί να πάει.

 

Πρώτο βήμα, φυσικά, θα ήταν να τεθεί υπό έλεγχο έκδοσης. Με αυτό τον τρόπο, τουλάχιστον μπορείτε να πάτε πίσω στην αρχική έκδοση εργασίας. Δεύτερον θα μπορούσε να είναι μια καλή ιδέα να αντικαταστήσετε τα περιλαμβάνουν, απαιτούν, κλπ λειτουργίες, για παράδειγμα, γράψτε το όνομα του αρχείου που είναι να συμπεριληφθούν σε κάποιο αρχείο καταγραφής, με αυτόν τον τρόπο μπορείτε να μάθετε τα οποία πράγματι περιλαμβάνονται αρχεία (έτσι ελπίζουμε αποκλείοντας ένα μεγάλο μέρος της index2.php, index3.php, κ.λπ.


Για να μάθετε, αν είναι απαραίτητο, εάν ορισμένες κατηγορίες χρησιμοποιούνται και κάποιες άλλες δεν είναι, μπορείτε να χρησιμοποιήσετε get\_declared\_classes σε συνδυασμό με get\_defined\_vars και gettype για να δείτε ποιοι τύποι που τεκμηριώθηκε.


Όσον αφορά το θέμα 4 και 5, αυτά είναι ίσως λίγο πιο δύσκολο να επιλυθούν, αλλά αυτό θα πρέπει να ξεκινήσετε ελπίζουμε.

 

Θα πρέπει σίγουρα ένα περιβάλλον ανάπτυξης. Εάν δεν θέλετε να το χάος με τη λειτουργία του site στα παράθυρα κουτί σας, θα μπορούσατε να πάρετε ένα VMWare εικόνα κάποιου διανομή Linux. 

 

Το πρώτο πράγμα που θα κάνουμε είναι να δημιουργήσει ένα περιβάλλον δοκιμής χρησιμοποιώντας μια εικονική μηχανή κάποιου είδους. VirtualBox ή το Virtual PC θα ήταν μια χαρά επιλογές. Με αυτόν τον τρόπο μπορείτε να αρχίσουμε να αλλάζουμε τα πράγματα χωρίς φόβο να σπάσει το περιβάλλον παραγωγής. Δεν έχει σημασία πόσο πολύ δουλειά αυτό φαίνεται σαν να είναι (με το διακομιστή της βάσης δεδομένων και web και τα πάντα), στο τέλος θα αξίζει τον κόπο. Ένα από τα μεγάλα οφέλη είναι ότι μπορείτε να αντιγράψετε το VM και να της δώσει σε κάποιον άλλο, αν βρείτε χρειάζεστε βοήθεια.

 

1. αρχίσετε να χρησιμοποιείτε τον έλεγχο έκδοση του έργου (Θα ήθελα να συστήσω git)
2. γράφετε εξετάσεις μονάδα για όλες τις κώδικα
3. αρχίσετε να χρησιμοποιείτε ORM (εγώ συνιστούμε δόγμα)
4. αρχίσετε να χρησιμοποιείτε κάποιο πλαίσιο (Θα ήθελα να συστήσω symfony / nette)
5. ξεκινήστε refactoring κώδικα php

 

Ναι, Έλεγχος έκδοσης είναι σίγουρα το βήμα # 0.


Θα ήθελα επίσης να συστήσει ένα καλό **εργαλείο αναζήτησης κώδικα** .


*Agent διερευνώ* είναι πολύ καλή (με την προϋπόθεση είστε σε παράθυρα)
 <http://www.mythicsoft.com/agentransack/Page.aspx?page=download>


Θα ήθελα να πετούν τυφλά, χωρίς αναζήτησης κώδικα.

 

Έχω *μόλις* πέρασε από αυτό ο ίδιος.


Μου νούμερο ένα tip είναι να μην προσπαθήσουμε και να αλλάξει τα πάντα σε μία ημέρα. Χρειάζεται φίλοι, αν θέλετε πραγματικά να είναι σε θέση να διορθώσετε αυτό το πράγμα. Χρειάζεται συναδέλφους σχέση σας προτού να προτείνουν πώς να αλλάξετε όλα αυτά που έχουν εργαστεί για μήνες (χρόνια;).


Κατ 'αρχάς, να πάρετε τον κώδικα υπό έλεγχο την έκδοση το συντομότερο δυνατό. Αν αυτό δεν πρόκειται να είναι εύκολο για σας, τουλάχιστον να αρχίσουμε να κάνουμε καθημερινά αντίγραφα ασφαλείας, ακόμα και αν αυτό σημαίνει απλά ξέρετε, τρέχοντας τα αρχεία και ονομάζοντας το αρχείο zip με την ημερομηνία. Αν κανείς δεν ξέρει υπάρχουν σχετικά με τον έλεγχο έκδοσης, αγοράστε το βιβλίο μια ρεαλιστική προγραμματιστή σε CVS ή SVN, και το έστησαν τον εαυτό σας. Τα βιβλία μπορούν να διαβαστούν σε μια μέρα, και μπορείτε να οργανωθεί και να λειτουργήσει γρήγορα. Αν κανείς άλλος δεν θέλει να χρησιμοποιήσει τον έλεγχο έκδοσης, μπορείτε να το χρησιμοποιήσετε για τον εαυτό σας ... στη συνέχεια, όταν κάποιος χάνει ένα αρχείο που μπορεί να σώσει την ημέρα με ένα αντίγραφο από το repo σας. Αργά ή γρήγορα οι άλλοι θα δουν τη σοφία που είναι έλεγχος έκδοσης.


Δεύτερον, βουτήξει στον κώδικα τόσο σκληρά όσο μπορείτε ενδεχομένως. Ζήστε το και αναπνέουν για ένα μήνα. Δείτε τους ανθρώπους που είναι εκεί ότι θα έχετε την ευκαιρία να μάθετε τον κωδικό τους.


Τρίτον, καθώς περνάτε από τον κώδικα, να λάβει άφθονες σημειώσεις. Γράψτε κάτω κάθε πράγμα που σας ενοχλεί σχετικά με τον κώδικα. Μόλις πάρετε τις σκέψεις σας σε χαρτί. Μπορείτε να οργανώσετε αργότερα, μετά το Μήνα One.


Τέταρτον, την εγκατάσταση ενός κώδικα profiler (όπως xdebug). Αυτό θα σας πω ποια αρχεία και οι λειτουργίες που καλούνται σε κάθε σελίδα, και πόσο καιρό το κάθε κομμάτι του κώδικα χρειάζεται για να τρέξει. Μπορείτε να χρησιμοποιήσετε αυτό για να καταλάβω σας περιλαμβάνει θέματα, και να βρούμε αργά κομμάτια του κώδικα. Βελτιστοποιήστε εκείνες πρώτη.


Μετά το μήνα σας σκληρή δουλειά, κοσκίνισμα μέσα από τον κώδικα, και σημειώσεις, γυρίστε τις σημειώσεις σας σε ένα κατάλληλο έγγραφο. Τα διάφορα τμήματα μπορεί να κυμαίνεται από την ασφάλεια, για την προσωρινή αποθήκευση, την αρχιτεκτονική, σε ό, τι άλλο σας ενοχλεί. Για κάθε κριτική που κάνετε, προσφέρουν μια καλύτερη λύση, και μια εκτίμηση για το πόσο καιρό θα πάρει για να διορθώσετε. Αυτό είναι όπου μπορείτε να απαλλαγείτε από όλα τα ανταγωνιστικά javascript πλαισίων κ.λπ.


**Τροποποιήσει το παρόν έγγραφο όσο το δυνατόν περισσότερο.** 
Δεν μπορώ να τονίσω ότι αρκετά.


Βεβαιωθείτε ότι το κοινό σας μπορεί να πει το κάνετε για το καλό της εταιρείας, όχι μόνο τις προσωπικές σας προτιμήσεις.


Παρουσιάστε να το αφεντικό σας, στο πρόσωπο. Set-up ένα χρόνο για να το συζητήσουμε.


Θα μπορούσαν να σας φωτιά για να έχει γράψει. Αν το κάνουν, είστε σε καλύτερη θέση χωρίς αυτούς, επειδή δεν θέλουν να βελτιώσουν και την καριέρα σας θα παραμείνει στάσιμη.


Μπορεί να θέλουν να εφαρμόσουν όλες τις συστάσεις σας. Δεν είναι πιθανό, αλλά είναι δυνατόν. Στη συνέχεια θα ήθελα να είναι ευτυχισμένος (εκτός προτάσεις σας αποτύχει).


Το πιο πιθανό είναι ότι θα θέλουν να εφαρμόσουν μερικές από τις συστάσεις σας, και αυτό είναι καλύτερο από το τίποτα. Τουλάχιστον, αυτό θα βοηθήσει να διευκολύνει τις ανησυχίες σας.


Όσο για τον έλεγχο, τη ρύθμιση άλλο «εικονική υποδοχής» στο Apache (υποστηρίζεται στα Windows και Linux). Virtual Hosts σας επιτρέπει να εκτελέσετε πολλές ιστοσελίδες σε ένα διακομιστή. Οι περισσότεροι μεγαλύτερα sites έχουν τουλάχιστον 3 virtual hosts (ή πραγματική servers): dev.domain.com (για την καθημερινή ανάπτυξη), staging.domain.com (για QA τους ανθρώπους να κάνουν δοκιμές σε λίγο πριν από την απελευθέρωση), και www.domain. com (server παραγωγής σας). Θα πρέπει επίσης να dev εγκατάστασης, στάσης, και η παραγωγή εκδόσεων της βάσης δεδομένων, με διαφορετικά στοιχεία και κωδικούς πρόσβασης, έτσι ώστε να μην κατά λάθος τους μπερδέψει.


Μια εναλλακτική λύση θα ήταν να δοθεί σε κάθε προγραμματιστή δική τους εικονική υποδοχής στο διακομιστή Linux, και μπορούν να εργαστούν μέσω FTP / SCP ή το δίκτυο χρησιμοποιώντας σάμπα.


Καλή τύχη!

 

Εκτός από την καλή δουλειά άλλοι άνθρωποι έχουν πει, να πάρει ένα πρώτο πέρασμα σε ποια αρχεία που χρησιμοποιούνται ενεργά, μπορείτε να εγκαταστήσετε μια προσωρινή μνήμη opcode όπως APC ή eaccelerator στον server dev σας (ή ακόμα και ένα διακομιστή παραγωγής, αυτό δεν θα σπάσει Οτιδήποτε). Στη συνέχεια, κάντε κλικ στην επιλογή γύρω από το web εφαρμογή στον server dev σας (ή αφήστε τους χρήστες να κάνουν στον server της παραγωγής σας).


Τώρα κοιτάξτε τη λίστα των προσωρινά αποθηκευμένων αρχείων σε σελίδα μνήμη cache διαχειριστή σας. Εάν ένα αρχείο δεν είναι καταχωρημένη ως αποθηκευτεί προσωρινά από την προσωρινή μνήμη opcode σας, υπάρχει μια καλή πιθανότητα να μην φορτώνεται από το τίποτα.


Αυτό δεν είναι μια ολόκληρη λύση, αλλά αν κάθε κατάλογος έχει 10 αρχεία index.php (π.χ. index.php, index2.php, κλπ), τουλάχιστον θα ξέρετε ποιο είναι αυτό που χρησιμοποιείται από την εφαρμογή σας.

 

Κάνε ό, τι είπε ο Χάρπερ Shelby ... 


Αλλά, θα ήθελα επίσης να προσθέσω ότι, αν δεν έχετε την υποστήριξη της διαχείρισης για να καθαρίσει αυτό επάνω, μπορεί να θέλετε να αποδεχθεί το γεγονός ότι αυτό μπορεί να είναι σαν αυτό για έναν λόγο. ... απλά λέω. ;-)

 

Προσπαθήστε να πάρετε λεπτομερή στατιστικά σχετικά με την ιστοσελίδα και να μάθετε όπου τα σημεία εισόδου και εξόδου είναι. Ένα αξιοπρεπές τρόπος για να μάθετε ποια αρχεία έχουν πληγεί από την κορυφή (και στη συνέχεια να εξετάσουμε αυτά τα αρχεία για να δείτε που περιλαμβάνει τα τραβιέται).

 