Quando, como e por que uma atualização de estruturas (Java)?


8

Breve resumo como introdução:

Somos uma pequena equipe de desenvolvimento web Java, criando aplicativos usando várias estruturas e bibliotecas como JSF, Hibernate, Seam, todas implementadas juntas no JBoss AS.

Inicialmente, o aplicativo foi montado e alguns recursos foram adicionados para formar uma vitrine para mostrar aos clientes em potencial. Ocorreram alguns polimentos, o aplicativo foi lançado, foi aceito e funcionando e, com o passar do tempo, recursos adicionais foram adicionados, bugs foram corrigidos, novos bugs ocorreram, como sempre.

Devido aos altos fatores de barramento e às corridas de inicialização, o desenvolvimento ficou um pouco fora de controle - foram adicionados mais e mais recursos, sem entender completamente a arquitetura principal do sistema. Ainda está funcionando, mas sempre existem armadilhas porque o sistema evoluiu de onde se originou para outra coisa e, no início, vários atalhos foram tomados para acelerar o desenvolvimento - agora tudo isso volta e o desenvolvimento fica mais lento, porque as soluções alternativas são usadas e bastante difícil introduzir novos desenvolvedores no projeto.

Agora, estou limpando e organizando as coisas - instalando um sistema de rastreamento de bugs, desenvolvendo uma cultura de teste / qualidade, pensando em como fazer testes automatizados, revisões de código (todas aquelas coisas profissionais sofisticadas que nos faltavam no início) e refatoração geral, como organizar hierarquias e funções de classe para facilitar o uso de coisas. Isso torna tudo um pouco melhor, mas ainda há muito o que fazer. Como não sou a pessoa que construiu o sistema inicialmente (o ex-programador líder deixou) e não é a mesma experiente (desenvolvendo há 2,5 anos, mas essa é a minha única experiência de 'mundo aberto' até agora), nem sempre tenho certeza do que Faz.

Aqui está o meu problema:

A refatoração é sempre algo bom e estou constantemente fazendo isso para facilitar as coisas, mas o que me intriga é quando, como e por que devo atualizar a arquitetura básica (ou seja, bibliotecas nas quais o sistema depende, servidor de aplicativos, banco de dados etc.)

Exemplos:

  • Atualmente, estamos usando o JBoss 4.2.2 - Eu li algum lugar do JBoss 7.1 já lançado, devo fazer isso? Como alguém pode avaliar isso?

  • Usamos o Seam 2.2, o que parece ser um grande bloqueador (não funciona em versões superiores do JBoss, não suporta o JSF2). Além disso, vejo fontes me dizendo para usar os recursos JEE em vez do Seam.

Basicamente, estou interessado em qualquer abordagem genérica para esses problemas, não apenas os mencionados nos exemplos acima - pois posso tropeçar nesses problemas para outra biblioteca em outro sistema em outro momento (ou alguém pode enfrentar problemas semelhantes) .

Então, qual é o objetivo? Devo estar atualizado e usar apenas bibliotecas de ponta ou devo ficar com o que tenho? Como reconheço, a tecnologia que estou usando é literalmente um cavalo morto e pula? Com que frequência essas atualizações de tecnologia devem aparecer?

E, outra pergunta ao lado do material geral 'como fazer atualizações'. Como reconheço que meu software pode ser chamado de 'criado por profissionais' ?. Existe um teste de Joel para software bem-feito, além do senso comum dos programadores?


1
A única resposta real para isso é 'depende'. Depende exatamente do que você é o produto, se versões mais recentes de estruturas ou bibliotecas que você está usando trazem vantagens significativas de desempenho, manutenção ou segurança, quão duro (bem, demorado) e bem equipado você está para fazer as alterações necessárias para faça seu software funcionar com as estruturas e bibliotecas mais recentes, e assim por diante.
Anónimo

Não estão falidos - não conserte.
Nikolay Fominyh

2
@NikolayFominyh Embora a mudança por causa da mudança seja ruim, esse tipo de atitude geralmente leva a um software mal mantido e mal compreendido, que quebra da maneira mais inconveniente possível. Como Martijn aponta, eventualmente o fornecedor descarta o suporte ou você precisa de uma correção de bug / segurança. Quanto mais você adiar as atualizações, mais difícil será.
R0MANARMY

