Dicas para planejar uma reescrita de um grande projeto PHP?


13

Decidi reescrever completamente uma estrutura PHP (usando MVC) na qual trabalho há anos. Meu problema até agora era que eu só tinha idéias, as jogava no Trac como tickets e as adicionava mais tarde - sem me preocupar com o design do próprio framework. Com o tempo, isso causou alguns problemas e acho que uma reescrita seria útil, mas não sei por onde começar com o planejamento - sei que não quero usar o Trac e sei que preciso de mais do que apenas bilhetes e marcos - mas o que mais eu precisaria?

Eu realmente quero planejar completamente essa reescrita, quero detalhar todos os recursos que eu quero, para onde ele vai e como ele se conectará a todas as outras partes - mas não tenho experiência com esse nível de planejamento. Algum conselho? Algum programa que irá ajudar? Estou cansado de Trac, nunca gostei muito disso.

Sei que precisarei de um documento de design, mas há algum layout específico que devo seguir? Também precisarei de rastreamento de bugs, tickets, marcos etc., mas além do Trac também não sei o que é bom para isso. Tenho certeza de que preciso de mais, mas não tenho idéia do que seja necessário, então qualquer ajuda seria apreciada.


por que você quer reescrever? Por que não refatorá-lo nos lugares que precisam de melhorias? Quando você reescreve algo do zero, é provável que elimine problemas antigos para novos.

@Gordon talvez seja tão terrivelmente escrito que reescrevê-lo seja melhor do que refatorar.
rightfold

Reescrever é sempre mais difícil do que parece, e eu aprendi da maneira mais difícil. Oh, bem dessa vez eu sei o que estou fazendo, por isso vai demorar metade do tempo (em seguida, ele acaba levando mais tempo do que o original porque você over-engenheiro tentando corrigir erros ou antecipar-se feito anteriormente)
Davy8

Respostas:


7

Veja abaixo algumas coisas que faço ao desenvolver um grande projeto:

1 - Uso uma ferramenta de planejamento como o OpenProj e adiciono todos os recursos que quero incluir como tarefa. Por exemplo, agora estou trabalhando em um recurso para permitir que meus usuários façam logon automaticamente depois que se registrarem no meu site. Eu tenho uma tarefa no meu plano como "feature-autologin".

2 - Sou uma loja de desenvolvimento individual, por isso geralmente passo de um recurso para o outro. Meu plano é criado de forma que todos os recursos sejam seqüenciais. Não investi muito tempo estimando quanto tempo precisarei para cada recurso. Eu costumo considerar que cada um me levará um dia para se desenvolver. Se for preciso mais, simplesmente atualizo o plano e todas as tarefas futuras são movidas de acordo.

3 - Eu uso o git extensivamente. Cada recurso é uma ramificação. Depois de concluir cada recurso, mesclo-o novamente ao ramo de desenvolvimento e crio um novo ramo para o próximo recurso.

4 - Se eu encontrar um bug no software, crio um pequeno ramo git para corrigi-lo e mesclá-lo novamente quando ele for resolvido. Certifico-me de atualizar o ramo de desenvolvimento e meu ramo de recursos atual em que estou trabalhando. A propósito, o bug se torna outra tarefa no meu plano OpenProj. Algo como "bug-wrong-address". E quando eu insiro, todos os outros recursos são movidos de volta na linha do tempo.

5 - Enquanto estou desenvolvendo, se penso em um novo recurso, simplesmente o incluo no plano em que acho que melhor se ajustará e ajustará a linha do tempo novamente.

Eu espero que isso ajude. Parece que você tem um projeto emocionante pela frente. Boa sorte!


10

Se você deseja uma reescrita completa, por que não considerar se deveria usar o php? Uma mudança / atualização da tecnologia pode ser o catalisador que você deseja melhorar seu projeto / escalabilidade / manutenção, etc ...


3
Além disso, considere as estruturas existentes mais adequadas do que a criação de Outra estrutura de uso único.
S.Lott

1
@ S.Lott - o que há de errado em criar um Framework de uso único se ele for adaptado para atender melhor a esse uso único do que qualquer outro?
Anônimo

1
@ Chris Bridgett: O mundo pode não precisar de mais uma estrutura altamente especializada. Pode ser um "incômodo atraente". Um divertido desperdício de tempo. Freqüentemente, as estruturas existentes também funcionam. A "adaptação" em uma estrutura de finalidade especial geralmente resulta de uma falha no entendimento de uma estrutura existente e estabelecida. Freqüentemente, as estruturas existentes são mais seguras, mais confiáveis ​​e mais rápidas. Freqüentemente, as estruturas existentes já são depuradas. Freqüentemente, as estruturas existentes são melhor compreendidas por outros membros da equipe.
S.Lott

@ S.Lott: Estou escrevendo isso para vários sites que possuo, e seu design é configurado de uma maneira que nenhuma outra estrutura é. Também não pretendo lançá-lo por algum tempo, se é que alguma vez. re: TheLQ: Esse foi um dos meus primeiros pensamentos, no entanto, nenhuma outra linguagem da Web tem o alcance que o PHP faz além do .NET. O Python seria o preferido, no entanto, configurá-lo em servidores cPanel (que infelizmente compõem grande parte do mundo de hospedagem na web), é uma dor.
Jon

