Clean Code: Práticas Para Alcançar o One Piece da Codificação

Elegância, Legibilidade, Eficiência. Um desenvolvedor conquistou tudo que as boas práticas de programação tinham a oferecer, o Rei do Clean Code, Robert C. Martin. Antes de publicar o seu livro, suas palavras levaram multidões ao Código Limpo: “Querem minhas práticas de Clean Code? Fiquem à vontade para utilizá-las. Pratiquem! No livro está tudo que as boas práticas de codificação podem dar a vocês!”. Desenvolvedores cheios de esperança partiram em busca de escrever o código dos sonhos, em direção à Codificação Perfeita. E assim teve início a Grande Era do Clean Code.

No universo de One Piece toda boa tripulação pirata precisa de um bom carpinteiro/engenheiro naval para conseguir manter seus navios em bom estado para prosseguir com suas aventuras. No mundo da programação não é diferente, pois a manutenção de um software é tão importante quanto tê-lo funcionando. Em vista disso, é de suma importância a adoção de boas práticas no desenvolvimento de um software por parte do time.

Se você for uma pessoa ansiosa, pode estar se perguntando: ‘Como embarcar nessa aventura se nem sei por onde começar?’. Calma, jovem aventureiro, para isso, Robert Cecil Martin (ou Uncle Bob) apresentou em seu livro ‘Clean Code: a Handbook of Agile Software Craftsmanship’ (2008), que se tornou um best seller, a definição e técnicas de Clean Code (Código Limpo). Um guia de boas práticas que, se aplicadas corretamente, ajudarão você a alcançar o One Piece da Codificação - seu código rodando com maestria. Então, continue nessa jornada de leitura aqui que você receberá dicas de ouro.

Rumo ao Clean Code

A jornada até a última ilha é repleta de desafios. Para navegar na direção correta, é necessário um Log Pose, uma bússola que aponta sempre para a próxima ilha. Visando o Código Limpo, o Uncle Bob também fornece uma série de instruções que direcionam a um código de qualidade. Seguem algumas delas:

1 - Nomes Devem ser Significativos:

As Akuma no Mi, ou Frutas do Diabo, são frutas que conferem habilidades inumanas a quem as consome. Cada uma delas possui um nome único que as identificam e refletem com clareza seu poder.

Se a Gomu Gomu no Mi (Fruta da Borracha) do Luffy fosse chamada de Fruta do Esticamento seria um nome pouco significativo, visto que torna o poder do Luffy único ter um corpo semelhante ao de borracha - desconsideremos aqui as recém-descobertas.

Da mesma forma, é de suma importância nomear bem as variáveis, funções, classes e tudo mais, pois isso facilita o entendimento do código. Como por exemplo:

A primeira variável não apresenta um significado claro. Por outro lado, a segunda variável, com um nome descritivo, permite que a pessoa que estiver lendo o código entenda do que se trata tal variável.

2 - Funções Devem Fazer Apenas Uma Coisa

Na tribulação pirata dos Chapéus de Palha, cada membro é responsável por algo, Luffy é o Capitão, Zoro é o Imediato, Nami é a Navegadora, Sanji é o Cozinheiro, Usopp é o Atirador e assim por diante. Tais funções são essenciais para que todos possam ter sucesso na jornada ao One Piece.

Com as Funções em um código não é diferente, cada função deve ter uma especialidade única e responsabilidades claras, a fim de facilitar a compreensão e manutenção do código. Do contrário, uma função que visa realizar múltiplas tarefas, além de ser de difícil de entendimento, tendem ao erro.

No exemplo 1, a função navegar_destino tenta realizar mais de uma tarefa. Enquanto que no exemplo 2, a foram criadas duas funções para realizar, cada uma, tarefas específicas.

Esse tipo de ação contribui na compreensão, bem como na reutilização da função em outras partes do código e de fácil manutenção, uma vez que qualquer alteração que seja necessária será mais direta.

Seguindo esse raciocínio, o ideal é que quanto menos parâmetro uma função possua, melhor ela será de ser lida e testa, visto que, em caso de testes, quanto mais parâmetros uma função tiver mais desafiador será a combinação dos mesmos.

3 - Cuidado Com os Efeitos Colaterais

Efeitos colaterais acontecem quando uma função não realiza o que deveria (aquela uma coisa que deveria fazer) e/ou também realiza outras coisas fora de seu escopo, o que, inevitavelmente, ocasionará em execuções indesejadas em seu código. Um bom exemplo para se entender a importância de se evitar os efeitos colaterais são as mentiras do Grande “Capitão” Usopp, nosso atirador favorito adora contar histórias exageradas e, por vezes mentirosas, que geralmente acarreta em consequências inesperadas (geralmente cômicas) ao mesmo, como ter que bancar uma luta com um inimigo muito mais forte por ter mentido ao dizer que já lutou com milhares de outros guerreiros do mesmo porte.

Contudo, enquanto os efeitos das mentiras de Usopp são divertidas para nós telespectadores, os efeitos colaterais provenientes de uma função mal escrita podem resultar em problemas difíceis de rastrear e que afetarão outras partes do código.

