Clean Code (Código Limpo)

O que são? Onde vivem? Do que se alimentam?

Você já deve ter ouvido falar sobre código limpo, mas quais são as características de um bom código?

Clean Code se refere a um conjunto de boas práticas de programação com o intuito de facilitar a leitura e escrita do código.

Essa citação do Martin Fowler é um bom resumo do que é um código limpo.

“Qualquer tolo pode escrever um código que um computador possa entender. Bons programadores escrevem código que humanos podem entender ”

Softwares vão sofrer atualizações, requisitos de negócios vão mudar, novas funcionalidades terão que ser adicionadas e por isso é tão importante que seja o mais limpo possível para a manutenção do código.

Na sua experiência na programação você já deve ter se deparado com um código confuso que te atrasou a realizar alguma alteração, ou até mesmo você já tenha feito um código que ficou difícil de entender.

Aqui pensamos em alguns possíveis motivos por isso ter acontecido:

· O prazo para entrega era curto

· Os requisitos mudaram durante o desenvolvimento

· O código já estava funcionando

E muitos outros, mas isso não é justificativa e a culpa é nossa. Nós programadores devemos defender a implementação de código limpo.

No livro "Código Limpo: Habilidades Práticas do Agile Software", do autor Robert C. Martin, ele usa o seguinte exemplo:

“E se você fosse um médico e tivesse um paciente que pediu que você parasse com toda essa besteira de lavar as mãos antes de uma cirurgia, pois estava demorando demais? Claramente o paciente é o chefe, mas o médico claramente deve negar o pedido do paciente. Por quê? Porque o médico sabe mais do que o paciente sobre os riscos de doenças e infecções. Seria uma atitude não profissional (sem falar criminal) se o médico aceitasse o pedido.”

Um bom programador é um programador que se importa com o código. Que o defende, para que tudo seja realizado com qualidade.

Legibilidade e produtividade

Imagine que você está se mudando e coloca todas as suas coisas em uma enorme caixa, e na hora de dormir após a mudança você tem que encontrar sua escova de dente. Que missão isso seria, hein!?

Agora imagine o mesmo cenário, mas dessa vez você separou em caixas menores e as etiquetou. Você encontra uma caixa chamada banheiro e dentro dela uma menor com o nome “Higiene pessoal”, você até suspira de alívio. Você ganhou tempo, passou menos raiva, sem contar com os elementos externos como sua esposa(o), falando que você não encontra nada (risos).

No código não é muito diferente, classes bem estruturadas, funções com nomes legíveis e intuitivos, códigos claros e necessários… o ganho de produtividade é grande, além da motivação do profissional em estar no projeto.

De modo contrário, a produtividade reduz drasticamente com o passar do tempo se a equipe de desenvolvimento não seguir as boas práticas de programação.

Recomendações

Agora que já sabemos a importância desse tema, a seguir veremos de quais maneiras podemos aplicá-lo no nosso dia a dia.

· Nomenclatura

Use nomes significativos que revelem seu propósito, o seu código conta uma história e como você a escreve é como será lida. As classes são como os capítulos, o nome das funções são os subtítulos e o método dentro delas são os parágrafos, que juntos formam o livro, a aplicação, que tem um objetivo maior.

Evite nomes com duplo sentido ou que confunda quem está lendo, não minta no que aquele trecho de código faz e use nomes pronunciáveis, não queremos no meio de uma reunião técnica falar que o método ykyrxz quebrou ou até mesmo descobrir em qual contexto ele está inserido.

Não use números mágicos em sua lógica, é difícil identificar o seu significado. Use uma constante para esse valor e dê um nome explicativo para ela.

Por convenção usamos substantivo(s) para classes, e objetos e verbos para métodos/funções.

· Funções

No livro de Robert Martin, ele cita duas regras para funções:

1ª: Funções devem ser pequenas

2ª: Devem ser menores ainda

