Tenho meia década de experiência com Java, durante este tempo tive muita oportunidade de escrever código ruim, código legal e, principalmente, ver muita coisa hedionda. Programas feitos da pior maneira possivel, dígnos de serem chamados de jokeware. Apesar disso, posso afirmar que é possivel medir a qualidade de um software seguindo uma métrica muito precisa e facil de calcular. Esté é o resultado de um estudo conjunto de várias pessoas com muita experiência na industria.
A métrica é gerada a partir de dois componentes que estão diretamente relacionados com a capacidade dos desenvolvedores, boa aplicação de padrões de projeto e conhecimento da plataforma. O primeiro componente é a taxa de connection leaks, isto é, quantas requisições precisam ser feitas para que uma conexão com o banco de dados seja inutilizada. O segundo é a quantidade de exceptions que são descartadas em cada layer da aplicação.
Pode parece simples, mas tomando estas duas medidas é possivel ter uma idéia muito precisa do tamanho da encrenca. Entendo a origem de cada problema, podemos analisar e quantificar a qualidade do software e do time que produzir ele. Começando por Connection leak, que mostra claramente o desconhecimento básico de J2EE, assim como total desconhecimento de padrões de projeto comuns. Evitar connection leaks é mais simples que usar JDBC, então o que justifica alguém conseguir fazer um select e largar a conexão aberta?
Exception hidding é um caso bem pior, por causar muita dor de cabeça, chegando a fúria homicida contra os pobres infelizes que criaram o sistema. O sintoma é bem simples, o sistema da sumiço de uma exception, normalmente na transição entre tier da aplicação, já os efeitos são desastrosos, principalmente por tornar defeitos não rastreaveis. Existem duas opções quando teu código recebe uma exception e precisa lançar uma outra para o layer superior da aplicação: você pode usar exception-chaining (recurso que Java tem a 4 anos) ou gravar em log; nunca, mas nunca mesmo, descartar ou guardar somente a mensagem.
Eu ainda estou para conhecer um projeto que submetido a essa métrica não de uma imagem bem precisa da sua qualidade; assim como eu já aceitei que vou continuar encontrando essas coisas pela minha frente. Uma pena que seria bem dificil criar um software para calcular essa métrica, assim poderiamos evitar esse tipo de dor de cabeça mais facilmente.
9 responses so far ↓
1 Diego Pires Plentz // Mar 8, 2007 at 12:56 am
No cliente que estou alocado agora, o sistema legado tem o problema Exception hidding de forma gritante. É simplesmente impossível que um erro de banco (trigger, por exemplo) chegue na view. Inclusive acredito que eles achavam que isso nem dava pra fazer.
Quando começamos a desenvolvedor a nova versão e jogar os erros de triggers na view, foi uma alegria só. “Causos” da vida enterprise…
2 lavh // Mar 9, 2007 at 12:09 am
Exception hidding realmente é batata vc achar em qlq projeto….infelizmente…jah vi muito SCJP fazendo isso, o que me fez colocar em descredito essa certificação.
3 Phillip Calçado "Shoes" // Mar 12, 2007 at 11:44 pm
Tem um tempinho eu criei também aminha própria métrica: “você pode medir o quanto um código é ruim pela quantidade de ifs necessárias para implementar uma mudança.”. Claro que isso é só um plágio simplificado (!) de complexidade ciclomática mas… se alguém não sabe o que é polimorfismo vai entender complexidade ciclomática?
4 Phillip Calçado "Shoes" // Mar 12, 2007 at 11:45 pm
Tem um tempinho eu criei também aminha própria métrica: “você pode medir o quanto um código é ruim pela quantidade de ifs necessárias para implementar uma mudança.”. Claro que isso é só um plágio simplificado (!) de complexidade ciclomática mas… se alguém não sabe o que é polimorfismo vai entender complexidade ciclomática?
5 Leonardo // Mar 13, 2007 at 4:20 pm
O tema do post é ótimo e bem proveitoso.
Ah! Só uma correção. Não é conecção, hein! ConeXão.
6 Rodrigo Jardim // Mar 13, 2007 at 11:55 pm
ótima métrica :D
e concordo plenamente que com esta métrica bem simples se pode determinar facilmente a qalidade do sistema :D
7 Rafael // Mar 14, 2007 at 3:20 pm
Caro blogger, achei muito interessante essa sua métrica para qualidade de software, aliás concordei em vários pontos. Gostaria de saber como você faz para ter essa métrica. Mesmo não tendo softwares específicos para isso, você não deve sair vasculhando o sistema todo para encontrar connection leaks ou exception hidding, certo?
8 kumpera // Mar 14, 2007 at 3:34 pm
Rafael.
Por pior que soe, a melhor maneira de calcular esse métrica é com o sistema em produção. O número de connection leak você tira do número de vezes que precisa reiniciar o container devido a exaustão dos pools. Exception hidding você verifica analisando o log e descobrindo que falta informação.
.
O ruim da métrica que aqui apresentei é que para efeitos práticos, você só mede ela da pior forma possivel - quando o estrago já está feito.
9 André Barbosa // Mar 14, 2007 at 5:11 pm
Se o fulano ‘pega’ a Exception e não faz nada com ela é Exception hidding. E se o fulano não previu a Exception, o que é? Exception leak?
A propósito, eu gosto dessa métrica de ruindade de código do shoes, da quantidade de if´s.
Leave a Comment