Bluesoft Labs: Clean Code por Bruno Lui

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?

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.

Classes

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