Métricas de Código Sprint 6
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 validação dos campos referentes ao usuário UserValidator que permanece com um LOC considerado BOM, não é necessário nenhum tipo de intervenção pois a métrica indica uma provável facilidade de manutenibilidade do código fonte, mesmo piorando um pouco.
A única classe que podemos ver um problema ainda é a CreatePrescriptionView, ela apresenta um nível preocupante, mas como já dito em análises passada é observado que ela é o core da aplicação e por isso é uma classe que tende a ser, relativamente, maior que as demais.
- AMLOC
A métrica de AMLOC mostrou-se coerente ao final dessa sprint. A métrica de AMLOC se manteve da mesma forma da sprint anterior em grande parte das classes. Pode-se ver que grande parte das classes que estão em nível REGULAR são responsáveis por validação de campos de formulários. Além disso, pode-se avaliar que ainda que as classes que tenham o maior índice, ainda estão longe de se tornar preocupantes.
Por fim, vale ressaltar que o time vem mantendo um nível BOM ou ÓTIMO no restante das classes.
- AMCC
A métrica AMCC permanece em nível BOM sendo que as classes que apresentam um nível REGULAR são aquelas, que assim como na métrica anterior, responsáveis pela validação dos campos de formulários, utilizando vários caminhos para que se possa verifica os campos.
- CD
- 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
| Cobertura |
|---|
| 95% |
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.
