Skip to content

Métricas de Código Sprint 0

Ronyell Henrique dos Santos edited this page Oct 24, 2017 · 3 revisions

Após o término da Release I foi notado uma série de pendências. As pendências priorizadas envolviam a aplicação de técnicas de programação e algumas dívidas técnicas. Como os membros de GPP não participaram do desenvolvimento durante a sprint de refatoração, não houveram muitas mudanças no quadro geral da qualidade do software.


Resultados

  • LOC

LOC

O LOC de todas as classes permanece Ótimo, seguindo os parâmetros utilizados. A sprint de refatoração e de dividas técnicas não trouxe muitas alterações nesse quesito.

  • AMLOC

AMLOC

Observa-se que grande parte das classe continuam com AMLOC aceitável. As classes HealthProfessionalForm e PatientForm aumentaram a quantidade média de linhas por método,de forma oposta, outras classes como a UpdateUserForm melhoraram em relação a essa métrica.

Em relação as classes em nível crítico foi constatado a necessidade de novas validações nos campos presentes, por isso mais código foi inserido nessas classes, as tornando maiores, e por consequência os métodos também ficaram maiores. Recomenda-se que as classes nesse nível de criticidade sejam refatoradas, com atribuição de métodos para validação de cada campo, ou que as validações dos campos sejam atribuídas a outras classes.

  • AMCC

AMCC

Observa-se que grande parte das classe continuam com AMCC aceitável. As classes HealthProfessionalForm, PatientForm e UpdateUserForm aumentaram a complexidade ainda mais.

Como relatado no tópico acima, a complexidade também aumentou pela necessidade de novas validações nos formulários. Da mesma maneira citada acima, recomenda-se que as classes nesse nível de criticidade sejam refatoradas, com atribuição de métodos para validação de cada campo, ou que as validações dos campos sejam atribuídas a outras classes.

  • CD

CD

As classes continuam com nível crítico em relação à porcentagem de comentários. Mesmo que a maioria esteja em estado crítico, observa-se que algumas dessas classes são muito pequenas e os integrantes do grupo julgaram não necessitar de comentários.

Mesmo que algumas classes não precisem de comentários, alguns comentários padrões, como comentários de classe, são necessários para um melhor entendimento do código.

  • NLM

NLM

As classes continuam com um número ótimo de métodos. Mesmo assim deve-se verificar a necessidade da dissolução de métodos muito complexos ou criação de novas classes, como classes de validação, visto que algumas das métricas acima continuam em estado crítico por conta da atribuição de muita responsabilidade a um único método, o sobrecarregando.

  • Duplicação de código

CR2

CR2

CR2

Com a utilização do codeclimate foi coletado os trechos de código que estão duplicados, existem NOVE trechos de código duplicados. Alguns desses trechos são trechos de código comentados, portanto, não é tão relevante para que seja considerado crítico.

  • Cobertura

CR1

CR3

Em relação a cobertura observada no final da Release II a cobertura cresceu em torno de 5%, todavia, observou-se a dificuldade de testar requisição de e-mail para criação da conta. Dessa forma os arquivos,como confirmpasswordview.py, resetpasswordview e loginview , relacionados a essa funcionalidade não conseguiram atingir o valor esperado .

Grupo 2

logo

Release II

Equipe

Sprints

Sprint 0

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Sprint 7

Sprint 8

Release I

Gerência do Projeto














Desenvolvimento de Software

Clone this wiki locally