Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W 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
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Rotas Rurais
  • Wiki
  • Wiki
  • Boas Práticas

Boas Práticas · Changes

Page history
Create Boas Práticas authored Mar 29, 2023 by Martin Ferreira's avatar Martin Ferreira
Hide whitespace changes
Inline Side-by-side
Boas-Práticas.md 0 → 100644
View page @ 1853968b
|[Home](home)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Banco de Dados](banco_dados)|[Instalação](instalacao)|[Gerência de Projeto](gp)|[Git](git)|[Boas Práticas](boas-praticas)|[Merge Request Template](mr-template)|
|---|---|---|---|---|---|---|---|---|---|---|---|
# *Boas práticas*
O cliente pode não se interessar se o código de um sistema esta bem ou mal escrito, mas nós devemos ter essa preocupação - até porque, com um código limpo, a entrega para o cliente fica mais fácil.
Aqui vão algumas práticas que ajudam a melhorar a produtividade de um projeto. Obs.: iremos fazer nivelamento da equipe, então não se preocupem se aparecerem coisas que ainda não viram.
#### Definição de Pronto
* Merge realizado na Dev sem conflitos.
* Testar a funcionalidade desenvolvida.
**Regra básica**
Pense antes de sair loucamente desenvolvendo. Faça um esquema, escreva em papel. Divida o seu problema em problemas menores, e em como tais problemas se ligam.
****Código****
* **Tudo em Inglês.** listRecurso, findCaminho... isso confunde bastante.
**Métodos, funções**
* Métodos e funções têm papeis específicos. Se o seu método parseia uma string, pegar informações do HTML da página e acessa o banco, você tem TRÊS métodos, e invoca eles quando necessário.
* Blocos de código devem ser curtos sempre que possível. Se o seu bloco tem mais do que 50 linhas, considere refatorar.
* Níveis de abstração (isso pode ser um pouco complicado de pegar, então, ignore se não se sentir confortável): para garantir que sua função faz UMA coisa, tente manter todos as ações no mesmo nível de abstração. No exemplo acima, mesmo que tenhamos três funções, ainda assim não é boa ideia chamar todas elas no mesmo bloco - HTML, manipulação de strings e acesso a banco são três coisas bem distintas.
**Estrutura**
* Identação sempre! -> Instalar o plugin EditorConfig do Visual Studio Code que já temos uma configuração padrão no projeto, ele deve funcionar sem ter que fazer nenhuma modificação.
* Separação de responsabilidades: respeitar o padrão de projeto definido!
\ No newline at end of file
Clone repository
  • Boas Práticas
  • Gerenciamento do Projeto
  • Git
  • Qualidade
  • arquitetura
  • banco_dados
  • configuracao
  • cronograma
  • Home
  • instalacao
  • mockups
  • requisitos
  • sprints