Qual é a melhor abordagem para auditar um grande aplicativo Java/J2EE

Question

Eu tenho que auditar um grande aplicativo Java/J2EE da Web que evoluiu ao longo de vários anos. Foi escrito por outra empresa, não a que estou trabalhando. No seu estado atual, tornou -se difícil evoluir e manter, novas funcionalidades são difíceis de adicionar e geralmente levam a bugs que, em algum momento, aparecem em produção. Parece haver algum código de cópia/colado que resultou em duplicação de código. O aplicativo atual é algum tipo de compra on-line com algum conteúdo do tipo CMS aqui e ali. São principalmente suportes e algumas primavera em partes mais recentes do código, talvez alguns EJBs joguem por uma boa medida. Existem alguns testes de unidade disponíveis, mas não muitos deles. Essas são coisas que me disseram, ainda não vi o código real.

Minha empresa fará uma proposta para reescrever partes deste aplicativo, a fim de reduzir a complexidade, melhorar a qualidade e a modularidade e possibilitarem adicionar novas funcionalidades mais fáceis sem regressões. Antes de assumir qualquer compromisso, eles gostariam de ter algum tipo de apreciação da qualidade do código existente e avaliar quanto disso pode ser reutilizado, a fim de ter mais do que um palpite no que terá que ser feito - completo reescrever ou reescrever parcial.

O problema é que vou ter que fazer isso em um período muito curto (alguns dias), por isso estou tentando elaborar um plano para o que pode ser feito em tão pouco tempo. O que estou Thiking é:

• Confira as coisas "básicas" - exceções de tratamento, registro
• Confira o nível de camadas (visualizações, controladores, camada DAO)
• Meça a cobertura real dos testes de unidade
• Talvez execute alguns estilo de cheque, findbugs e PMD sobre os projetos
• ...

Portanto, a questão real é que outras coisas devo levar em consideração/verificação/medida/etc?

Não tenho certeza de que tipo de números eu poderia obter disso e se isso realmente significaria algo, sinto que o que a gerência está perguntando é uma espécie de abordagem errada, então a segunda pergunta seria: alguém tem Uma ideia melhor?

Agradeço alguma ideia, sugestão, comentar sobre isso.

Editar: adicionarei dois detectores de código morto à mistura: Ucd e Dcd

Answer 1

Eu tinha dois aplicativos da Web com configurações semelhantes que você. Parei de usar o FindBugs e o Checkstyle, pois eles mostravam mais de 10.000 pontos problemáticos. Os aplicativos utilizaram acesso de dados de nível JDBC, JSP para apresentação e uma estrutura personalizada para despacho de solicitação. Felizmente para mim, essas configurações de baixo nível me permitiram fazer as extensões e correções com dificuldade média. Durante o projeto de três anos, apenas cerca de 20% do código original permaneceu como era. Mais cedo ou mais tarde, tudo o mais precisava ser alterado, substituído ou removido (e finalmente pude usar o FindBugs e o Checkstyle).

Também enfrentamos o dilema da reescrita completa. No entanto, houve vários fatores contra:

• Não tenho certeza se o cliente pagará por uma reescrita completa.
• A falta de documentação funcional e técnica torna arriscado fazer a reescrita completa.
• Manhours para entender completamente o aplicativo completo era muito alto. O cliente queria as alterações solicitadas mais cedo.
• Os usuários foram personalizados para a apresentação e o comportamento da página. Parecia difícil convencer os usuários a usar uma nova interface para funções antigas.
• Se fizermos uma reescrita completa, precisamos fornecer documentação completa. Para atualizar, precisávamos documentar apenas nossa parte.
• É difícil convencer a administração (própria e do cliente) de uma reescrita se o programa funcionar (mais ou menos)
• A empresa tinha suas próprias regras de PMD e o código não passou. Foi mais simples argumentar que basta que as novas peças passam no teste.

Isso resume o que você quer fazer na verdade.

Você quer reescrever, apesar da complexidade?

• Coloque ênfase nos erros de código. Grandes gráficos de pizza com muito vermelho são convincentes.
• Explique as propriedades do programa e como elas não se encaixam na visão corporativa.
• Mostrar opções de aprimoramento além dos requisitos atuais e descreva como a versão atual não está à altura do desafio.
• Faça entrevistas com os usuários reais. Eles podem apontar problemas importantes com a versão atual.
• Seja barato, mas um bom estimador. Você pode adiar alguns custos até a fase de manutenção.

Você não quer reescrever?

• Enfatize o custo, especialmente os Manhours exigidos do cliente para re-testar tudo.
• Aponte o problema potencial de quebrar a funcionalidade.
• Peça um escritor de documentos em tempo integral.

Se você quiser provar o código, tente adicionar o Hello World! função/tela para o aplicativo. Isso diz quão difícil e quão rápido você pode implementar coisas novas.

Answer 2

Na verdade, eles não pagarão por uma reescrita completa, porque:

• É recessão, o custo de você reescrevê -lo do zero será alto

• Eles podem estar tentando vender a empresa o mais rápido possível

• A gerência não entende nada sobre desenvolvimento de software

Eu iria primeiro com alguns fatos simples:

• Use uma ferramenta para exibir o sloc do projeto
• Corra enquanto planejava findbugs e, eventualmente, PMD, apenas para estimar os defeitos
• Faça uma sessão rápida de perfil
• Verifique as diferentes camadas
• Veja se os recursos geralmente estão fechados (fluxos, conexões de hibernação ou JDBC, etc.)
• Veja se as tecnologias são usadas onde não se aplicam (EJBS, Web Services etc.)
• Veja como eles lidam com exceções e registros
• Veja se há muito ou insuficiência abstração
• Veja se você poderia adicionar algumas classes base para reduzir a duplicação de código

Tente desenhar um diagrama rápido da arquitetura do aplicativo, se eles não lhe derem um documento sobre isso.

Reúna algumas estatísticas e alguns fatos, escreva um relatório e envie -os para a empresa. Eles vão querer minimizar os custos e pedirá que você evite a fixação do código que não está quebrado. Você começa com as estatísticas, depois para os fatos e uma proposta com o tempo/porcentagem aproximada do código afetado/preços.

Normalmente, os aplicativos de suportes legados são uma pita para manter, faz isso. Se não fosse parte do seu trabalho, eu diria que deixe para lá. Se você encontrar páginas "independentes" que não envolvem muitos modelos e estão sujeitas a muitas mudanças, proponha reescrevê -las com outra tecnologia.

Answer 3

Você está se concentrando na manutenção e extensibilidade que estão no local.

Eu acrescentaria olhando quanto tempo levará para reiniciar o projeto. Eles usam o controle de origem? Eles têm ambientes separados para integração e teste de aceitação do usuário? Existe um servidor de construção?

Quando você precisa passar dois meses antes da primeira melhoria, alguém precisa gerenciar as expectativas do cliente.

Answer 4

Eu gosto muito da sua lista. Eu acho que você tem um excelente plano de ataque para começar.

Eu olhava de olho na padronização da primavera ou do EJB 3.0, mas não em ambos.

Eu não li sozinho, mas me pergunto se o livro de Michael Feathers "Trabalhando efetivamente com o código legado" Tem boas idéias?

ATUALIZAR:

Talvez você possa ajudar as coisas colocando -as em uma construção automatizada e integração contínua - controle de cruzeiro, Hudson ou Team City. Se você precisar fazer alguma refatoração, isso ajudará.