Home	Sprints	Requisitos	Arquitetura	Configuração	Boas práticas	Git	Mockups	Banco de Dados	Instalação	Gerência de Projeto	Horários Disponiveis	Retrospectivas	[Testes] (Testes)

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 Developer 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.

Nomes

• Tudo em Inglês. listRecurso, findCaminho... isso confunde bastante.

Vamos respeitar os padrões de nomeação usados no Java:

• classes - substantivos, com a primeira letra de cada palavra em maiúscula: Investigador, OcorrenciaCrime.
• instâncias - em minúscula. Pessoa pessoa = new Pessoa().
• métodos - devem ser um verbo, seguido ou não por substantivos, com a primeira letra da primeira palavra em minúscula e as demais primeiras letras em maísculas: executarConsulta, cancelar.
• variáveis - primeira em minúscula, demais primeiras em maíscula. int nome, Date horaOcorrencia
• constantes - sempre em maiúsculas, com palavras separadas por underscores.
• Os nomes devem ser descritivos e concisos. Coisas como float x1, class AdcCnt... NÃO EXISTIRÃO
• Se você precisa contextualizar demais alguma coisa, talvez seja uma boa ideia criar uma nova estrutura específica para tal. Ex.: PrimeiroNomeAluno, EndereçoAluno... => classe Aluno, atributos Nome, Endereço...

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!
• Separação de responsabilidades: como iremos adotar o padrão MVVM, deve ficar muito claro o que cada coisa faz.

Voltar para a página principal