Métricas de Código Sprint 3
Alguns pontos levantados que poderiam ser melhorados foi repassado ao time de desenvolvimento e o que pode se notar nas métricas é que o time se mostrou disposto em melhorar o código. As métricas dessa sprint em sua mairia tiveram uma melhora quando comparada com as da sprint passada.
- LOC
O LOC da maior parte das classes permanece Ótimo, seguindo os parâmetros utilizados. As classes que não estão com o status de ótitma é a classe de criação da prescrição na view CreatePrescriptionView e a classe onde ocorre a validação dos 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 apresentou uma grande melhora ao da final dessa sprint. Pode ser observado algumas classes ainda com o nível REGULAR, mas muitas delas foram corrigidas para que os métodos fossem mais atômicos e executassem apenas uma função. As classes que estão REGULAR e possuem um nível alto na deve-se ao fato de que essas classes precisam de vários parâmetros e variáveis para sua inicialização. Mas a equipe de desenvolvimento foi alertada sobre tentar deixar o mais simples e coeso os métodos.
- 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.
-
Duplicação de código
-
Cobertura
A dificuldade em testar requisição de email nas classes que utilizam como a ConfirmPasswordView continua, a equipe está tentando testar essa funcionalidade. Essa sprint a cobertura se manteve alta, e a equipe de desenvolvimento merece ser reconhecida nesse ponto, eles entenderam de fato um dos principais pilares da metodologia ágil que é história pronta é história testada. A cobertura se subiu 2% em relação a sprint passada, isso evidencia que o time vem mantendo um ótimo nível de cobertura de teste durante toda a Release II.