4 - Repetir é Chato 

One Piece é uma obra muito longa, que mantém sua popularidade graças a criatividade e engenhosidade de seu criador, nosso querido Eiichiro Oda. Agora, imagine que cada arco de One Piece se repetisse em seus principais elementos narrativos, discutisse os mesmos assuntos, se os vilões tivessem a mesma personalidade e os mesmos desejos, e as ilhas tivessem as mesmas características. Seria enfadonho e difícil de manter o engajamento dessa obra, certo?

Felizmente, em cada novo arco encontramos diferentes vilões, ilhas e desafios diferentes a serem enfrentados pelos nossos piratas favoritos, assim até pode ser que exista algum arco ruim, mas ele pode ser compensado pelos demais arcos bons.

Evitar repetições no código é tão importante quanto vermos arcos diferentes, pois a duplicação código pode vir a se tornar uma amontoado de coisas que precisarão ser modificadas em caso da necessidade de alterações, do contrário comprometerá toda a execução. Assim sendo, um código bem estruturado e com o mínimo de repetições, diferentemente de One Piece, pode ser concertado sem danos maiores.

5- Chega de Comentários!

Uma boa tripulação pirata não precisa dizer um ao outro o que faz/tem que fazer, pois se comunicam com as próprias ações. O Luffy não precisa dizer para um companheiro doente que este deve procurar o Chopper para se tratar, pois ele já tem sua função e responsabilidades bem estabelecidas e reconhecidas no bando. Bem como numa batalha, cada um tripulante atua em sincronia pois já compreendem as intenções e habilidades um do outro.

No mundo do Clean Code é a mesma coisa, um código limpo e bem escrito dispensa comentários, pois ele é autoexplicável. Não é necessário, portanto, comentar que a variável rLuffy é recompensa do Luffy, se a variável já possuir o nome recompensaLuffy. Sobre isso, Uncle Bob, afirma:

"O uso adequado de comentários é compensar nosso fracasso em nos expressar no código. (…) Comentários são sempre fracassos. Devemos usá-los porque nem sempre encontramos uma forma de nos expressar sem eles, mas seu uso não é motivo para comemoração." 

Assim, parafraseando o Uncle Bob, antes de utilizar um comentário para explicar algo no código, tente explicar através do código em si.

6 - Formatação Importa

Ao lermos um código, seguimos um padrão comum. Geralmente, ele é lido esquerda para a direita e de cima para baixo, cada linha representa uma estrutura e cada grupo de linhas representa um pensamento completo. Uncle Bob orienta, portanto, que esses pensamentos devem ficar separados por linhas em branco. Voltemos ao exemplo de código da dica 2:

Da mesma forma que o Sunny (navio dos Chapéus de Palha) tem portas bem definidas para suas armas de combate com diferentes funções e poder de fogo. O código com espaçamentos verticais separa partes do código, como declarações, blocos de código e funções, de maneira clara e objetiva.

7 - Testar é Essencial

Assim como, ao consumir um Akuma no Mi, um usuário deve testar seus poderes recém adquiridos para saber se são funcionais numa batalha. Testar é uma parte essencial para que um código possa ser validado e considerado limpo. Para uma boa testagem, deve-se seguir algumas regras :

• Rapidez: O teste deve ser rápido, para que possa ser realizado várias vezes e em qualquer momento;
• Independência: Deve ser independente, para que não ocorra problemas de execução em outras partes em caso do surgimento de alguma falha, e permita uma análise mais apurada do problema;
• Repetibilidade: Deve permitir a repetição do teste diversas vezes e em ambientes diferentes;
• Auto validação: Devem retornar a respostas booleanas (true ou false), para evitar a subjetividade em alguma falha;
• Conveniência: Devem seguir à risca a pontualidade. E, idealmente escritos antes do próprio código, a fim de evitar que ele fique complexo demais para ser testado.

Conclusão

Assim como a jornada em busca do One Piece, é uma aventura repleta de desafios que requerem prática para que todos os membros da tripulação evoluam, cheguem a próxima ilha e derrotem inimigos cada vez mais fortes. O Clean Code é uma aventura que requer prática para que cada novo código criado evolua e seja melhor que o anterior, transformando códigos em verdadeiros tesouros para qualquer pirata (lê-se, desenvolvedor).

Referências

Capa: Gerada com Bing Image Creator (DALL-E).

Chagas, Vanderlei. 10 Boas práticas do livro Clean Code. Novatics, 2022. Disponível em: <https://blog.novatics.com.br/10-boas-pr%C3%A1ticas-do-livro-clean-code-6a19d4178fe1> Acesso em: 26 jun. 2023

Martin, Robert C. Clean Code: A Handbook of Agile Software Craftsmanship. 1st edition. Pearson, 2008.

Silva, Gizele. O qué é Clean Code e por que ele é impotante?. Coodesh. Disponível em: <https://coodesh.com/blog/candidates/metodologias/o-que-e-clean-code-e-por-que-ele-e-importante/#:~:text=Como%20surgiu%3F,%C3%A1rea%20de%20desenvolvimento%20desde%201970> Acesso em: 26 jun. 2023