Não podemos deixar de falar sobre o princípio de responsabilidade única (SRP) do Solid, que diz que um método deve desempenhar uma única tarefa. Métodos que tem mais que uma responsabilidade se tornam mais difíceis de serem reutilizáveis, além de serem mais complexos para entender, testar e dar manutenção. Quando um requisito muda, grande parte do código terá que ser alterado, pois está interligado. Se utilizarmos o SRP, a classe só terá uma razão para ser modificada.

· Comentários

Não comente o óbvio, use em casos extremamente necessários, comentários poluem o código e muitas das vezes não refletem a verdade, pois não são atualizados a cada manutenção. Comentários não devem explicar o código, o código tem que ser claro o suficiente, então é melhor usar nomes maiores que indicam o objetivo do trecho do que comentários. Se o código é muito confuso e precisa de comentários, é melhor reescrevê-lo.

· Padronização

Siga as convenções, inclusive estabeleça um padrão dentro do seu time. Se todos colocam ponto e virgula no final da linha, coloque também. Se você executa algo de uma maneira, execute todo o resto desta mesma forma.

Existem várias ferramentas que ajudam a estabelecer um padrão e a identificar problemas no código. Exemplos: prettier, eslint e sonarlint.

· Indentação

Faça indentação do código, mesmo que pareça simples ajuda muito a legibilidade. O seu uso facilita identificar a hierarquia e de qual linguagem aquele código representa, além de diminuir o esforço mental de quem está lendo. Como já citado anteriormente, crie código que humanos compreendam.

· DRY “Don’t Repeat Yourself” (Não se repita)

Você já deve ter ouvido a frase “Menos é mais”, isso se aplica para esse princípio. Evite repetições, elas aumentam a complexidade da manutenção, pois terá vários lugares para serem alterados e esquecê-los podem gerar bugs, assim como o aumento de processamento de dados.

· Kiss Keep It Stupid Simple (Mantenha isto estupidamente simples — KISS)

Escreva suas estruturas de código da maneira mais direta e simples, não crie débitos técnicos pensando antecipadamente, foque em programar de forma clara e concisa.

· Regra do escoteiro

“Deixe sempre o acampamento mais limpo do que você encontrou!”

Se todos os integrantes da equipe pensarem dessa forma, são grandes as chances de estarem criando bons códigos.

Conclusão

Como vocês perceberam, grande parte desse conteúdo foi baseado no livro Código Limpo, o qual recomendo fortemente a leitura. O livro é de leitura leve com muitos exemplos de programação que auxilia bastante na maneira de pensar ao programar.

Bom, encerro aqui, espero ter contribuído de alguma forma e deixo uma frase para você guardar no seu coração:

“Se você não tem tempo de fazer bem feito agora, quando terá tempo de fazer de novo?”

Referências

MARTIN, Robert. Código Limpo: Habilidades Práticas do Agile Software. ed. Rio de Janeiro: Alta Books, 2011.

<https://medium.com/desenvolvendo-com-paixao/1-clean-code-o-que-%C3%A9-porque-usar-1e4f9f4454c6>

<https://medium.com/desenvolvendo-com-paixao/2-clean-code-boas-pr%C3%A1ticas-para-escrever-c%C3%B3digos-impec%C3%A1veis-361997b3c8b5>

<https://programadorviking.com.br/clean-code-vale-a-pena-analise-completa-do-livro/>

<https://balta.io/artigos/clean-code>

<https://www.sydle.com/br/blog/clean-code-602bef23da4d09680935509b/>

<https://www.treinaweb.com.br/blog/dicas-para-manter-seu-codigo-limpo-e-legivel>

<https://medium.com/@alexandre.malavasi/caracter%C3%ADsticas-de-aplica%C3%A7%C3%B5es-web-modernas-bee638433212>

<https://stackify.com/solid-design-principles/>

<https://www.macoratti.net/16/04/net_dry1.htm>