Hérité d'un cauchemar PHP, par où commencer?

Question

J'ai hérité d'un projet PHP qui est en train de devenir un cauchemar. Voici les points saillants:

1. L'original de tous les développeurs ont laissé
2. Le code n'a pas de contrôle de version
3. Tout le développement et le test a été effectué sur le serveur live par le fait de renommer et éditer les fichiers PHP. Il existe plusieurs copies de chaque fichier index.php, index2.php, index3.php etc. et il est difficile de savoir quels fichiers sont réellement utilisé
4. Il existe de multiples comprend dans chaque fichier pour les fichiers à inclure d'autres fichiers qui incluent d'autres fichiers, etc.
5. Il y a eu plusieurs développeurs sur le projet, qui avaient chacun leur propre façon de faire les choses. Par exemple, il y a un méli-mélo de frameworks JavaScript, certaines requêtes de base de données utilisation de SQL, d'autres une interface XML et d'autres appellent des fonctions de procédure dans la base de données.

En raison de tous ces problèmes, le développement est d'une lenteur décourageante. En plus de la ventilation de mes frustrations à Débordement de Pile, des recommandations sur la façon d'obtenir commencé sur ce gâchis? Je suis assez nouveau développement en PHP moi-même, mais il semble que mettre en place une sorte d'environnement de développement afin que les modifications puissent être testés sans rompre le serveur live est la première étape. Des conseils sur la façon d'obtenir commencé ici? Qu'est-ce que d'une manière typique pour faire des tests? La configuration d'une version locale du site sur mon bureau ressemble à beaucoup de travail (serveur est sous Linux, mais les ordinateurs de bureau, ici, sont des Fenêtres). Puis-je créer un sous-répertoire sur le serveur de test, ou..? Ce sur la base de données?

Deuxièmement, est-il une sorte de profilage je peux permettre de suivre les fichiers sur le serveur sont vraiment utilisés? Je voudrais supprimer la renommée des copies des choses qui ne sont pas réellement compris. Encore mieux, est-il un moyen de dire quelle est la partie d'un fichier ne sont pas exécutés? Il y a beaucoup de copié les fonctions et les déchets dans le, que je soupçonne de ne pas être utilisés soit. De même, pour les includes, les conseils sur la redresser le désordre?

Eh bien, je vais arrêter de ventilation ici et de me jeter à la merci de tout le monde ici. :)

Answer 1

1. Avant tout, obtenez les fichiers dans le contrôle de version tels quels. Ne continuez pas au-delà de n ° 1 jusqu'à ce que ce soit fait.
2. Établir un environnement de test.
3. Nettoyer les fichiers

Answer 2

Je l'ai fait. Vous avez toute ma sympathie. Si votre passeport n'est pas courant ou pour une autre raison, vous ne pouvez pas esquiver en faisant cela, voici comment j'allais l'aborder:

L'étape Zéro est d'obtenir dans le contrôle de version, peu importe comment la merde qu'il est. Si ce même type de travaux, et vous cassez quelque chose, vous devez être en mesure de revenir à l'état de fonctionnement ou au moins, de comparer vos modifications pour comprendre ce qui s'est passé. De fréquentes, petit check-ins que vous êtes refactoring, et vous aurez moins de code à faire reculer quand les choses mystérieusement aller mal. (Les choses VONT mystérieusement aller mal.)

Après cela, j'aimerais commencer par la base de données. Assurez-vous que tout est relativement bien normalisé, les colonnes sont clairement nommés, etc.

Faire le code PHP suivant. Si le code est vraiment que beaucoup de patchwork, j'irais de l'avant et de l'adapter à un cadre. Regarder dans CakePHP ou Symfony - leurs Rails-ish manière de séparer les préoccupations rend la question "où ce morceau de code?" facile à répondre. Ce n'est pas une mince tâche, mais une fois que vous l'avez fait, vous êtes probablement mieux que la moitié à avoir un sainement construit app. En outre, le haut-dans les installations d'essai d'un bon framework web faire du refactoring BEAUCOUP plus facile d'écrire un test de recouvrir une pièce de fonctionnalité avant de la changer, et vous saurez si vous avez cassé quoi que ce soit après le changement.

Une fois que vous avez votre base de données triées et le modèle de code dans les modèles et le code du contrôleur dans les contrôleurs, alors vous pouvez vous soucier de la présentation des choses comme la standardisation sur un seul JS/AJAX library, nettoyage CSS, etc.

Comme pour un environnement de dev: Vous devez absolument installer un local environnement de dev. Il y a des clés en main WAMP paquets, ou vous pouvez installer un Linux/VM (je recommande de VirtualBox pour la virtualisation). Vous devez également avoir un test d'intégration de l'environnement qui imite le serveur live. Rien de mais live code doit s'exécuter sur le serveur live.

Aussi loin que debug/outils de profilage, je sais que Symfony est livré avec une jolie nappe ensemble d'outils, y compris un peu de JS barre d'outils qui apparaît sur vos pages (uniquement en mode debug) avec connexion et les informations de profilage.

