Orientação - Realizar a revisão do código-fonte

De Redome
Revisão de 21h07min de 15 de dezembro de 2017 por Admin (discussão | contribs) (Criou página com 'A revisão do código-fonte é uma técnica complementar a outros mecanismos de qualidade, como testes unitários e testes de sistema, adotados no processo de desenvolvimento...')
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para: navegação, pesquisa

A revisão do código-fonte é uma técnica complementar a outros mecanismos de qualidade, como testes unitários e testes de sistema, adotados no processo de desenvolvimento do Redome.

Esta técnica tem como objetivo garantir a qualidade do código fonte gerado pelo time de desenvolvimento, localizando possíveis erros da atividade de codificação.

Também tem por função homogenizar a forma do código-fonte produzido, facilitar e/ou promover a disseminação do conhecimento entre todos os envolvidos.

Checklist para code-review de código

Esta seção fornece alguns pontos de verificação gerais do que deve ser procurado em uma revisão.

Geral

  1. Verificar lógica e coerência do código
  2. Verificar coerência dos testes unitários
  3. Rodar os testes unitários
  4. Verificar se código está de acordo com o padrão de codificação definido.


TODAS as classes

  • Os métodos devem ser comentados (para o caso de métodos getters e setters utilize o eclipse para gerar automaticamente os comentários).
  • Código devidamente comentado com as anotações de autoria, parâmetros de métodos e retorno.
  • As classes devem ter em seu cabeçalho uma breve descrição sobre aquilo que ela faz.
  • TODAS as classes devem estar identadas de acordo com a padronização do arquivo disponibilizado com o responsável pela arquitetura.


Classes do pacote model

  • TODAS as classes devem ter os métodos equals e hashcode implementados (caso considere o ideal o eclipse gera automaticamente ambos os métodos).
  • TODAS as classes devem implementar Serializable.
  • As annotations JPA devem estar nos atributos.
  • Os atributos do tipo data devem utilizar a nova API do Java 8.


Classes de serviço

  • Caso exista a necessidade do serviço utilizar outro repositório, este deverá chamar a classe de serviço que está vinculada ao repositório e não diretamente o repositório.
  • TODAS as classes do tipo serviço devem ser anotadas com o @Service e @Transactional, somente na implementação e não a interface.
  • A classe deve ter seu devido teste unitário que valide todos os métodos que forem necessários.


Enums

  • TODOS devem assim como as classes ter a descrição no topo sobre do que ele se trata.


Interfaces

  • TODAS as interfaces devem ter o prefixo "I".
  • TODAS as interfaces devem ter uma descrição ao topo sobre o que ela se trata.
  • TODOS os métodos devem ter uma descrição sobre o que eles fazem e devem utilizar, caso seja necessário, as anotações de parâmetro e retorno.


Controladores

  • TODOS os controladores cujo retorno será um json devem ser anotados como @RestController.
  • TODOS os controladores devem ser testados com o Mockito

Métodos de persistência:

  • Devem receber o objeto a ser persistido como parâmetro e este parâmetro deve ser anotado com @RequestBody.
  • A anotação de @RequestMapping deve seguir o seguinte padrão: Ex.: @RequestMapping(value = "/entidade>", method = RequestMethod.POST)
  • Possíveis retornos:
  1. HttpStatus.CREATED: ao criar um novo registro
  2. HttpStatus.UNPROCESSABLE_ENTITY: erro de validação

Métodos de consulta

  • Devem receber os parâmetros (Caso não sejam um objeto de domínio) com a anotação de @RequestParam para cada um.
  • A anotação de @RequestMapping deve seguir o seguinte padrão: Ex.: @RequestMapping(value = "/entidade", method = RequestMethod.GET) @RequestMapping(value = "/entidade/{id}", method = RequestMethod.GET)
  • Possíveis retornos:
  1. HttpStatus.OK: ao retornar o registro
  2. HttpStatus.NOT_FOUND: se o registro com o id especificado não foi encontrado ou se é inválido

Métodos de atualização

  • Devem receber o id do objeto a ser atualizado.
  • A anotação de @RequestMapping deve seguir o seguinte padrão: Ex.: @RequestMapping(value = "/entidade/{id}", method = RequestMethod.PUT)
  • Possíveis retornos:
  1. HttpStatus.OK: ao efetuar a operação com sucesso
  2. HttpStatus.NOT_FOUND: se o registro com o id especificado não foi encontrado ou se é inválido
  3. HttpStatus.UNPROCESSABLE_ENTITY: erro de validação
  4. HttpStatus.METHOD_NOT_ALLOWED: se a deleção não for permitida

Métodos de exclusão

  • Devem receber o id do objeto a ser excluído.
  • A anotação de @RequestMapping deve seguir o seguinte padrão: Ex.: @RequestMapping(value = "/entidade/{id}", method = RequestMethod.DELETE)
  • Possíveis retornos:
  1. HttpStatus.OK: ao realizar com sucesso a operação
  2. HttpStatus.NOT_FOUND: se o registro com o id especificado não foi encontrado ou se é inválido
  3. HttpStatus.METHOD_NOT_ALLOWED: se a exclusão não for permitida


Front-End

  • Todas as classes de DTO, Components, Modules e Services:
  1. Devem conter ao topo da classe a devida descrição sobre o que se trata a classe em questão e a devida autoria utilizando a anotação @author.
  2. TODOS os métodos devem ter a devida descrição sobre o que ele faz e utilizar as anotações @param e @return.
  • Todos os métodos de validação e que se julgarem necessário devem ter testes como Jasmine.
  • Todos os métodos dos serviços ou que fazem interação com o servidor REST devem ser Mocadas.