"Nunca toque em um sistema em execução" parece simples, mas, na minha opinião, dependendo do ciclo de vida do sistema, nem sempre é um motivo. Se você já está no modo de manutenção, não gastaria muito tempo atualizando. Mas o sistema ainda está evoluindo e novos recursos são adicionados, portanto, manter-se atualizado será definitivamente necessário.
Volker

Respostas:


5

A resposta curta é que você alterna quando o esforço para não alternar excede o esforço de alternar ou quando pode prever que isso acontecerá em breve. Essa é uma avaliação muito subjetiva que requer experiência, mas é relativamente fácil ver os casos extremos.

Por exemplo, digamos que você calcule um mês para alternar, mas não alternar significa que você não pode usar um módulo que está disponível apenas na versão atualizada; portanto, você precisará de dois meses para implementar um a partir do zero. A escolha é fácil.

Por outro exemplo, se você está gastando todo o seu tempo corrigindo vulnerabilidades de segurança em software que não é mais suportado pelo fornecedor, é uma boa hora para mudar.

Se você nunca tiver reuniões em que alguém diga: "Isso seria muito melhor / mais fácil com a nova versão", provavelmente não será necessário mudar.

Os casos intermediários são mais difíceis de reconhecer, mas geralmente parece haver pressão crescente, onde permanecer com a versão antiga parece cada vez mais limitante.

No que diz respeito ao seu teste de software bem-feito, seu rastreador de erros fornece uma boa regra geral sobre isso. Quando você tem zero defeitos críticos e sua lista de defeitos não críticos está em um nível razoável e diminuindo constantemente, você pode chamá-lo de 'pronto'. Você pode ter uma noção da qualidade da arquitetura do software pelo tempo de resposta para adicionar novos recursos ou corrigir bugs. Não existe um ponto de corte que diga "isso é profissional", mas quanto menor, melhor.


Obrigado pelo teu conselho. Medir os custos de atualização versus permanência é um bom suporte à decisão e, olhando para o que temos até agora, a atualização parece ser realmente necessária. Aceitarei sua resposta, porque você forneceu vários outros pensamentos sobre o processo geral de desenvolvimento / atualização.
Volker

Ao mesmo tempo, fui solicitado a manter um aplicativo antigo do Visual Basic. A primeira coisa que aconteceu quando inseri o CD do Visual Basic no computador foi que o Windows exibiu uma tela de aviso de que este era um SOFTWARE NÃO SUPORTADO (ou algo semelhante a isso). Tomei isso como uma dica de que era hora de mudar.
Thorbjørn Ravn Andersen

9

Existem várias razões pelas quais você pode querer atualizar sua infraestrutura subjacente e deve avaliar cada uma delas da maneira mais empírica possível. Por exemplo, você pode atualizar porque:

  1. O fornecedor não está mais suportando a versão que você está usando
  2. Há um bug crítico ou correção de segurança
  3. Há um novo recurso que você deseja aproveitar
  4. Isso aumentará sua velocidade
  5. Há uma redução direta dos custos de capex na atualização (licença de suporte mais barata ou similar)

Esses motivos precisam ser ponderados novamente contra o custo da atualização, a maior parte gasta em testes. É aqui que o TDD / BDD realmente aparece, especialmente quando combinado com uma boa configuração de IC.

Isso significa que você pode "Refatorar rapidamente sem medo"

Se você não possui um conjunto de testes abrangente decente, significa que está testando manualmente, o que consome tempo e é muito suscetível a erros, aumentando o custo da atualização.


Obrigado pelo teu conselho. Configurar um ambiente de teste sólido e abrangente parece ser o caminho a seguir - o BDD parece bastante interessante e eu definitivamente darei uma olhada nisso.
Volker

3

As tecnologias que você listou são amplamente usadas, é fácil encontrar documentação para eles e pessoas que são proficientes com elas, então acho que não há motivo real para alterá-las. Por outro lado, eu recomendo atualizar suas estruturas para as últimas versões lançadas. Acho que você precisará fazer isso de qualquer maneira, mais cedo ou mais tarde (se não for para novos recursos e compatibilidade com bibliotecas mais recentes, depois para os bugs corrigidos em novas versões), e quanto mais cedo você fizer isso, menos tediosa será essa tarefa.

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.