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
A métrica de densidade de comentários está sendo um pouco problemática, pois não está se mostrando uma análise efetiva apenas olhar a porcentagem de comentários em relação à quantidade de linhas. A equipe de medição está também olhando no próprio código a quantidade de linhas naquela classe, pois se uma classe pequena com 10 linhas receber apenas os comentários que a comunidade recomenda que seriam comentário de classe, comentário de imports e comentários de métodos já apontaria na ferramenta um nível PREOCUPANTE da métrica, entretanto isso não reflete na realidade.
Uma boa parte das classes que o grupo de desenvolvimento criou possui uma baixa quantidade de linha o que acontece exatamente como discutido a cima. Algumas classes demonstram uma atenção especial por não possuírem comentários, isso aconteceu nas maiorias das classes que foram criadas essa sprint como a classes relacionadas a criação de uma prescrição que foram criadas para atender as novas necessidades do cliente. A equipe de desenvolvimento já foi alertada para comentar melhor as classes que forem criadas nas sprints futuras e as classes que apresentaram-se críticas é preciso
- 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.
