Qual é a melhor forma de migrar de um existente confuso webapp e elegante, MVC?[fechado]

Question

Entrei para uma nova empresa, a cerca de um mês atrás.A empresa é bastante pequeno no tamanho e tem muito forte "start-up" para ele se sentir.Eu estou trabalhando como programador Java com uma equipe de 3 pessoas.A empresa, principalmente, vende um serviço para as empresas/business-tipo de pessoas a utilizar na comunicação com o outro.

Uma das principais coisas que eu tenho sido, e será a trabalhar, é o site principal da empresa, a partir do qual o serviço é vendido, os usuários existentes login para verificar o seu serviço de e pagar as suas contas, os novos usuários podem se inscrever para um teste, etc.Este é, actualmente, um JSP da aplicação implementada no Tomcat, com acesso a um banco de dados feito através de uma camada de persistência escrito pela própria empresa.

Repetida e crescente frustração que eu estou tendo aqui (e eu estou muito feliz com o trabalho em geral, para que este não é um "oh não, eu não gosto do meu trabalho"-o tipo de post) é a falta de qualquer maiores de design ou arquitetura para esse aplicativo web.O aplicativo é composto de várias dezenas de páginas JSP, com quase nenhuma lógica existente em Servlets ou Feijão ou qualquer outro tipo de estrutura.Muitas das páginas JSP são milhares de linhas de código, eles jsp:include outras páginas JSP, lógica de negócios, que se mistura com o HTML, frequentemente utilizados trechos de código (como a obtenção de uma conexão de serviço web) é recortar e colar, ao invés de incluir reutilizados, etc.Em outras palavras, o aplicativo é uma bagunça.

Houve alguns rumores dentro da empresa, para tentar re-arquiteto este site para que ele se encaixa MVC melhor;Eu acho que os desenvolvedores e superior-ups estão começando a perceber que esta atual padrão de código espaguete não é sustentável ou muito facilmente escalável para adicionar mais funcionalidades para os usuários.O maior-ups e os desenvolvedores estão cautelosos completamente re-escrita da coisa (por um bom motivo, pois isso significaria várias semanas ou meses de trabalho de re-escrever a funcionalidade existente), mas nós tivemos algumas discussões (lentamente) re-escrevendo a certas áreas do site para um novo quadro.

Quais são algumas das melhores estratégias para permitir mover a aplicação e a base de código para esta direção?Como posso, como um desenvolvedor realmente ajudar a mudar isso junto, e rapidamente, sem parecendo idiota-y cara novo que vem em um trabalho e diz a todos que o que escreveram é uma porcaria?Existem estratégias comprovadas ou experiências que você usou na sua própria experiência de trabalho quando você já encontrou esse tipo de coisa?

Answer 1

Sua melhor aposta é, provavelmente, refatorá-lo lentamente, como você vá junto.Alguns de nós temos os recursos que seriam necessários para iniciar completamente a partir do zero com algo que tem tantas regras de negócio enterrado nele.Gestão realmente odeia quando você passar meses desenvolvendo um aplicativo que tem mais bugs do que o que você substituído.

Se você tem a oportunidade de construir qualquer aplicativos separados a partir do zero, use todas as melhores práticas de lá e usá-lo para demonstrar como eles são eficazes.Quando você pode, incorporar essas idéias gradualmente para o aplicativo antigo.

Answer 2

Primeiro, pegar uma cópia do Michael Pena de Trabalho Efetivamente, com Código Legado.Em seguida, identificar o melhor modo para testar o código existente.O pior caso é que você está preso com apenas alguns alto nível de testes de regressão (ou nada) e Se você tiver sorte, haverá testes de unidade.Então é um caso de lenta estável refatoração espero que, enquanto a adição de novas funcionalidades de negócio ao mesmo tempo.

Answer 3

Na minha experiência, a "elegância" de uma aplicação, normalmente, tem mais a ver com o design de banco de dados do que qualquer coisa.Se você tem um grande design de banco de dados, incluindo uma bem-procedimento armazenado definido pelo interface, a boa aplicação do código tende a seguir não importa qual plataforma você usa.Se você tiver pobres design de banco de dados, não importa que plataforma você usar, você vai ter um tempo muito difícil edifício elegante do código do aplicativo, como você vai ser constantemente de compensação do banco de dados.

Claro, há bastante espaço entre as grande e pobres, mas o meu ponto é que, se você quer um bom aplicativo de código, comece por ter certeza de que seu banco de dados é lá essas coisas.

