Herdou um pesadelo PHP, por onde começar?

votos
40

Eu herdei um projeto PHP que está a transformar-se num pesadelo. Aqui estão os pontos mais importantes:

  1. Todos os desenvolvedores originais não deixaram
  2. O código não tem controle de versão
  3. Todo o desenvolvimento e teste foi feito no servidor ao vivo, renomeando e editar os arquivos PHP. Existem várias cópias de cada index.php arquivo, index2.php, index3.php etc. e não está claro quais arquivos estão realmente sendo usado
  4. Existem múltiplos inclui em cada arquivo para arquivos que incluem outros arquivos que incluem outros arquivos, etc.
  5. Tem havido vários desenvolvedores do projeto que cada um tinha lá própria maneira de fazer as coisas. Por exemplo, há uma miscelânea de frameworks JavaScript, algumas consultas de banco de dados usar SQL, outros uma interface XML e outros chamam funções processuais no banco de dados.

Por causa de todos esses problemas, o desenvolvimento é frustrantemente lenta. Além ventilação minhas frustrações ao estouro de pilha, quaisquer recomendações sobre como começar a fazer essa bagunça? Eu sou bastante novo para o desenvolvimento PHP mim mesmo, mas parece que a criação de algum tipo de ambiente de desenvolvimento para que as alterações podem ser testadas sem quebrar o servidor ao vivo é o primeiro passo. Todas as dicas sobre como começar aqui? O que é uma maneira comum de fazer o teste? A criação de uma versão local do site no meu desktop parece um monte de trabalho (servidor é Linux, mas desktops aqui estão Windows). Posso criar um subdiretório no servidor ao vivo para o teste, ou ..? E sobre o banco de dados?

Em segundo lugar, existe algum tipo de profiling posso habilitar para acompanhar quais arquivos no servidor estão realmente sendo usado? Eu gostaria de excluir as cópias renomeados de coisas que não estão realmente sendo incluídos. Mesmo melhor, há uma maneira de dizer que partes de um arquivo não estão sendo executados? Há muitas funções copiados e lixo em que eu suspeito que não estão sendo usados ​​também. Da mesma forma, para o inclui, alguma dica sobre endireitar a bagunça?

Bem, eu vou parar de ventilação aqui e me jogar à mercê de todos aqui. :)

Publicado 09/12/2008 em 19:48
fonte usuário
Em outras línguas...                            


27 respostas

votos
56
  1. Antes de tudo, obter os arquivos no controle de versão como é. Não prossiga passado nº 1 até que seja feito.
  2. Estabelecer um ambiente de teste.
  3. Limpar os arquivos
Respondeu 09/12/2008 em 19:58
fonte usuário

votos
30

Eu fiz isso. Você tem a minha simpatia. Se o seu passaporte não é atual ou por algum outro motivo você não pode evitar fazer isso, aqui está como eu iria abordá-lo:

Passo Zero é colocá-lo no controle de versão, não importa o quão horrível é. Se mesmo tipo de funciona, e você quebrar alguma coisa, você precisa ser capaz de voltar para o estado de trabalho - ou pelo menos comparar as alterações a ele para descobrir o que deu errado. Fazer frequentes, pequenas check-ins como você está refatoração, e você terá menos código para reverter quando as coisas misteriosamente dar errado. (As coisas vão misteriosamente dar errado.)

Depois disso, eu ia começar no banco de dados. Certifique-se de que tudo está relativamente bem normalizada, as colunas são claramente nomeada, etc.

Fazer o código PHP seguinte. Se o código é realmente muito de uma colcha de retalhos, eu iria em frente e ajustá-lo para um quadro. Olhe para CakePHP ou Symfony - sua maneira Rails-ish de preocupações que separam faz a pergunta "onde deveria este pedaço de código ir?" fácil de responder. Não é uma tarefa pequena, mas uma vez que você fez isso, você é provavelmente melhor do que a metade para ter um aplicativo sanely-construído. Além disso, o built-in instalações de teste de um bom framework web fazem refatoração muito mais fácil - escrever um teste para cobrir uma parte existente de funcionalidade antes de mudá-lo, e você vai saber se você quebrou qualquer coisa após a mudança.

Assim que tiver o seu banco de dados ordenados e ter o código do modelo nos modelos eo código do controlador nos controladores, então você pode se preocupar com coisas no nível da apresentação como a padronização de uma única biblioteca JS / AJAX, limpando CSS, etc.

Quanto a um ambiente de dev: Você deve absolutamente configurar um ambiente de dev local. Há pacotes WAMP turnkey lá fora, ou você pode instalar em uma caixa de Linux / VM (eu recomendo VirtualBox para virtualização). Você também deve ter um ambiente de teste de integração separado que imita o servidor ao vivo. Nada além de código ao vivo deve ser executado no servidor ao vivo.

