Boas Práticas na Escrita de código

Published in

RapaduraTech

6 min readJun 12, 2022

Por que se preocupar em escrever código com boas práticas?

Segundo Robert C. Martin, em Clean Code, um programador passa 10 vezes mais tempo lendo código do que escrevendo. Isso significa que a facilidade de leitura e entendimento de um código terá impacto direto na produtividade do time. A própria Oracle informa que 80% do custo de vida útil de um software são com os custos de manutenção do mesmo. Isso destaca que é preciso ter um olhar atento para que esse valor possa ser reduzido, e assim ser investido em outro setor.

Toda vez que uma alteração precisa ser feita, um código confuso demanda grande tempo de leitura e entendimento. No momento em que o tal código foi escrito, tanto a necessidade de negócio quanto a lógica que resolviam aquele problema estavam “frescas”, eram claras. Porém, em algumas semanas, após tratar outras diversas demandas, isso tudo já não está mais na sua cabeça. Ou seja, você mesmo vai precisar parar e entender o seu próprio código. E imagine uma outra pessoa tentando entender aquilo, talvez sem nenhum contexto, sem suporte…

Regras gerais

Algumas dicas do clean code

Siga as convenções, e você começou agora em um projeto ou acabaram de definir suas convenções, siga-as! Se utilizam por exemplo constantes em maiúsculo, enumeradores com E como prefixo, não importa! Siga sempre os padrões do projeto.
Utilize nomes que realmente expressem o seu conteúdo. Seja uma variável, uma classe, um método, um parâmetro, um arquivo. Vale a pena pensar bem nos nomes, pois vai economizar tempo no médio e longo prazo. É muito melhor utilizar um nome mais longo porém mais significativo;
Nomes de métodos, especialmente, devem descrever efetivamente seu comportamento. Melhor ainda se puderem estar associados a operações de negócios, por exemplo faturarPedido;
Métodos devem ser o mais curtos possíveis, e devem executar apenas uma tarefa. Aqui, deve-se pensar sempre em refatorar: você pode começar com um método mais procedural, que executa todas as operações necessárias, e depois ir dividindo em diversos métodos menores, cada um com apenas uma ação e com seu nome que deixa muito claro o que ele faz;
Comentários, normalmente, não são uma boa ideia. Se você sentir necessidade de explicar seu código por meio de um comentário, é porque ele está pouco claro. Tente aplicar as demais dicas e deixá-lo mais limpo e legível. Uma ideia interessante é, ao invés de adicionar um comentário, colocar algum tipo de log, explicitando ainda mais a ação, e utilizando dados que tornem esse log significativo ao precisar fazer um troubleshooting;
Procure usar uma padronização para nomes. Por exemplo, qual a diferença entre métodos com os nomes fetchDeliveries, getCustomer e retrievePayment? Todos buscam dados? Se todos eles executam a mesma operação, devem ter o mesmo nome, acompanhados do item que eles trazem, como retrieveOrder, por exemplo, estendendo essa padronização por toda a aplicação.

Técnicas e Exemplos

Controle de versão

Manter as diferentes versões de sua API o ajudará a rastrear as mudanças e a restaurar a versão anterior caso algo dê errado com a última. Considere um cenário em que você implementou uma API, implante-a e muitos clientes começarão a usá-la. Agora, em algum momento, você deseja fazer algumas alterações e adicionar ou remover os dados de um recurso.

Há chances de que ele gere bugs nos serviços externos que consomem a interface e alguns podem não ter como efetuar a mudança de imediato. Este é o motivo pelo qual você deve manter as diferentes versões de sua API. Da versão anterior, você pode obter o backup e trabalhar mais nele.

O controle de versão pode ser feito de acordo com a versão semântica. Não force todos a trabalhar na mesma versão ao mesmo tempo, você pode remover gradualmente as versões antigas de sua API assim que perceber que ela não é mais necessária. Na maioria das vezes, o controle de versão é feito com / v1 /, / v2 / etc. adicionado no início do caminho da API.

Polimorfismo no lugar de IFs

Um IF ou condicional, como o nome diz, traz uma tomada de decisão a nossa aplicação, o que implica no aumento da complexidade da mesma. No geral devemos evitar o uso excessivo destes.

Nestes cenários, opte sempre pelo polimorfismo ao invés de tomar decisão em todo método que cria.

Exemplo

Vamos tomar como base uma classe Pagamento, onde temos pagamento via Boleto ou Cartão de Crédito, porém nos pagamentos via Boleto, caso o dia do vencimento seja sábado ou domingo (Final de semana), o mesmo pode ser pago no próximo dia útil.

Note que temos duas tomadas de decisão dentro do método PodeSerPago, onde a primeira se refere apenas a pagamentos do tipo Boleto. Caso hajam mais formas de pagamento futuramente, como tratariamos este código? Encheriamos de IF?

A solução mais plausível é derivar da classe base Pagamento criando o PagamentoBoleto que sobrescreve o método PodeSerPago, dando uma nova funcionalidade a ele.

Lei de Demeter

A Lei de Demeter (LoD) ou princípio do menor conhecimento é um princípio que prega os seguintes pontos.

Cada unidade deve ter conhecimento limitado sobre outras unidades: apenas unidades próximas se relacionam.
Cada unidade deve apenas conversar com seus amigos.
Não fale com estranhos, apenas fale com seus amigos imediatos

Exemplo, segue classe base

Mau Exemplo, acesso direto

Bom Exemplo, acesso por “procuração”

Evite uso direto de strings

Quem nunca perdeu horas procurando um BUG que era apenas um problema de comparação de string? Evite digitar a mesma string várias vezes, utilize constantes para isto.

// Evite

if(environment == “PROD”)
…

// Utilize
const String ENV = “PROD”;
if(environment == ENV)

…

Opte por poucos parâmetros

Evite exigir muitos parâmetros para construção do objeto

Não tome decisões desnecessárias

Não utilize os famosos “flags” para tomar decisões dentro dos métodos, divida-os em vários métodos ou até mesmo outras classes.

Mau exemplo

Bom Exemplo

Utilize nomes pronunciáveis e buscáveis

Evite misturar idiomas, utilizar nomes difíceis de pronunciar ou inventar nomes e convenções para variáveis, classes e métodos. Lembre-se sempre da linguagem ubíquoa (que devem ser plenamente entendidos tanto por especialistas no domínio como por desenvolvedores) e da importância dela no código.