Métricas de Código Sprint 4
O time de desenvolvimento vem mantendo um bom nível de manutenibilidade do código olhando as métricas no geral. Essas métricas servem para que o time mantenha um nível mínimo de qualidade no código, pois sabe-se que esse projeto será evoluído no fúturo.
- LOC
O LOC da grande maioria das classes permanece Ótimo, seguindo os parâmetros utilizados. Excetua-se a classe de criação da prescrição na view CreatePrescriptionView que apresenta um LOC considerado REGULAR, sendo necessário ter uma atenção maior à mesma. É aconselhado que o time dê uma revisada na mesma, para caso enxergue alguma funcionalidade que não deva pertencer a classe.
- AMLOC
A métrica de AMLOC mostrou-se coerente ao final dessa sprint. Pode ser observado algumas classes com um nível REGULAR, ou seja, que precisa de uma atenção maior conforme o decorrer das próximas sprints. Dessas classes julgadas como REGULAR, temos a ComposeView que por conta de se ter muitos atributos para serem inicializados ao se criar uma mensagem, teve um acréscimo na métrica, e a ConfirmPasswordForm que por mais que a métrica aponte o resultado 24 para a mesma, esse número é acrescido por conta de algumas variáveis da classe que não são colocadas em métodos, se formos contar as linhas da classe realmente, teriamos um AMLOC de 9.
Por fim, vale ressaltar que o time vem mantendo um nível BOM ou ÓTIMO no restante das classes.
- AMCC
O time vem mantendo um nível BOM ou ÓTIMO nesta métrico na maior parte das classes. Temos duas classes com o nível REGULAR, entretanto esse nível é obtido pela natureza dos métodos de validação, que tem um nível de complexidade ciclomática maior.
- CD
Para a métrica de densidade de comentários, a gente não consegue fazer uma boa análise apenas olhando a porcentagem de comentários em relação à quantidade de linhas, temos também que olhar a quantidade de linhas naquela classe, pois se uma classe apenas com 10 linhas receber 5 comentários, esse número seria referente à escala de nível PREOCUPANTE da métrica, entretanto isso não reflete na realidade.
Dito isso, podemos verificar que existem bastante classes com o nível PREOCUPANTE quando olhamos apenas para a densidade de comentários, mas se olharmos para a coluna de linhas da classe podemos verificar que boa parte dela tem o seu nível mascarado em decorrência da pequena quantidade de linhas da classe. Mas ainda assim podemos verificar uma grande quantidade de classes que estão com o nível realmente PREOCUPANTE, com 0 comentários. Uma parte dessas classes, foram classes novas criadas nessa sprint na história de criar uma Recomendação e a maior parte dessas classes são referentes a prescrição, que pelo tamanho muito pequeno de linhas da mesma os membros julgaram que não era necessário os comentários, entretanto vai ser pedido um pouco mais de atenção para essas classes na próxima sprint para que esse nível suba em relação à maior parte das classes.
- NLM
As classes continuam com um número ótimo de métodos. Verifica-se uma alta coesão e provavelmente uma alta granularidade das classes e, provavelmente, um relevante índice de manutenibilidade do código fonte.
- Cobertura
O time de desenvolvimento vem mantendo um ótimo nível de cobertura de teste durante toda a Release II, isso se dá por conta do critério de pronto adotado nas histórias onde uma história só pode ser aceita se mantiver a cobertura de código anterior. Entretanto podemos ver ainda algumas classes com o nível de cobertura bem pequeno ConfirmPasswordView e UpdatePasswordView, isso se dá por conta da dificuldade que a equipe vem tendo em testar a requisição de email.