Tanto como ferramentas de depuração / perfis, eu sei que Symfony vem com um conjunto muito escorregadio de ferramentas, incluindo uma pequena barra de ferramentas JS que surge em suas páginas (somente no modo de depuração) com o registro e informações de perfil.

Boa sorte.

Respondeu 09/12/2008 em 20:25
fonte usuário

votos
17

Bem, as primeiras coisas primeiro. Eu estive na situação em que está, e isso é um saco. Eu acho que você está no caminho certo em querer obter um ambiente de desenvolvimento instalado e funcionando.

Ambiente de desenvolvimento

Isso irá incluir uma pilha de motor / motor de banco de dados Webserver / script, e um IDE mais provável.

Para um LAMP instalador pilha , eu recomendo usar um destes:

Além disso leitura na pilha LAMP:

local OnLamp da O'Reilly

Para uma boa IDE PHP , eu recomendo usar um destes:

Artigo sobre desenvolvedor site da IBM comparando vários IDE

Para control Fonte , você pode usar Team Foundation Server, SVN, ou Git - basta usar algo que você sabe. Eu recomendaria tudo no controle de origem primeira (para qualquer manutenção de emergência que possa ter), mas, em seguida, planeja fazer um muito grande revisão.

o Overhaul

Você mencionou que você nem sabia quais arquivos estão sendo usados, e que eles usaram um arquivo convenção de nomenclatura como um pseudo-version-control. Você pode querer começar a reformar lá, uma vez que você tem um ambiente de desenvolvimento instalado e funcionando. Existem algumas coisas que podem ajudá-lo:

  • Seus clientes app / usuários
  • tomar notas meticuloso e organizado
  • A estrutura de log boa

Os clientes / utilizadores são importantes , porque parece que você é novo para o projeto e eles vão saber como o aplicativo deve se comportar melhor do que você (provavelmente).

Meticuloso anotações é importante , porque você vai ser essencialmente re-escrever qualquer documentação de requisitos / design / usuário final a partir do zero. Você precisa entender os internos se você estiver indo para fazer isso. E se você vai entender nada sobre este sistema, você precisa anotá-la a si mesmo (ou você estaria lendo documentação premade agora em vez de ler Stack Overflow) ;-)

E, finalmente, uma estrutura de log é importante porque você precisa para consertar as coisas, e você não pode consertar as coisas que você não conhece estão quebrados. A estrutura de log dá-lhe visibilidade em partes do aplicativo que não têm qualquer UI óbvio. Inserindo-o em várias partes do aplicativo e, em seguida, olhando para os logs lhe dá uma boa idéia de quando o código está em execução e em que ordem.

Você vai querer se concentrar em capturar (no papel) como o aplicativo deve funcionar, e, em seguida, lentamente removendo arquivos desnecessários ao tentar não quebrar nada. Fique de olho no logs para ajudar com a depuração. Certifique-se de seus clientes não estão gritando que algo está quebrado. Certifique-se de suas notas de acordo com o que está sendo registrado e que seus clientes estão dizendo.

Evitá-lo no futuro

Verifique novamente tudo de volta no controle de origem . Esperamos que você tenha chegado a uma melhor estrutura mais recente, mais sã, diretório por este ponto.

Obter uma estrutura de teste no lugar . Mesmo se isso significa apenas conseguir um framework de teste unidade básica no lugar e fazer alguns testes básicos de fumaça após cada implantação, é melhor do que nada. Idealmente, você deve ter um engenheiro de teste ou um cliente conhecedor e de confiança que pode gastar tempo testando após cada implantação.

Coloque um processo de implantação no lugar se você crescer mais de um desenvolvedor. Controle das mudanças no ambiente de produção deve ser sua primeira prioridade. (A última coisa que você quer fazer é passar por isso novamente, certo?) Você deve ter um processo claro e simples para se mover entre os limites ambientais (como Dev -> Test então Test -> Produção).

Respondeu 09/12/2008 em 20:23
fonte usuário

votos
16

Na maioria das vezes você pode dizer se um arquivo está sendo usado por usando grep.

grep -r "index2.php" *

Você também pode usar o analisador PHP para ajudá-lo a limpeza. Aqui está um exemplo de script que imprime as funções que são declarados e chamadas de função:

#!/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";
        }
    }
}
Respondeu 09/12/2008 em 23:56
fonte usuário

votos
10

Se é o pior caso, o código é tudo scrampled, e toda a exposição é misturado com a lógica e as chamadas de banco de dados, você pode fazer o que eu tinha a ver com um projeto PHP.

Eu dei-lhe três partidas em tentar a abordagem refatoração. Era como colina de escalada em uma motocicleta e recebendo 10% do caminho de cada vez. Então eu peguei uma outra abordagem que acabou funcionando muito melhor.

  1. I logado como usuário,
  2. e trabalhou através de cada tela e cada caso de uso que eu poderia encontrar.
  3. Guardei o html para arquivos estáticos,
  4. e tomou notas sobre o funcionamento processual e regras de negócio óbvias.