Bonne chance.

Answer 3

Eh bien, tout d'abord. J'ai été dans la situation où vous êtes, et elle le suce. Je pense que vous êtes sur la bonne voie en voulant obtenir un environnement de développement et en cours d'exécution.

Environnement de développement

Cela comprendra un Serveur web / script moteur / moteur de base de données de la pile, et une IDE plus probable.

Pour une LAMPE à pile programme d'installation, je vous recommande d'utiliser l'un de ces:

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

En savoir plus sur la pile LAMP:

O'Reilly OnLamp site

Pour une bonne IDE PHP, je recommande d'utiliser l'un de ces:

• Zend Studio
• ActiveState Komodo
• Jetbrains PhpStorm

Article sur IBM de Développeur de site de comparaison de plusieurs IDE

Pour le contrôle de code Source, vous pouvez utiliser Team Foundation Server, SVN ou Git -- suffit d'utiliser quelque chose que vous savez. Je recommande de tout contrôle de code source (pour tout urgence en entretien que vous pourriez avoir), mais ensuite prévoyez de faire une grosse révision.

La Refonte

Vous avez mentionné que vous ne saviez même pas quels fichiers sont utilisés, et qu'ils ont utilisé une convention de nommage de fichier comme un pseudo-contrôle de version. Vous voudrez peut-être commencer la refonte de là, une fois que vous avez un environnement de développement et en cours d'exécution. Il y a quelques choses qui peuvent vous aider:

• Votre application clients/utilisateurs
• Méticuleux et organisé la prise de note
• Une bonne structure de journalisation

Vos clients/utilisateurs sont importants, car il semble que vous êtes nouveau sur le projet et qu'ils savent comment l'application doit se comportent mieux que vous (le plus probable).

Méticuleux de la prise de notes est important, parce que vous allez être essentiellement ré-écriture exigences / design / fin-documentation de l'utilisateur à partir du sol. Vous avez besoin de comprendre le fonctionnement interne si vous allez faire. Et si l'on veut comprendre quelque chose à propos de ce système, vous aurez besoin de l'écrire vous-même (ou si vous voulez être parcourant premade documentation de l'instant, au lieu de la lecture d'un Débordement de Pile) ;-)

Et enfin, une journalisation est important parce que vous avez besoin pour arranger les choses, et vous ne pouvez pas réparer les choses que vous ne connaissez pas sont cassés. Une journalisation vous donne de la visibilité dans les parties de l'application qui n'ont pas du tout évident de l'INTERFACE utilisateur. En l'insérant dans différentes parties de l'application et puis en regardant les logs vous donne une bonne idée de quand le code est en cours d'exécution et dans quel ordre.

Vous aurez envie de se concentrer sur la capture (sur le papier) la façon dont l'application devrait fonctionner, et puis, lentement, en supprimant les fichiers inutiles, tout en essayant de ne pas casser quoi que ce soit. Gardez un œil sur les journaux pour faciliter le débogage. Assurez-vous que vos clients ne sont pas en hurlant que quelque chose est cassé. Assurez-vous que vos notes d'accord avec ce qui est arriver connecté et ce que vos clients disent.

La prévention de ce problème à l'avenir

Tout revérifier en arrière dans le contrôle de source. Nous espérons que vous serez arrivés à un plus nouveau, plus sain, une meilleure structure de répertoire par ce point.

Obtenir un test de la structure en place. Même si cela signifie l'obtention d'une unité de base du framework de test en place et faire de base des tests de fumée après chaque déploiement, c'est mieux que rien. Idéalement, vous devriez avoir un test d'un ingénieur ou d'un compétent et digne de confiance de la clientèle qui peut passer du temps à tester après chaque déploiement.

Mettez un processus de déploiement en place si vous poussent à plus d'un développeur. Le contrôle de changement à votre environnement de production devrait être votre première priorité. (La dernière chose que vous voulez faire est d'aller à travers ce nouveau, non?) Vous devriez avoir une idée claire et simple processus de déplacement entre l'environnement des limites (comme Dev -> Test Test -> Production).

Answer 4

La plupart du temps, vous pouvez savoir si un fichier est utilisé à l'aide de grep.

 grep -r "index2.php" *
 

Vous pouvez également utiliser l'analyseur PHP pour vous aider à nettoyer. Voici un exemple de script qui imprime les fonctions déclarées et les appels de fonction:

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

Answer 5

1. Configurer un serveur de développement (comme Greg Hewgill mentionné, VirtualBox et Virtual PC sont de bons choix pour c').

2. Mettre le site actuel fichiers (y compris le serveur web pertinent et la configuration de PHP!) en le contrôle de version.

3. Trouver quels fichiers sont utilisés - utilisation de votre serveur de développement le programme d'installation pour test en supprimant tous les fooN.php les fichiers et voir si elle fonctionne encore.

4. Prier...beaucoup (OK, ce n'est pas nécessaire, mais il semble que vous aurez besoin).