1
@ S.Lott Estive lendo sobre Symfony, CakePHP e CodeIgniter desde a publicação, e a principal coisa que me impede de usá-las - é que todas parecem aderir cegamente ao MVC e ignorar a reutilização. Meu projeto atual (e futuro, se eu reescrever) é o MVC em uma única pasta (pasta A 'module'), com visualizações lá, no entanto, o usuário deseja (nomeado exemplo.module.view.php), além de temas pasta, onde os designers podem criar seus próprios temas que substituem as visualizações existentes. Isso é crucial para mim, e nenhuma das principais estruturas parece fazer isso sem muitos hackers - isso me incomoda.
Jon

10

Eu sugeriria refatorar pesadamente

O problema que você antecipa aqui:

Eu realmente quero planejar completamente essa reescrita, quero detalhar todos os recursos que eu quero, para onde ele vai e como ele se conectará a todas as outras partes - mas não tenho experiência com esse nível de planejamento. Algum conselho? Algum programa que irá ajudar? Estou cansado de Trac, nunca gostei muito disso.

é realmente difícil. É basicamente o modelo Waterfall com toda a sua feiura. Aqui estão algumas evidências anedóticas dos problemas com a abordagem de 'grande reescrita', que chega à conclusão: você provavelmente não antecipará os problemas corretamente e acabará com outra bagunça que deseja reescrever do zero. Não porque você é ruim, mas porque é impossível conseguir algo grande de uma só vez.

Quando você começar a refatorar, poderá escrever tickets individuais e continuar usando o projeto. O truque aqui é identificar pequenas mudanças que levam a um design geral melhor.

Por exemplo: você menciona, não possui MVC, mas deseja. Como primeiro passo, você pode pegar um único arquivo PHP e, assumindo a mistura usual, classificá-lo, para que, no topo, você tenha todos os acessos ao db, cálculos etc., na parte inferior, você tem o "modelo" ( primeiros tickets, para cada arquivo). Como uma segunda etapa, você pode encapsular todas essas partes de modelo em funções, que passam seus parâmetros. (muito mais ingressos). Feito? Parabéns, você terminou seu V no MVC.


Vou levar isso em conta, obrigado. Também apenas para esclarecer as coisas - estou usando o MVC agora.
Jon

@ Jon: Sim, também, meu exemplo assumiu uma página típica, sem estrutura. Mas acho que, mutatis mutandis, minha resposta não é invalidada por isso. Um ponto que não mencionei: refatorar é divertido. É muito gratificante ver porcaria total de tornar-se algo bonito :)
keppla

3

Considere usar uma estrutura existente. CakePHP, Zend Framework, CodeIgniter e Symfony são os conhecidos pelo PHP. Se eles atendem às necessidades de centenas ou milhares de usuários, tenho certeza de que podem atender às suas.

Se você estiver disposto a aprender / usar algo diferente de PHP - Django (Python) e Rails (Ruby) são praticamente as principais estruturas para aplicativos da Web convencionais.

Isso, é claro, a menos que você queira experiência na criação de estruturas - o que, devo acrescentar, tem muito menos valor no mercado (em vez de saber como usar bem as estruturas existentes e suportadas).


1

O que eu gosto de usar é o Redmine como rastreador de agendamento. A TI lida com cada um desses itens muito bem, além de ser muito mais amigável (na minha opinião) do que o trac.

Em relação à sua reescrita, é importante entender primeiro que você nunca antecipará todos os recursos / novas extensões que possam surgir; portanto, tente escrever seu aplicativo o mais flexível possível. O uso de muitas das estruturas MVC que o PHP possui pode ajudar a alavancar isso; no entanto, algumas dessas estruturas também ajudam você se sua arquitetura de banco de dados não é flexível desde o início (Cake). Eu realmente focaria em tornar as coisas o mais abstratas possível e, sempre que vir algo codificado, pergunte-se para que serve e por que não pode ser armazenado em um banco de dados.

Realmente o design do DB ajuda a responder a muitas perguntas e problemas, e é aí que vejo a principal importância de como seu aplicativo interage; portanto, recomendo que passe boa parte do tempo analisando como os dados são armazenados e como o seu banco de dados está estruturado.


1

Como um software de rastreamento de problemas, o JIRA é ótimo, mas é muito caro. Outra boa ferramenta que eu estou usando é Eventum. É grátis.

Mas a parte mais importante é ter uma boa idéia do que você precisa. Primeiro, você precisa reunir os requisitos para sua aplicação, para ter uma idéia geral do que deseja e o mais completo possível.

Com base nisso, você criará requisitos de software, que é uma abordagem mais técnica na qual descreverá os módulos que farão parte do seu aplicativo, suas funções e subfunções, objetos, classes, interfaces, praticamente tudo.

Saiba que você entenderá a complexidade do aplicativo e as linhas de código necessárias para poder fazer uma estimativa e criar um cronograma. É importante ter um cronograma e prazo, ou você pode acabar nunca terminando.

Espero que ajude


Jira é muito barato para menos de 10 usuários. O custo é de US $ 10 e os US $ 10 são destinados à caridade.
sixtyfootersdude
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.