Eu fiz isso por 3 dias sólidos, e, em seguida, tomou as minhas notas e teve uma longa conversa com os stakeholders.

Depois de obter um acordo sobre alguns primeiros passos, eu reimplemented toda a UI html corretamente, usando o bom design consistente e abstração. Depois de ficar rolando, eu poderia fazer um telas casal por dia.

Então eu peguei o resultado de volta para as partes interessadas e correu através de um grupo de casos de uso. (As partes interessadas eram imensamente satisfeito com os passos 1 e 2, porque não gostou da primeira implementação em tudo de qualquer maneira (surpresa) e agora parecia que não havia esperança de melhoria, não apenas a recuperação de sane-old app.

Que acabou por ser o fim do trabalho duro (e também o fim do risco do projeto percebido pelos stakeholders.)

Descobriu-se que o primeiro grupo tinha ficado tão amarrado em suas próprias spaghetti Misbegotten que havia realmente relativamente pouco conteúdo para o trabalho, então duplicá-lo teve menos espaço do que qualquer suspeita.

Mas a decisão fundamental foi que o código original, conteúdo e estrutura, foram unrefactorable e eu precisava trabalhar a partir de uma visão inteiramente exterior com uma nova estrutura que foi projetada corretamente.

Respondeu 10/12/2008 em 00:24
fonte usuário

votos
10
  1. Configurar um servidor de desenvolvimento (como Greg Hewgill mencionado, VirtualBox e Virtual PC são boas escolhas para isso).

  2. Coloque os arquivos do site atuais (incluindo as configurações do servidor web e PHP relevantes!) No controle de versão.

  3. Descubra quais arquivos estão sendo usados ​​- use sua configuração do servidor de desenvolvimento para testar através da remoção de todos os arquivos fooN.php e ver se ele ainda funciona.

  4. Ore ... lotes (OK, isso não é necessário, mas parece que você vai precisar dele).

Respondeu 09/12/2008 em 19:57
fonte usuário

votos
7

Uma coisa que você pode considerar é instalar o PHP extensão "xdebug" em um ambiente de desenvolvimento, configurá-lo para rastrear todas as chamadas de função, e depois tão plenamente quanto possível (possivelmente através de testes de UI automatizado) exercer toda a aplicação. Então você vai ser capaz de analisar / analisar os arquivos de rastreamento xdebug para encontrar todos os arquivos / funções usadas pela aplicação.

Respondeu 09/12/2008 em 20:38
fonte usuário

votos
6

Outras pessoas sobre esta discussão tem grande conselho. Eu estive nesta situação também. Provavelmente, todos de uma só vez em sua carreira entrou em um projeto que parece que foi atingida por um tornado.

Uma sugestão que eu gostaria de acrescentar é que antes de fazer qualquer da limpeza descrito por outras pessoas, você precisa para obter management buy-in.

  • Faça um plano com base em sugestões sobre esta discussão.
  • Descrever qualquer novo hardware ou software que você precisa para criar um ambiente de desenvolvimento e teste, e precificar estes para fora.
  • Descobrir quais novas competências que você precisa para ser treinado para configurar e usar o ambiente de desenvolvimento e teste. Estimar o tempo e as despesas necessárias para você obter essas habilidades. Por exemplo, livros ou formação pago.
  • Estimar um cronograma de trabalho para que você possa fazer a limpeza. Quanto tempo para obter o código sob controle de origem? Quanto tempo para entender o banco de dados? Quanto tempo para entender o PHP e código javascript?
  • Apresentar isso ao seu gerente, e frase a meta em termos de benefício para a sua linha de fundo. Por exemplo, uma vez que tudo é limpo, fazendo alterações ou lançando uma nova funcionalidade será mais rápido, depuração de erros será mais previsível, e incrementando novos funcionários será mais fácil.

Naturalmente que você precisa para continuar a trabalhar com a confusão atual, porque é um site ao vivo. Gerenciando o site ao vivo tem prioridade, então o trabalho de limpeza deve ser uma tarefa em segundo plano. Isso significa que ele vai demorar ainda mais. Minhas experiências de limpeza de um projeto de tamanho moderado como uma tarefa de fundo têm geralmente tomada seis a doze meses. Desde que o site continuará a evoluir ao longo deste período, algumas das suas tarefas de limpeza concluídas podem precisar de ser revista ou re-feito. Verifique se o seu gestor entende tudo isso também.

Se o gerente se recusa a seu plano para limpar essa bagunça, ou não valoriza limpá-lo, pelo menos, em seguida, você vai saber por que todos os outros desenvolvedores não deixaram esta empresa!

Eu tenho algumas sugestões específicas sobre como proceder:

  • Além de todos os outros grandes conselhos, eu sugiro usar o Teste do Joel como referência. Seu plano para a limpeza deve resultar em um ambiente de trabalho que iria marcar bem no Teste Joel.
  • Leia a minha resposta à pergunta " Quais são as melhores maneiras de compreender uma base de dados desconhecida? "
  • Activar o registo no site para que você possa analisar quais páginas PHP estão realmente sendo chamado. Pelo menos que lhe diz qual dos index2.php, index3.php, index4.php, etc. são verdadeiramente obsoleto.
  • PHP tem uma função get_included_files()que retorna uma matriz de todos os arquivos incluídos durante a solicitação atual. Ao iniciar a sessão esta informação, você pode descobrir quais arquivos PHP estão em uso, mesmo se eles não aparecem no log do servidor web.
  • Você realmente precisa ter um ambiente de teste e desenvolvimento que corresponde ao seu servidor de produção. Isso não é bom para testar no Windows e implantar no Linux. Isso não é bom para usar MySQL 5.0 durante o desenvolvimento e MySQL 4.0 na produção. Você provavelmente pode ir longe com uma plataforma de hardware que é mais modesta (embora compatível).
Respondeu 09/12/2008 em 21:29
fonte usuário

votos
5

Você pode ver uma lista de todos os incluídos / arquivos exigidos por colocar este perto da parte inferior da página:

<?php var_dump(get_included_files()); ?>
Respondeu 12/12/2008 em 02:45
fonte usuário

votos
5

Eu iria:

  1. Sente-se e tomar uma respiração profunda;
  2. Decidir se isso é realmente onde você quer trabalhar;
  3. Supondo que sim, então eu iria arregaçar as sleaves, escolher uma bagunça para trabalhar em um tempo e começar a trabalhar.

Eu sei que não podemos nos limitar a apenas uma tarefa de cada vez; no entanto, você pode limitar o seu trabalho para resolver um mexer de cada vez, enquanto trabalhava nas tarefas diárias que vêm em.

Respondeu 09/12/2008 em 20:09
fonte usuário

votos
3

Considere-se uma re-escrever e usar o site antigo como uma especificação recurso

Surpreendentemente, ninguém sequer mencionou isso, tanto quanto eu posso ver, mas não há outra alternativa: dar-se sobre o código e usar apenas a funcionalidade do site em si como uma especificação novo conjunto de recursos (ou seja, o primeiro de sempre para este projeto) e, em seguida, re-construir o site, com base nessas características, com um quadro estabelecido (como Symfony, Laravel, ou Drupal).

Sim, existem aqueles que assustar com a palavra mal re-escrever ... mas não são casos em que esta é realmente a melhor maneira de ir, e você insinuou algumas razões:

  • você está bastante novo para PHP desenvolvimento, você mesmo
  • você provavelmente será melhor começar com algo limpo em vez do código porcaria pura você herdou
  • em última análise, a maioria dos usuários não dão a mínima para o código-fonte , e se parece que ele "trabalha" para eles, eles podem olhar para você como você é louco se você tentar lhes dizer algo está terrivelmente errado
  • você vai se divertir mais e viver uma vida mais longa, se você pegar as práticas de controle de revisão fonte e design de banco de dados dentro de uma estrutura unificada que parece que alguém realmente se importava o suficiente para ter seu nome ligado a ele

Claro, todo mundo nesta posição teve que trabalhar com um código como este antes, mas às vezes é o bastante e é melhor para desfazer o espaguete e começar com uma placa fresca.

Se você ler o artigo de Joel sobre por que isso é ruim para fazer um re-escrever, você vai notar quase nenhuma das circunstâncias ele cita aplicar a você aqui.

Respondeu 10/12/2008 em 01:02
fonte usuário

votos
2
  1. Obtê-lo sob controle de revisão.

  2. Decidir sobre as convenções de nomenclatura e estrutura de arquivo / diretório.

  3. Verifique se você tem as ferramentas decente / IDE.

  4. Configurar um ambiente de desenvolvimento / testes separado, se você não tiver já

ENTÃO ...

  1. Infelizmente, você vai precisar para peneirar todas essas 1, 2, 3 arquivos e determinar quais estão em uso, e que podem ser eliminados. Não há outro jeito além de uma força bruta moer através, arquivo por arquivo.

  2. Mesmo que eu tenha um RCS no lugar, eu ainda muitas vezes mover o que eu penso são scripts não utilizados para um local escondido, dizem .mausoleum e depois ter a RCS ignorar esse local. Bom para ser capaz de dar uma olhada no local sem voltar para o repo.

  3. HTML separado e PHP na maior medida possível . Eu não posso forçar este bastante! Se isso for feito em cada arquivo, tudo bem. Contanto que você tem pedaços separados de PHP e HTML. Claro, HTML será salpicado com ecos aqui e ali, mas tentar ter todos os testes, switches, tudo mudou-se para fora do bloco HTML e no bloco PHP. Isso por si só pode ser enorme quando se trata de fazer as coisas resolvidas.

  4. Se o código é principalmente processual - Presumo no seu caso, é - é provavelmente melhor fazer alguma limpar em primeiro lugar, antes de fazer qualquer refatoração graves ou refatoração em classes.

  5. Como você encontrar arquivos / scripts que podem, logicamente, ser combinados, fazê-lo. (Eu vi projectos - provavelmente não muito diferente de seu - onde o número total de arquivos sobreviventes é de cerca de 1/4 do que nós começamos com).

Uma vez que você tenha ido tão longe, então você pode começar a refatoração adequada ou refatoração em classes.

Bonne chance!

Respondeu 02/03/2009 em 18:50
fonte usuário

votos
2

Lotes de mensagens úteis sobre como lidar com isso.

Sem tentar repetir o que todos os outros disseram:

  1. Obter uma cópia do ambiente prod execução. Pode ser uma máquina virtual, ou outra máquina real. Mas você precisa ser Deus nele. Se o banco de dados prod está em outra caixa, você vai precisar de uma versão dev também.
  2. Jogue tudo no controle de versão. Em outra caixa. Um que é apoiada pelo menos semanalmente.
  3. Certifique-se de que você sabe como ramificação obras em seu aplicativo de controle de versão. Você provavelmente vai precisar dele.
  4. Se o servidor prod bloqueado. Você não quer quaisquer outras alterações feitas a ele que não saem de controle de versão.
  5. Criar instruções para liberar o código do controle de versão para o servidor prod. A menor unidade de mudança releasable deve ser toda a base de código.

Os próximos passos dependem de como ligado a ele são os usuários. Se ele não pode ser alterado para muito por qualquer motivo, você vai precisar de uma abordagem progressiva. Se o desenvolvimento e manutenção ainda precisa acontecer, então este é provavelmente a sua única opção. Lembre-se de usar esse recurso ramificação para separar esses mods longe de seus esforços de re-escrita.

Para colocar sentido na estrutura, você tem que criar basicamente uma nova estrutura ao lado do que está lá. Um novo manipulador DB é geralmente um bom lugar para começar, incluídos a partir de um genérico arquivo de inclusão que cada página deve carregar. O objetivo aqui é criar um mínimo incluem a estrutura que pode ser expandida mais tarde, sem contar todas as páginas para carregar arquivos adicionais.

Agora você precisa para começar a funcionalidade movendo-se sobre a seus novos arquivos de inclusão. Você vai precisar de uma maneira de ter vários arquivos abertos ao mesmo tempo, como um editor de multi-arquivo ou tela + vi (ou emacs). Comece com funções de utilidade e de código-blocos que se repetem em vários lugares. Tente não ficar distraído em fixar um lote de uma só vez. Alguns tipos de problemas vão ter apenas mover lugares como outros problemas de ficar fixo. Você vai voltar a eles mais tarde.

Não pense que você precisa adicionar um quadro de terceiros. Adicionando tal coisa rapidamente leva a uma re-escrita completa. Neste ponto, isso vai ser muito mais trabalho do que apenas domar sua incluem estrutura. Assim resolver isso primeiro.

Como você se move funcionalidade longo, você precisará ter arquivos usar o novo arquivo de inclusão. Os primeiros arquivos que você fazer isso por você estará perseguindo conflitos por um tempo. Ela vai se sentir desanimador e sem sentido, mas esta é provavelmente a parte mais difícil. Depois de alguns arquivos, ele vai ficar mais fácil. Haverá momentos em que você pode migrar meia-dúzia de páginas para o novo incluir arquivos, substituindo uma dúzia inclui com apenas um. O outro lado dessa ação é que haverá arquivos que você pode simplesmente apagar.

Se você ficar nisso, você acabará por chegar ao ponto onde todos os arquivos de inclusão são os únicos que você escreveu e você estará em toda incluem layout. Por esse ponto, será significativamente mais fácil de fazer mudanças muito mais invasivos, como colocar em um quadro de terceiros.

Respondeu 10/12/2008 em 05:31
fonte usuário

votos
2
  1. Fazer um back-up do código agora.

  2. Controle de versão.

  3. Criar um site de teste. É o local executando sob o Apache? Você pode até mesmo instalar Apache + PHP + MySQL em seu próprio computador, e usar isso para o teste.

  4. Lidar com questões de segurança. Verifique se o site é protegido de injeção de SQL, e da injeção de e-mail. No mínimo, você pode fazer uma pesquisa para chamadas de banco de dados e adicionar chamadas para mysql_real_escape_string()(bem, se ele está usando um banco de dados MySQL) ... você pode fazer uma correção real, mais tarde uma vez que você entender o código melhor. Para a injeção de e-mail ... escrever uma função de filtro que filtra código spammer, e certifique-se todos os campos do formulário que são usados em um e-mail são filtrados. (Sim, adiciona mais código espaguete, mas vai demorar um pouco antes que você está pronto para refatorar significativamente o código.)

  5. Depois disso, eu sugiro atualizações incrementais. Você é novo eo código é uma bagunça higgleypiggley, por isso vai levar algum tempo para entender tudo isso ... e para compreender inteiramente o domínio. Então, basta ir sobre o seu trabalho para um pouco, consertar o que precisa ser corrigido, acrescentando o que precisa ser adicionado. Como você está fazendo isso, você está aprendendo o sistema é colocado em conjunto. Depois de saber como o código é organizado (ou não organizada) um pouco melhor, você pode começar a planejar uma grande refatoração / reescrita do sistema. Esperamos que você pode fazê-lo componente por componente de modo que você sempre tem um novo marco no futuro próximo.

Respondeu 10/12/2008 em 00:06
fonte usuário

votos
2

Eu sei como você se sente. Eu herdei o desenvolvimento de um projeto como este. Ele ficou comigo por um ano e para ser honesto, me fez o desenvolvedor que sou hoje. Não há melhor oportunidade para o avanço pessoal do joelho trabalhar profundamente na merda.

Aqui estão as coisas que me ajudaram a mais:

  • identificar quais são os arquivos essenciais do sistema. Você vai encontrá-los, porque a maior parte do seu trabalho será feito neles
  • criar uma versão local do projeto (incluindo o banco de dados) e colocá-lo sob controle de versão
  • trabalhar apenas em uma pequena quantidade de arquivos com pequenas alterações
  • não colocar nada no interior da versão de produção até que você tenha testado exaustivamente, e depois estar pronto para colocar a versão antiga de volta
  • descobrir como os usuários do sistema são tratados (sessões, cookies). Criar um super usuário e, em seguida, quando você precisa testar seu código ao vivo no sistema colocá-lo em um bloco como este:

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

    outros usuários não será capaz de sentir as mudanças. Esta técnica me ajudou muito quando eu era incapaz de substituir o estado do sistema na minha máquina local

  • escreva teste, e seguir as orientações de engenharia rigorosos para todo o código que você está escrevendo

Respondeu 09/12/2008 em 23:09
fonte usuário

votos
2

Esta é realmente uma bagunça. Mas começar a criativa sobre onde cortar alguns dos tentáculos sobre esta coisa:

  1. Obter o controle de versão. Eu recomendo Git.
  2. Configurar um servidor de desenvolvimento local. Encontre um, LAMP ou MAMP pacote WAMP para você começar desde que você é novo para isso.
  3. Encontre os pontos de entrada (index.php, etc.). Verifique seus logs de acesso do servidor para ver o que estes são.
  4. Arregace as mangas em alguma magia negra expressão regular e despejar um include / exigem árvore em todos os arquivos. Mas cuidado com qualquer include ($ filename) dinâmica inclui. Se você tiver qualquer um desses que você vai precisar fazer alguns log em $ filename para descobrir o que possivelmente é incluído, embora o código em torno dele deve dar-lhe pistas. Com um pouco de sorte você pode abater todos os seus arquivos não utilizados desta forma.
  5. Use magia negra mais regex para verificar as funções e métodos estão sendo mencionados na base de código. Pode haver um IDE que pode ajudá-lo com isso. Tente NetBeans (eu usei isso para me ajudar a refatorar um projeto C ++, uma vez, por isso pode ajudar aqui.)
  6. Como alguém respondeu: "descobrir, se necessário, se algumas classes são utilizados e alguns não são, você pode usar get_declared_classes em conjunto com get_defined_vars e getType para ver quais tipos estão sendo instanciado." Você também pode apenas escrever algum código para encontrar todas as novas declarações na base de código.
  7. E assim por diante ... apenas pense sobre como você pode talhar esse monstro para baixo. E tentar reorganizar o código onde você pode.
Respondeu 09/12/2008 em 20:31
fonte usuário

votos
2

Aqui estão algumas ideias:

  • PHP e Apache funcionar muito bem no Windows também. Talvez você possa fazer uma instalação todo-o Windows depois de tudo?
  • Tente grep'ing (ou alguma alternativa Windows) para 'incluir' e 'exigir' em todos os arquivos PHP. Em seguida, faça uma lista de todos os arquivos incluídos encontrados. Compare a lista com os arquivos na pasta. Você deve ser capaz de se livrar de pelo menos alguns arquivos não referenciados.
  • Alternativamente fazer uma lista de todos os nomes de arquivos e pesquisar todos os arquivos para eles. Você poderia fazer algo como um gráfico de dependência como esta.
Respondeu 09/12/2008 em 20:30
fonte usuário

votos
2

Eu acho que todos 5 de seus pontos de vida em alguns projetos ASP clássico Eu herdei, e um PHP também ...

Concordo plenamente com os outros em obtê-lo no controle de origem o mais rápido possível e usar VMWare, VirtualBox, etc para um ambiente de teste.

Certifique-se de obter o seu banco de dados de versão também, especialmente se os procedimentos têm lógica extra neles (e não apenas inserção reta, update, delete). DB versionamento preciso mais atenção, então as páginas PHP. Você precisa gerar todos os objetos para scripts SQL e colocar esses scripts no controle de origem. Então, como você mudar a estrutura db, procedimentos, etc você precisa atualizar os scripts para que você tenha uma história dessas mudanças também.

Como para descobrir o que está usando o que no lado do banco de dados Eu sugeriria olhar ApexSQL Limpa . Eu usei isso em um projeto com várias centenas de arquivos ASP, mais de 200 mesas e cerca de 400 procedimentos armazenados. Eu era capaz de identificar 20 ou mais tabelas que não estavam em uso e cerca de 25% dos procedimentos armazenados. Com ApexSQL Limpa você pode adicionar todos os seus arquivos php na verificação de dependência, juntamente com as tabelas, vistas e procedimentos armazenados. Pegue o teste de 30 dias e check-out, você vai economizar muito tempo.

Para que os arquivos estavam em uso para o site, tive logs do servidor web para o mês anterior e correu pesquisas contra eles para qualquer coisa que eu não tinha certeza sobre. Eu também faço como uma variação do que Aistina sugeriu em modificar os arquivos para iniciar sessão quando eles são acessados. Talvez tê-lo ir para uma tabela no banco de dados que você configuração que é nome de arquivo e acesso contagem e para cada vez que o arquivo é carregado, ele incrementa a contagem. Então, depois de um período de tempo que você pode olhar sobre as contagens e determinar o que pode ir.

Respondeu 09/12/2008 em 20:24
fonte usuário

votos
2

O primeiro passo, claro, seria a de colocá-lo sob controle de versão. Desta forma, pelo menos você pode voltar para a versão original de trabalho. Em segundo lugar, pode ser uma boa idéia para substituir o incluem, exigem, etc funções para, por exemplo, escrever o nome do arquivo que está sendo incluída a algum arquivo de log, desta forma você pode descobrir quais arquivos estão sendo incluídos (assim espero excluir uma grande parte do index2.php, index3.php, etc.

Para descobrir, se necessário, se algumas classes são utilizados e alguns não são, você pode usar get_declared_classes em conjunto com get_defined_vars e getType para ver quais tipos estão sendo instanciado.

Quanto à questão 4 e 5, são provavelmente um pouco mais difícil de resolver, mas isso deve começar esperançosamente.

Respondeu 09/12/2008 em 20:01
fonte usuário

votos
2

Você definitivamente precisa de um ambiente de desenvolvimento. Se você não quer mexer com o funcionamento do site na sua caixa de janelas, você poderia pegar uma imagem VMWare de alguma distro Linux.

Respondeu 09/12/2008 em 19:53
fonte usuário

votos
2

A primeira coisa que eu faria é criar um ambiente de teste usando uma máquina virtual de algum tipo. VirtualBox ou Virtual PC seria escolhas finas. Dessa forma, você pode começar a mudar as coisas sem medo de quebrar o ambiente de produção. Não importa quanto trabalho isso parece que será (com o servidor de banco de dados e web e tudo), no final vai valer a pena. Uma das grandes vantagens é que você pode copiar o VM e dá-lo a outra pessoa, se você achar que precisa de ajuda.

Respondeu 09/12/2008 em 19:50
fonte usuário

votos
1
  1. começar a usar o controle de versão no projeto (eu recomendo git)
  2. escrever testes de unidade para todo o código
  3. começar a usar ORM (eu recomendo fortemente doutrina)
  4. começar a usar alguma estrutura (i recomendar symfony / nette)
  5. começar a refatoração de código php
Respondeu 02/12/2010 em 08:54
fonte usuário

votos
1

Sim, Controle de Versão é definitivamente o passo # 0.

Eu também recomendo um bom Code Search Ferramenta .

Agente Ransack é muito bom (supondo que você está no windows) http://www.mythicsoft.com/agentransack/Page.aspx?page=download

Eu estaria voando às cegas, sem busca do código.

Respondeu 11/01/2009 em 20:55
fonte usuário

votos
1

Eu apenas passei por isso mesmo.

Meu número um dica é não tentar mudar tudo em um dia. Você precisa de amigos, se você realmente quer ser capaz de corrigir isso. Você precisa do seu colegas respeito antes de sugerir como mudar tudo o que tenho vindo a trabalhar há meses (anos?).

Em primeiro lugar, obter o código sob controle de versão o mais rápido possível. Se isso não vai ser fácil para você, pelo menos, começar a fazer backups diários, mesmo que isso signifique apenas fechando os arquivos e nomear o arquivo zip com a data. Se ninguém lá sabe sobre controle de versão, comprar o livro de um programador pragmático em CVS ou SVN, e configurá-lo sozinho. Os livros podem ser lidos em um dia, e você pode ser instalado e funcionando rapidamente. Se ninguém quer usar o controle de versão, você pode usá-lo a si mesmo ... então quando alguém perde um arquivo que você pode salvar o dia com uma cópia do seu repo. Mais cedo ou mais tarde, os outros vão ver a sabedoria que é controle de versão.

Em segundo lugar, mergulhar no código tão duro como você pode possivelmente. Vivê-lo e respirá-lo por um mês. Mostrar as pessoas que estão lá que você vai aprender o seu código.

Em terceiro lugar, como você ir através do código, tomar notas copiosos. Anote cada coisa que incomoda você sobre o código. Apenas obter os seus pensamentos no papel. Você pode organizá-la mais tarde, após meses Um.

Em quarto lugar, instalar um perfil de código (como xdebug). Isso vai lhe dizer quais arquivos e funções estão sendo chamados em cada página, e quanto tempo cada pedaço de código necessário para executar. Você pode usar isso para descobrir o seu inclui questões e encontrar pedaços lentas de código. Otimizar os primeiros.

Após o seu mês de trabalho duro, peneirar o código, e tomando notas, transformar suas notas em um documento adequado. As diferentes seções pode variar de segurança, armazenamento em cache, a arquitetura, a tudo aquilo que está incomodando você. Para cada crítica que você faz, oferecer uma solução melhor, e uma estimativa de quanto tempo levaria para consertar. Isto é onde você se livrar de todos os quadros concorrentes javascript etc.

Revisar este documento, tanto quanto possível. Eu não posso enfatizar o suficiente.

Certifique-se de seu público pode dizer que você está fazendo isso para o bem da empresa, e não apenas as suas preferências pessoais.

Apresentá-lo ao seu chefe, em pessoa. Definir-se um tempo para discutir o assunto.

Eles poderiam demiti-lo por ter escrito isso. Se o fizerem, você está melhor sem eles, porque eles não querem melhorar, e sua carreira irá estagnar.

Eles podem querer implementar todas as suas recomendações. Não é provável, mas é possível. Então você ficaria feliz (a menos que suas recomendações falhar).

O mais provável é que eles vão querer implementar algumas das suas recomendações, e isso é melhor que nada. No mínimo, ele vai ajudar a aliviar as suas preocupações.

Quanto ao teste, configurar outro "host virtual" no Apache (suportado em Windows e Linux). Hosts virtuais permitem que você execute vários sites em um único servidor. A maioria dos sites maiores têm pelo menos 3 hosts virtuais (ou servidores reais): dev.domain.com (para desenvolvimento diário), staging.domain.com (para QA pessoas para fazer testes em apenas antes de um lançamento), e www.domain. com (seu servidor de produção). Você deve também dev instalação, preparação e produção versões do banco de dados, com diferentes logins e senhas para que você não acidentalmente confundi-los.

Uma solução alternativa seria dar cada desenvolvedor seu próprio host virtual no servidor Linux, e eles podem trabalhar via FTP / SCP ou compartilhamento de rede usando samba.

Boa sorte!

Respondeu 11/12/2008 em 03:29
fonte usuário

votos
0

Além da grande coisa outras pessoas disseram, para obter uma primeira passagem em que os arquivos estão sendo usados ​​ativamente, você pode instalar um cache opcode como APC ou eaccelerator no seu servidor dev (ou mesmo um servidor de produção, isso não vai quebrar qualquer coisa). Em seguida, clique em torno da aplicação Web no seu servidor dev (ou deixar os usuários fazê-lo em seu servidor de produção).

Agora olhe para a lista de arquivos em cache na sua página de cache de administração. Se um arquivo não está listado como sendo armazenada em cache pelo seu opcode cache, há uma boa chance de que não está a ser carregado por qualquer coisa.

Esta não é uma solução completa, mas se cada diretório tem 10 arquivos index.php (por exemplo index.php, index2.php, etc.), pelo menos você vai saber qual deles está sendo usado por seu aplicativo.

Respondeu 11/12/2008 em 03:35
fonte usuário

votos
0

Faça o que Harper Shelby disse ...

Mas, eu também gostaria de acrescentar que, se você não obter o apoio de gestão para limpar isso, você pode querer aceitar o fato de que isso pode ser assim por uma razão. ... apenas dizendo. ;-)

Respondeu 09/12/2008 em 20:29
fonte usuário

votos
0

Tentar obter estatísticas detalhadas no site e descobrir onde os pontos de entrada e saída são. Uma maneira decente para descobrir quais arquivos estão sendo atingidos fora do topo (e, em seguida, olhar para esses arquivos para ver o que inclui estão sendo puxados).

Respondeu 09/12/2008 em 19:58
fonte usuário

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