Como tema de seu projeto do Bluesoft Labs, Bruno Lui leu o livro Clean Code, fez duas apresentações e escreveu o artigo que segue. Foi notável a diferença que a leitura deste livro fez em seu dia-a-dia, transformando não somente sua forma de escrever software mas também a de todos os outros membros da equipe que foram, no bom sentido, contaminados pelo Clean Code.
Gostaria de destacar que assistir a apresentação e ler a este artigo não substitui de forma alguma a riquíssima experiência da leitura desse livro, leitura que recomendados a todos os desenvolvedores que buscam tornarem-se melhores. O livro está disponível para venda em português e inglês.
Confira os videos e os slides no final do post.
O primeiro objetivo dos desenvolvedores quando criam uma funcionalidade é fazê-la funcionar. Tudo bem, está funcionando, mas e o código, como esta? Será que o código que faz tudo funcionar está legível, fácil de ser entendido, ou seja, será que está limpo?
É preciso preocupar-se com o código, garantir que está legível e bem escrito, pois somente o próprio código pode dizer de forma confiável o que o software realmente faz.
No livro Clean code escrito por Robert C. Martin, conhecido na comunidade de desenvolvimento de software como Uncle Bob, pode se encontrar várias técnicas e boas práticas para que se aprenda a melhorar a forma que se escrever código e deixá-lo mais limpo e claro. O livro ensina também a identificar um código ruim e melhorá-lo.
Mas afinal, o que é código limpo?
- Elegante (distinto)
- Eficiente
- Legível
- Simples
- Direto
- Único, sem duplicidades
- Bem escrito
- Deve ser escrito cuidadosamente
- E deve sempre possuir UMA responsabilidade
O código é importante e deve agregar valor ao negócio. Somente um código limpo pode oferecer a qualidade e entendimento que esperamos quando abrimos uma classe. Portanto é necessário que seu código seja limpo e legível para que qualquer um que encontrá-lo possa facilmente entendê-lo evitando perda de tempo e facilitando o trabalho de todos.
Cada capítulo do livro aborda um aspecto diferente da codificação, e ao passo se lê, as coisas vão se complementando e é possível notar que tudo tem seu jeito “limpo e claro” de ser feito. A seguir exploraremos um pouco do que Uncle Bob nos ensina.
Nomes significativos
Faça distinções significativas, use nomes diferentes dentro de um mesmo escopo. Nomes como a1, a2, a3 são o oposto de nomes que demonstram intenção. São confusos e não informam nada. Evite também usar abreviações ou trocadilhos, escreva exatamente o que você quer dizer, o nome deve ser auto-explicativo. É comprovado que um desenvolvedor passa muito mais tempo lendo código do que escrevendo, por isso não se preocupe em economizar caracteres ao escolher um nome, o fato de um ser claro e objetivo poupará muito mais tempo do futuro do que os caracteres a menos que você digitar ao escolher um nome curto e ruim.
Métodos e funções
O que os tornam métodos e funções fáceis de se ler e entender? A primeira regra dos métodos é que eles devem ser pequenos, a segunda é que eles devem ser menores ainda.
Métodos devem conter no máximo 20 linhas e seu nível de identação não pode ser maior que dois. Quanto ao conteúdo, um método deve ter somente UMA responsabilidade. É difícil dizer o que é “uma responsabilidade”, mas uma maneira de descobrir se um método está fazendo mais de uma coisa, é tentar extrair uma parte dele em outro método. Se for possível, realmente o primeiro método tinha mais de uma responsabilidade.
Evite passar muitos parâmetros para um método, porque isso pode causar confusão além de dificultar a escrita de testes unitários, pois assegurar que todas as combinações de parâmetros diferentes funcionarão é bem mais trabalhoso. Passar parâmetros booleanos (verdadeiro ou falso) também não é uma boa prática, além complicar a assinatura do método, claramente a função tem mais de uma responsabilidade. Outro detalhe importante que devemos nos preocupar são os efeitos colaterais, esses efeitos são mentiras. Seu método diz que fará uma coisa, mas faz outras “escondidas”.
public boolean checkPassword(String username, String password) { String passwordStatus = cryptographer.decrypt(password); if(passwordStatus.equals(“OK”)) { Session.initialize(); return true; } return false; }
Comentários
Quando você pensa em adicionar um comentário em seu código, é um forte indício que ele não está muito bom, não está claro.
Formatação
A legibilidade do código terá profundo efeito sobre todas as mudanças que serão feitas, seu estilo e disciplina sobrevive sobre estas mudanças.
Tratamento de erros
Quando estamos programando devemos tratar os possíveis erros que nossa aplicação poderá lançar, as coisas podem dar errado e temos que estar certos que nosso código fará o que deve fazer.
Prefira lançar uma exception ao invés de retornar um código de erro, estes retornos desorganizam a chamada do método e pode-se facilmente esquecer de verificá-los.
Testes unitários
Há alguns anos atrás, pouco se ouvia falar de TDD (Test Driven Development). Para muitos TDD erá apenas trechos de código que garantia que o programa “funcionasse”. Mas essa idéia amadureceu bastante entre todos nós, hoje em dia programar com TDD é um conceito de alto nível, por isso, todos os testes que criamos devem ser escritos com código limpo.
Lembre-se que o código do teste é tão importante quanto o código da produção.
- Você não pode escrever o código até que você tenha criado um teste que falhe.
- Você não pode escrever mais testes do que seja suficiente para falhar.
- Você não pode escrever mais código do que o suficiente para passar o teste que está falhando.
Classes
- variáveis publicas e estáticas
- variáveis privadas e estáticas
- variáveis privadas
Depois das variáveis vêm os métodos públicos. Os métodos privados aparecem depois de suas chamadas. Assim como os métodos, as classes também devem ser pequenas. Ninguém gosta de encontrar classes gigantes onde é difícil até mesmo de se encontrar dentro delas. Mas a pergunta é: O quão pequenas elas devem ser?
O nome da classe deve representar a sua responsabilidade. Tentar fazer uma breve descrição da classe, explicando o que ela faz pode ajudar a escolher o nome certo. Esta descrição deve ter no máximo 25 palavras e não conter palavras como “mas”, “e”, ”ou”, “se”, pois expressam mais de uma coisa mostrando que há mais de uma responsabilidade.
Para concluir, queremos nosso sistema com pequenas classes, cada uma com uma única responsabilidade, tendo uma razão para mudar e colaborando com outras para alcançar o comportamento desejado do sistema.
Design emergente
1. Rode todos os testes
2. Remova duplicação
3. Expresse sua intenção
Escrever código que nós entendemos é fácil pois estamos concentrados e ligados no problema que estamos tentando resolver. Mas o próximo que pegar o código para fazer manutenção, não estará tão ligado ao problema como você estava quando implementou a solução.
4. Diminua o número de classes e métodos
Conclusão
- Os nomes dos métodos e variáveis estão coerentes?
- Cada método possui sua responsabilidade?
- Não dá pra extrair para outro método?
- Está simples e fácil de entender?
8 Comentários
Pingback: Lista com todas as Práticas Ágeis | André Faria Gomes
Pingback: Uncle Bob Martin, um grande exemplo para nós Desenvolvedores | André Faria Gomes
Bastante interessante a resenha que fizestes. Gostaria de saber se você adquiriu o livro em Inglês ou Português. Se foi em Português, como está a qualidade em linhas gerais (Tradução, Coesão, etc)? Tenho esta dúvida, porquê se em Português está mais barato e chega com maior agilidade que comprar no Amazon.
Obrigado!
Olá Gustavo.
Obrigado pelo seu feedback. O livro que temos aqui na Bluesoft é em inglês, nós o trouxemos dos Estados Unidos, por isso, infelizmente, não podemos afirmar se a qualidade da tradução para o português é boa ou não é.
O Clean Code e realmente um ótimo livro e este post deu uma sintetizada fantástica no assunto, parabéns!
Muito útil e informativo. Manutenções em sistemas que seguem esses princípios deixariam de ser traumatizantes.
Excelente resenha e apresentação, Bruno! Precisamos de mais exemplos como o seu. Cada vez mais desenvolvedores precisam conhecer, ler e praticar as técnicas e dicas do Uncle Bob. No meu blog escrevi já há algum tempo dando essa dica de livro e de dois outros clássicos. Vide em http://josepaulopapo.blogspot.com/2009/01/codigo-limpo-beneficios.html
Também indiquei e falei sobre a sua resenha em meu twitter: http://twitter.com/josepapo/status/13499117833
http://twitter.com/josepapo/status/13499207736
http://twitter.com/josepapo/status/13499293240
Grande Lui. Parabéns pelo Artigo!