Clean Code — Reflexões e dicas para o “Getting Started”
Neste artigo vou abordar as 5 principais técnicas do Clean Code que eu uso nas minhas aventuras cotidianas no desenvolvimento de software.
E claro, prepare-se para ver algumas referências ao clássico livro “Clean Code” do genial Robert C. Martin.
Apesar de essencial, muitos desenvolvedores não se preocupam com a qualidade do seu código, eles se preocupam em entregar o que foi pedido e se no final do dia o modal abrir quando o usuário clicar no botão, missão cumprida certo? Errado! Como isso foi feito? Você duplicou código? A missão falhou! Você fez um código que será necessário reescrever para dar manutenção? A sua missão falhou miseravelmente!
A lógica do “funcionou, então fiz meu trabalho” não pode existir e é perigosa. Já imaginou um médico ou engenheiro civil pensando dessa forma?
“Tornar seu código legível é tão importante quanto torná-lo executável.” — livro Clean Code
Bom, agora que desabafei um pouco, vamos ao que interessa. A primeira parte deste artigo será um misto de teoria e prática, vou expor algumas lições aprendidas na marra e claro na leitura do livro.
1 — Os detalhes importam (e muito!)
Absolutamente tudo, do mais alto arranha céu do mundo, ao menor chaveiro do mundo, tudo é feito de detalhes. Em 1986, o ônibus espacial Challenger explodiu 73 segundos após a decolagem, matando 7 pessoas. O motivo? Um anel de vedação de alguns centavos de dólares: Um detalhe.
Logo no começo do livro “Clean Code”, vemos a seguinte frase: “Deus está nos detalhes” dita por um dos principais arquitetos do século XX, Ludwig Mies van der Rohe. Você pode não ser religioso, e para o assunto em questão não é o cunho religioso da frase que importa aqui, mas se você parar para pensar, você é o Deus do seu código, onde antes tinha o nada (um arquivo vazio) você criou tudo. Você está nos detalhes do seu código, uma letra errada pode fazer todo o seu trabalho falhar, então sim, os pequenos detalhes importam.
“Quem é fiel no pouco, também é fiel no muito, e quem é desonesto no pouco, também é desonesto no muito.” — Lucas 16:10
Você consegue me dizer rapidamente qual o objetivo dessa função, só de olhar para ela?
E agora?
Bem mais fácil, né? Ficou mais fácil ao alterar um dos menores detalhes do seu código, os nomes que você escolhe para a suas variáveis e funções.
2 — Nomenclatura
Alguém já disse para você, que variáveis ou funções com nomes grandes são coisas feias? Responda que feio é demorar mais tempo que o necessário tentando entender um código. O seu código deve contar uma história, ele não deve ser um jogo de quebra cabeças, que algumas vezes nem o criador sabe como montá-lo.
Dicas:
- Não fique constrangido de dar nomes longos quando necessário;
- Dê nomes que façam sentido para o contexto do algoritmo;
- Caso ainda prefira nomes mais curtos, crie o hábito de isolar seus códigos em contextos menores, por exemplo, numa classe chamada EmailService, tudo bem criar um método chamado “send” ao invés de “sendEmail”, entretanto, se você não costuma seguir as práticas do SOLID (assunto para outro artigo) e tem uma classe chamada EmailAndSmsService, que envia e-mail e SMS tudo no mesmo lugar (sério, não faça isso), aí sim fica ruim ter um método chamado simplesmente “send” (por isso aprenda SOLID!).
3 — Não repita código (DRY)
Repetir código é um erro muito natural quando você não se importa em manter seu código limpo, desse erro vem uma piores consequências: o bug!
Eu gosto de pensar na repetição de código como uma armadilha que não escolhe alvo, pode ser você a cair nela!
Imagine o fluxo do seu algoritmo como um rio, a água passa por esse rio sem problemas do ponto A ao B:
Daí, alguém resolveu mexer nesse rio e separou uma pequena parte dele em dois (código duplicado), mas ele continua indo do ponto A ao B sem problemas.
Um belo dia, resolveram que a água não poderia mais chegar ao ponto B (alteração na regra de negócio). Logo, eles bloquearam o fluxo do rio.
Eles só esqueceram, que agora o rio tem 2 fluxos, que fazem a mesma coisa, mas precisam ser tratados individualmente, ou seja: mais trabalho, possíveis bugs e vergonha!
E como é isso na prática?
4 — Saiba qual andar do prédio você está criando
Você é um engenheiro e precisa construir um prédio. Você não vai pintar as fundações do seu prédio e deixar concreto exposto na cobertura. Certo?!
Ao desenvolver um software existem as chamadas “Camadas de abstração”. Basicamente, é você esconder detalhes da implementação daquela funcionalidade, para tornar mais fácil o uso dela por uma camada mais acima.
Por exemplo, a linguagem Assembly tem uma camada de abstração mais baixa, já a linguagem Java tem uma camada mais alta.
Vamos ao ponto que eu quero chegar aqui: Não escreva código complexo em código que deva ser simples.
Por exemplo:
5 — Você está comentando ou se desculpando?
Assim como a metodologia ágil prega menos documentação e mais ação, isso se aplica também na hora de programar seu software.
Somos parceiros das empresas que trabalhamos, como toda parceria existe uma troca: nossas entregas pelo nosso salário. Como a empresa consegue pagar nosso salário? Com mais e melhores entregas! Os clientes querem isso! Para equilibrar essa equação, precisamos desenvolver mais rapidamente e com mais qualidade. Os comentários gigantes em cada bloco lógico que você escreve, não vão te ajudar, vão te atrasar!
Ao mesmo tempo, é necessário que seja fácil dar manutenção no seu código, mas como podemos equilibrar essa balança? Uma solução para isso é, veja só, manter seu código limpo! Estude mais sobre o assunto, e por favor, leia o livro “Clean Code” e mire nesse objetivo:
Se faça entender pelo seu código, não pelos seus comentários.
Lógico que os comentários também são importantes em determinadas situações, saber onde colocá-los e onde não, também é parte da jornada de se tornar um programador melhor.
Na criação de um pacote de componentes de UI, por exemplo, é obrigatório você documentar como os componentes devem ser usados, quais parâmetros recebem, etc. Mas na parte lógica desses componentes, deixe que seu código fale por si.
Bom, se você é da ProJuris e leu até aqui, me mande um “oi” no Slack com seu feedback sobre o artigo. Caso não seja, pode me mandar uma mensagem nas redes sociais. ;)
No próximo artigo vou abordar “10 dicas rápidas para você programar mais e comentar menos”!
Forte abraço!