Answer 4

Isso é mais difícil de fazer em aplicações que estão apenas no modo de manutenção, porque é difícil se convencer de que a gestão de reconfiguração de algo que já está 'trabalhando' vale a pena fazer.Gostaria de começar por aplicar os princípios do MVC para qualquer novo código que você é capaz de trabalhar (ie.mover a lógica de negócios para algo semelhante a um modelo, coloque todas as suas layout/exibir código em um só lugar)

Como você ganhar experiência com o novo código MVC você pode começar a ver oportunidades para alterar o código existente, sutilmente, de modo que ele também cai em linha.Ele pode ser um processo muito lento, mas se você pode mostrar os benefícios desta forma de fazê-lo, então você vai ser capaz de convencer os outros e obter toda a equipe a bordo.

Answer 5

Eu concordo com o lento refatoração abordagem;por exemplo, fazer uma cópia-e-colado código e extraí-lo em qualquer que seja o adequado Java paradigma (uma classe, talvez?ou melhor ainda, use uma biblioteca existente?).Quando seu código é muito limpa e concisa, mas ainda falta geral de arquitectura da estratégia, em seguida, você vai ser capaz de fazer as coisas se encaixam em uma arquitetura geral muito mais facilmente.

Answer 6

A melhor maneira é para imprimir o código, amasse-o, e jogá-lo fora.Não mesmo reciclar o papel.

Você tem um aplicativo que está escrito em 1.000+ linha longa JSPs.Ele provavelmente tem um terrível deus-Modelo de Domínio (se tiver um) e não apenas a MISTURA de apresentação com a lógica de negócios, une a ele e se senta lá e continua mexendo por horas.Não há nenhuma maneira para tirar o código que é de baixa qualidade e mover-se em uma classe Controller do MVC e ainda estar fazendo a coisa certa, você só vai acabar com um aplicativo MVC com um modelo de domínio anêmica ou aquele que tem coisas como chamadas de Banco de dados no Controlador de código, você ainda está falhando.

Você poderia tentar um novo aplicativo que faz a coisa certa e, então, os dois aplicativos falar uns com os outros, mas o que há de novo complexidade em si.Também é provável que você vai estar fazendo a mesma quantidade de trabalho que você ia fazer se você só começou a partir do zero, mas você pode ter um tempo mais fácil tentar convencer seus chefes que esta é uma abordagem melhor.

Answer 7

Iterativamente, de refatorar.Também procure por novas funcionalidades que pode ser feito completamente no novo quadro, como uma forma de mostrar o valor do novo quadro.

Answer 8

A minha sugestão seria a de encontrar o raro páginas que não necessitam de um certificado de importação de outros JSPs, ou têm muito poucas importações.Tratar cada JSP importado como uma caixa preta, e refatorar estas páginas em torno deles (de forma iterativa, o teste de cada mudança e certificando-se de que ele funciona antes de continuar).Uma vez que estes são limpos, você pode continuar a encontrar páginas com mais e mais as importações, até que, finalmente, você tem refatorado importações.

Quando refatoração, observe as peças que tentar aceder a recursos de não ser dado para a página e tentar levar isso a um controlador.Por exemplo, qualquer coisa que acessa o banco de dados deve estar dentro de um controlador, deixe o JSP lidar com a exibição de informações do controlador de dá-lo através de uma para a frente.Desta forma, você irá desenvolver várias servlets, ou coisas como servlets, para cada página.Gostaria de sugerir o uso de um front-controller base o enquadramento a esta refatoração (a partir da experiência pessoal, eu recomendo a Primavera e o seu Controlador de interface), de forma que cada controlador não está separado do Servlet, mas é, ao invés de delegados a partir de um único servlet que é mapeada de forma adequada.

Para o controlador, é melhor fazer acessos ao banco de dados de uma vez por todas, ao invés de tentar-los aos poucos.Os usuários podem e geralmente não toleram o carregamento de uma página, mas a página de saída será muito mais rápido se todos os dados do banco de dados é dado para o código de processamento, ao invés de incluir o código de processamento de suspensão e não dando dados para o cliente enquanto ele está tentando ler ainda outro conjunto de dados a partir do banco de dados.

Eu sinto sua dor e desejo-lhe sorte nessa empreitada.Agora, quando você tem que manter um aplicativo que abusos Spring Webflow, que é outra história :)