Foto de Florida-Guidebook.com na Unsplash
Se você tem experiência com desenvolvimento de software, com certeza já se deparou com um projeto desorganizado, cheio de problemas e testes que, quando existem, não testam nada. Aquele tipo de código que você perde um tempão tentando entender como funciona e com medo de quebrar alguma coisa por acidente.
Vou dar algumas dicas pra que podem ajudar quando isso acontecer. Vamos lá?!
A Regra dos Escoteiros
A regra dos escoteiros de “deixar o acampamento mais limpo do que encontrou” é uma das principais lições que os escoteiros aprendem desde cedo. Ela foi criada pelo fundador do movimento escoteiro, Robert Baden-Powell, que acreditava que essa regra era fundamental para desenvolver responsabilidade e respeito pelo meio ambiente.
Essa regra pode ser facilmente aplicada no desenvolvimento de software, pois o “clean code” (código limpo) segue os mesmos princípios de deixar o código mais organizado e fácil de entender do que encontrou.
Vamos então às dicas de hoje!
Dica #1: Dê nomes significativos pra tudo
Dê nomes significativos para as suas variáveis e funções é tão importante quanto escolher um nome de batismo para seu filho. Nomes ruins podem causar confusão, erros e até mesmo traumas irreversíveis (brincadeira, mas é sério).
Por exemplo, chamar uma variável de “x” ou “valor1” não diz muito sobre o que ela contém. Isso pode levar a erros e confusão enquanto você está escrevendo código, e também pode tornar mais difícil para outras pessoas entenderem o que você está fazendo.
Além disso, se você tem muitas variáveis com nomes semelhantes, mas ligeiramente diferentes, isso pode ser uma fonte constante de erros. Por exemplo, se você tem variáveis chamadas “nomeCliente” e “nomeCliente2”, é fácil se confundir e usar o nome errado em um lugar.
Evite nomes engraçadinhos, variáveis de uma letra só (desculpem Golang devs ¯\_(ツ)_/¯), nomes fora do contexto, etc.
Dica #2: Encapsule grandes listas de parâmetros (4 ou mais) em tipos ou objetos de valor
Você já passou por isso, certo? Você tem uma função ou método que precisa de uma tonelada de parâmetros e não tem ideia de por onde começar. E então, você acaba colocando tudo junto e tentando lembrar qual é qual. E quando alguém mais precisa usar essa função, eles ficam perdidos e confusos. Pior ainda, se você precisar mudar algum parâmetro ou adicionar mais, é uma bagunça total.
É aí que entra o encapsulamento de parâmetros em tipos ou objetos de valor. Em vez de passar uma tonelada de parâmetros soltos, você os encapsula em um tipo ou objeto de valor. Isso ajuda a organizar os parâmetros e dar nomes significativos para cada um deles, tornando mais fácil para você e para outras pessoas entenderem o que está acontecendo. Além disso, se você precisar mudar algo, é muito mais fácil de gerenciar, já que tudo está em um único lugar.
Dica #3: Remova comentários inúteis e desatualizados
Idealmente, sua aplicação deveria falar por si só, e os comentários deveriam ser reservados a explicar lógicas complexas de negócio. Mas, como vivemos no mundo real, com toda certeza vamos nos deparar com comentários velhos, desatualizados, fora de contexto e até mesmo incorretos.
Dica #4: Don’t Repeat Yourself! (DRY)
Um sério problema de aplicações legadas e/ou mal feitas é a duplicação de código. Reduzir esse problema é o objetivo do princípio DRY (Don’t Repeat Yourself).
A duplicação de código pode causar vários malefícios às suas aplicações, como:
Manutenção mais complexa, pois requer conhecimento prévio da aplicação;
Alta concentração de bugs nas áreas desatualizadas, inclusive problemas de segurança, tornando a aplicação mais frágil;
Aumento da dificuldade para implementar testes, fazendo com que com o tempo eles deixem de ser escritos e/ou mantidos completamente
Para aplicar esse princípio, você pode:
Criar funções ou métodos que possam ser chamados em vários lugares do seu código, buscando manter um alto nível de modularidade no seu código para facilitar a reutilização e manutenção;
Usar herança e polimorfismo para criar classes genéricas que possam ser estendidas ou substituídas conforme necessário;
Utilizar bibliotecas ou frameworks já existentes para evitar a necessidade de escrever código do zero e, em alguns casos, reinventar a roda.
Dica #5: Encapsule condições
Essa dica está bastante relacionada a dica 1, pois faz com que o código fale por si só, reduzindo a carga cognitiva necessária na implementação/manutenção do software.
Antes:
Depois:
Repare que agora o resto da aplicação não precisa ficar duplicando essa regra de negócio, e assim o código fica mais simples e mais intuitivo.
Bonus: Evite condições negativas
Evitar condições negativas é uma boa prática para escrever código limpo e fácil de entender. Em vez de escrever “se não for verdadeiro, faça isso”, escreva “se for verdadeiro, faça isso”, tornando mais fácil para você e para outras pessoas entenderem o que está acontecendo. Condições negativas tendem a ser mais complexas e difíceis de entender, e podem acumular e tornar o código difícil de seguir, então evitando-as, você pode manter o código simples e fácil de entender.
Conclusão
Espero ter ajudado você! Essas dicas foram extraídas do livro Clean Code, escrito por Robert C. Martin, que é considerado um dos principais livros sobre boas práticas de programação. Este livro é uma fonte valiosa de conhecimento para desenvolvedores de todos os níveis de habilidade, pois oferece princípios e técnicas para escrever código de qualidade e mantê-lo limpo e legível.
É importante destacar que a prática de escrever código limpo é uma jornada contínua e que requer esforço constante. No entanto, aplicando as dicas apresentadas neste artigo, você estará no caminho certo para escrever código de qualidade que será fácil de entender, manter e escalar.
Código Limpo, por Robert C. Martin
É isso pessoal! Logo mais trago mais dicas práticas como essas 😉