Trash Pandas adoram código Java empresarial

Se os guaxinins fossem engenheiros de software, eles se sentiriam em casa dentro de muitos sistemas empresariais. Esses sistemas geralmente estão cheios de código não utilizado e morto que foi escrito, totalmente testado e depois alterado de uma forma que impede as equipes de executá-lo.

Esse código lixo – o favorito dos guaxinins – é um fardo de manutenção que os desenvolvedores devem contornar para continuar passando nos testes enquanto outras mudanças importantes são feitas. Esse código geralmente não vai para a lixeira porque é difícil saber o que pode ser removido com segurança sem quebrar o aplicativo. Mas você pode identificar melhor códigos incorretos se entender como procurá-los.

A maneira típica de identificar código morto ou não utilizado é por meio de análise estática ou revisão de log. IDEs modernos podem detectar código não utilizado e morto por meio de análise de acessibilidade, mas há um problema de solidez para classes e métodos que não são 100% privados. Se o código tiver um modificador de acesso público, ele poderá ser carregado e suas ferramentas nunca o reportarão.

Outras vezes, quando o código é rastreado, ele é executado em um teste de unidade – tecnicamente, esse código não está morto. Infelizmente, embora o design orientado a testes seja uma boa prática, há partes do código que estão ativas apenas porque um teste de unidade falha quando esse código é removido. Tudo o que estes testes fazem é verificar se a bagagem desnecessária cumpre o seu design original.

Embora a remoção do código não utilizado e morto faça com que o teste fique vermelho, os desenvolvedores também podem remover esse teste e acelerar o pipeline de construção geral, não tendo mais que executá-lo. A melhor maneira de obter uma visão completa de qual código pode ser descartado é monitorar separadamente os ambientes de teste e de produção e ver o que acontece.

Código não utilizado e morto é uma desordem

Muitas equipes têm uma atitude de “por que se preocupar”: quanto código não utilizado e morto pode realmente existir e por que isso é importante? Código não utilizado e morto é uma desordem que retarda o presente e o futuro. Cada vez que alguém trabalha no aplicativo, ele precisa contornar esse código. Quando uma mudança importante é feita, como a atualização do Java 11 para 17 ou 21, todo aquele código desnecessário precisa ser mantido. O pipeline de construção leva tempo para garantir que o código funcione, independentemente de o código ser importante.

Quando uma grande instituição financeira dos EUA decidiu identificar e remover código não utilizado, conseguiu “reduzir o tamanho de uma base de código em 67%”. A complexidade reduzida melhorou tanto a experiência do desenvolvedor que eles lançaram atualizações para o aplicativo mais de 250 vezes em um ano e finalmente atualizaram algumas das bibliotecas mais antigas que os impediam.

Um estudo semelhante do IEEE sobre um sistema de software industrial descobriu que até 50% de uma grande base de código não era utilizada ou estava morta, e a média geral era de 5% a 10% do código não utilizado ou morto. Quanto maior e mais antigo for um aplicativo, maior será a porcentagem.

Código não utilizado e morto em Java

Os engenheiros Java podem tratar a detecção de código não utilizado e morto de forma semelhante à coleta de lixo: escolha sua configuração e deixe a JVM fazer o resto. A questão de saber se o código é usado na produção é respondida se o método é alguma vez chamado (ou embutido). O registro dessa decisão é feito em um dos três locais: no interpretador de bytecode, no AppCDS (Application Class Data Sharing) ou no recurso ReadyNow da Plataforma Azul Prime. Se o método for usado novamente, não há necessidade de afetar o desempenho além da gravação da primeira chamada. O método foi usado na produção, portanto o código não fica sem uso ou morto. Nesse cenário, as execuções da JVM são marcadas com o “ambiente de aplicativo” para ajudar a registrar qual aplicativo chamou o método para um determinado ambiente. Manter esses ambientes separados ajuda a identificar casos em que o código e os testes unitários servem apenas para manter um ao outro vivo.

Monitorar o código para ver o que você pode jogar fora requer uma dimensão adicional de tempo. Até que você observe o aplicativo um pouco, grande parte do código não será executada. Aqui, as equipes geralmente separam o código morto em duas partes: coisas das quais elas acham que podem se livrar, mas sobre as quais não têm certeza, e coisas que precisam de mais tempo para serem vistas — geralmente com base em algum tipo de atividade periódica associada ao ciclo de negócios.

Os desenvolvedores podem suspeitar que certas partes do código não sejam utilizadas ou estejam mortas, mas não tenham confiança suficiente para excluí-lo. O caminho seria rastrear o inventário de código, realizar algumas ações na aplicação e ver se esses métodos foram relatados como em execução. Se estivessem, então o código está ativo; caso contrário, provavelmente não foi utilizado ou está morto. Outras funcionalidades, como um relatório de final de ano, precisam seguir seu curso para fazer a detecção. É por isso que é melhor monitorar a atividade do código ao longo do tempo. As vitórias curtas podem ser conquistadas cedo, e mais código pode ser descartado posteriormente.

O inventário de código reduz a confusão de código

O Inventário de Código da Azul difere das ferramentas típicas de análise estática e IDEs que detectam código inacessível. O monitoramento do Code Inventory ocorre a partir da JVM em execução para identificar classes inteiras ou métodos públicos que estão presentes, mas não são executados. É um localizador de desordem – um repelente de guaxinim. Ele identifica com precisão o código não utilizado e morto para remoção, detalhando com precisão qual código personalizado e de terceiros está em execução.

A detecção de código morto melhora a produtividade e a felicidade do desenvolvedor. É uma tarefa árdua manter código cujo único propósito é satisfazer um teste que garanta que o código desnecessário funcione. Ao detectar código não utilizado e morto, os desenvolvedores podem jogá-lo no lixo com segurança – um deleite saboroso para nossos amigos guaxinins.

O post Trash Pandas Love Enterprise Java Code apareceu pela primeira vez em The New Stack.