GitLab

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.

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