Antes de iniciar a revisão

  • O revisor deve ler e compreender a demanda. Caso o pedido não esteja claro, o MR poderá ser fechado.

  • Tratando-se de demanda categorizada como defeito, o revisor deve simular o defeito utilizando o branch master. Não ocorrendo, o revisor pode fechar o MR.

  • O revisor deve atualizar o branch da demanda com o branch master e executar os scripts de migração (quando houver) utilizando o flyway. Caso ocorra conflitos ou falha na execução de algum script da demanda, o revisor poderá optar por corrigir ou fechar o MR.

  • O MR deve ser fechado caso possua arquivos completamente modificados. Isso indica que o caractere de final de linha foi alterado.

  • Caso o MR possua mais de um commit, o revisor será responsável por realizar o squash dos commits de forma que só haja um commit.

Durante a revisão

Classes
  • Observar a responsabilidade das principais classes do sistema

    • Classes responsáveis por tratar as requisições do usuário: Classes com sufixo Home e Action.

    • Classes responsáveis por manipular entidades de negócio: Classes com sufixo Home, Manager e DAO.

    • Classes responsáveis por lidar regras de negócio que envolvam mais de uma entidade de negócio. Classes com sufixo Service.

    • Classes utilitárias: Classes com o sufixo Utils.

  • Utilizar Javadoc para documentação.

  • Deve-se utilizar um substantivo para o nome.

  • Não devem ser criadas novas classes com o sufixo Home.

Métodos
  • Utilizar Javadoc para documentação.

  • O nome deve expressar uma ação. Ex.: recuperaXPTO(), verificaXPTO(), validaXPTO(), listaXPTO().

  • Verificar se os modificadores de acesso estão adequados à utilização do método.

  • Verificar a nulidade dos argumentos antes de sua utilização.

  • Verificar se o método está coeso.

  • Deve-se evitar mais de um ponto de retorno.

  • Métodos acessores (get/set) não devem ser utilizados dentro do escopo da classe. Utilizar a própria variável.

Scrips
  • Devem ser reexecutáveis.

  • Instruções de DDL e DML devem estar em arquivos separados.

  • Não devem conter IDs de registros.

Arquivos xhtml
  • Não devem conter estilos inline.

Ao finalizar a revisão

  • A issue deve necessariamente conter a descrição dos cenários de testes realizados juntamente com a evidência (foto e/ou vídeo).

  • Incluir no Gitlab o label de aprovação. Ex.: Revisores do CNJ só poderão incluir o label Aprovado CNJ.

Observções

  • Mantenha o código simples! O desenvolvedor deve realizar o mínimo de alterações para resolver o problema.

  • O código não deve ser refatorado, salvo quando necessário. Ex.: Alteração de método cuja regra de negócio não faça parte da responsabilidade da classe onde está inserido.

  • Não reinvente a roda.

  • Evite processamento desnecessário.

  • Não polua o código.

    • Código comentado deve ser excluído.

    • Imports, variáveis e métodos não utilizados devem ser excluídos.

    • Não utilizar comentários que contenham menção ao nome do desenvolvedor, tribunal ou número da issue. Essas informações devem constar na mensagem de commit.

    • Não utilizar comentários que indiquem a realização de uma tarefa posterior. Ex.: TODO.

    • Evite quebras de linha desnecessárias. No máximo uma quebra de linha como forma de organização do código.

  • Evite código duplicado. Faça uma verificação tomando como referência todo o projeto.

  • Para blocos de código que contenham apenas uma instrução, deve-se utilizar chaves.

  • Evite o anti pattern Magic number

  • Deixe o código menos verboso:

    • Utilize a notação de diamante em atribuições quando utilizar generics. Ex.: List<String> cars = new ArrayList<>();