Pular para o conteúdo principal

Boas Práticas e Padrões de Código​

Quem não seguir os padrões, paga o açai e o pão de queijo!​

Adotar boas práticas e padrões de código é crucial para a manutenção e escalabilidade de projetos de software, especialmente em ambientes de equipe. Essas convenções ajudam a garantir que o código seja limpo, compreensível e eficiente.

Localização das Regras de Negócio​

  • Regras de Negócio: Devem ser mantidas no pacote service, garantindo que a lógica esteja centralizada e separada da lógica de apresentação e acesso a dados.

Estrutura e Ordem do Conteúdo das Classes​

  • Ordem do Conteúdo das classes: As classes classe devem seguir a seguinte ordem para facilidade de leitura

    • @NoArgsConstructor
    • @Getter
    • @Setter
    • Variáveis estáticas
    • Variáveis de instância
    • Construtores
    • Métodos públicos
    • Métodos privados auxiliares (ordenados logicamente ou por visibilidade)

Nomenclatura e Convenções​

Quebra de Linha e Formatação​

  • Ao atingir 120 caracteres, uma quebra de linha deve ser inserida. Configuração recomendada em IDEs como IntelliJ IDEA para manter a uniformidade no projeto.

Evitar Acentuação​

  • Não utilize caracteres acentuados no código para evitar problemas de encoding e interoperabilidade entre diferentes ambientes de desenvolvimento.

Métodos e Variáveis​

  • Os nomes devem ser significativos e autoexplicativos, refletindo claramente o propósito da variável ou ação do método, evitando abreviações e promovendo a clareza.
    • Exemplos de Variáveis: questao, questaoEntity, qQuestaoEntity
    • Exemplos de Métodos: adicionarQuestoesAoMaterial, buscarQuestoesPorTexto, atualizarOrdem

Domínio​

  • Utilize o nome diretamente para classes de domínio, sem prefixos ou sufixos adicionais.
    • Exemplos: Questao, Material

Entidades de Persistência​

  • Sufixo Entity: As classes que representam entidades de persistência devem ter o sufixo Entity.
    • Exemplos: QuestaoEntity, MaterialQuestaoEntity

Variáveis de Relacionamento na Persistência​

  • As variáveis que representam entidades relacionadas devem ter o sufixo Entity para clareza e consistência.
    • Exemplos:
      • private TopicoEntity nivelAnteriorEntity;
      • private TopicoEntity topicoEntity;
      • private DisciplinaEntity disciplinaEntity;

Nome da Tabela de Persistência​

  • O nome da tabela especificado na anotação @Table não deve incluir o sufixo Entity.
    • Exemplos:
      • @Table(name = "topico")
      • @Table(name = "topico_disciplina")

Chave Estrangeira da Persistência​

  • As chaves estrangeiras devem ser nomeadas sem o sufixo Entity, mas devem terminar em _id para indicar claramente a sua função.
    • Exemplos:
      • @JoinColumn(name = "nivel_anterior_id")
      • @JoinColumn(name = "topico_id")
      • @JoinColumn(name = "disciplina_id")

Variáveis do QueryDSL​

  • Prefixo q: Utilize o prefixo q seguido do nome da entidade e o sufixo Entity.
    • Exemplos: QQuestaoEntity qQuestaoEntity, QMaterialQuestaoEntity qMaterialQuestaoEntity

Separação de Lógica de Consulta​

  • Encapsule lógica de consulta em métodos privados para manter os métodos públicos limpos e focados.

Padronização de Mensagens​

  • As mensagens, especialmente as de erro, devem ser claras, corretamente pontuadas e sem erros de português. Utilize o arquivo messages.properties para facilitar a gestão.

Nomenclatura Específica de Classes​

Ex:​

  • Controller: NomeDaClasseController

  • Api Mapper: NomeDaClasseApiMapper

  • DTO: NomeDaClasseDTO

  • Service: NomeDaClasseService

Parâmetros de Métodos​

  • Quantidade de Parâmetros: Minimize a quantidade de parâmetros em métodos. Idealmente, um método não deve ter mais de três ou quatro parâmetros. Considere usar objetos de transferência de dados ou padrões como Builder para métodos com muitos parâmetros.

Penalidade​

  • Adesão aos Padrões: É crucial que todos na equipe sigam esses padrões. Quem não seguir, pode ser encarregado de trazer açaí e pão de queijo para o resto da equipe!!!.