Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • A ALFA Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ALFA
  • ALFA Wiki
  • Wiki
  • Boas Práticas

Last edited by Marcelo Henrique De Souza Nov 16, 2021
Page history

Boas Práticas

Home Arquitetura Banco de Dados Boas Práticas Configuração Escopo Instruções Mockups POC Amazon Padrão MR Processos

Seguir o padrão de estilo de código definido para o projeto

  • Nomenclatura de em inglês.
  • Indentação do código.

Não reinventar a roda

  • Manter a estrutura de pastas definada.
  • Verifique se o que você precisa já não foi criado (componente ou método), antes de sair codando.

Garantir que o código é legivél

  • Lembre-se que haverá revisão de código por outros membros do time, portanto tente o deixar mais legível possível para um melhor entendimento, e para reuso de outros membros da equipe para demais tarefas que possam a vir a necessitar a utilizar o foi criado por ti.

Comentar e Documentar

  • Todos são responsáveis pela qualidade do código, sugestões e novas ideias são bem vindas, caso tenha alguma ideia ou insight sobre algo que poderia ser melhor, comente com o time.

Teste o seu código

  • Valida o que foi feito, fazendo um teste de ponta a ponta caso houver integração na tarefa que esteja fazendo, em caso contrario, valide com mocks a tarefa criada no front, ou pelo postman fazendo requisições para o backend.

Evitar hard-coding

  • Sempre que possível evite valores soltos no código a qualquer custo, em vez disso utilize constates e especifique um nome descritivo que dê significado a aquele valor.

Nomes descritivos ou contextuais

  • Ao nomear métodos, variáveis, constantes, classes, etc. Busque dar nome descritivos a funcionalidade, ou ao seu contexto.

Colaboração

  • Ajude quando puder e peça ajuda quando precisar, somos um time.
Clone repository
  • Arquitetura
  • Banco de Dados
  • Boas Práticas
  • C4 Model
  • Configuração
  • Escopo
  • Instruções
  • Mockups
  • POC Amazon
  • Padrão Merge Request
  • Processos
  • Home