Apresentação sobre o que é um código limpo e como fazê-lo.

1. Clean Code
Daniel Tamiosso
presentation based on Hendrik Ebel

2. Tópicos
O que é?
A motivação
Os objetivos
Escolhendo os nomes
Comentários
Métodos
Objetos e estrutura de dados
Tratamento de erros
Testes unitários
Arquitetura
Design
Programação em par
Maus cheiros
Como chegar lá?

3. O que é código limpo?
Uma questão...
fácil manutenção cuidadoso
legível
elegante
feito para o problema
sem duplicações
eficiente
simples
... muitas respostas!

4. A motivação
O custo total para o proprietário de um código bagunçado

5. Como mensurar?

6. Os objetivos
Produzir um código melhor
Escrever código para humanos lerem
Reduzir a complexidade
Manter a manutenibilidade do código ao longo do tempo
Idealizar a produção de software como uma tarefa artesanal
Software não só para o cliente mas também para o
desenvolvedor
Uma lei escoteira: Deixar o local do acampamento, no mínimo,
mais limpo do que quando você o encontrou.

7. Escolhendo os nomes
Variáveis, métodos e classes devem responder as seguintes
perguntas:
Por que isto existe? O que isto faz? Como isto é usado?
Se o nome escolhido requer um comentário, então o nome não está
revelando sua intenção.
Evite desinformação
Use uma nomenclatura de domínio
Se usou algum padrão de projeto, identifique-o
Prefira nomes pronunciáveis. Humanos são bons com palavras.
Evite o uso de encodings.
Evite a mesma palavra para dois conceitos distintos
Habilidades em dar nomes vão muito além do conhecimento técnico.
Faz parte da cultura do desenvolvedor. E realmente faz diferença.

8. Comentários
A principal proposta de um comentário é explanar um código que não
fala por si só
Não use um comentário quando você pode usar um método ou uma
variável
Comentários podem se tornar mentirosos
Mas, lembre-se: comentários muitas vezes são um mal necessário

9. Por que não comentar?
Representam sinais de “códigos sujos”. Tente reescrevê-lo antes!
Eles tendem a mentir.
Eles são sempre falhas de um código que não explanam sua
intenção.
Com certeza eles não vão melhorar seu código. Esqueça isso.

10. Onde jamais comentar
Fechando blocos de códigos
Marcando posições dentro do código fonte
Javadocs não público
Na forma HTML
Em redundância
public Carro(){} // default constructor

11. Onde podemos comentar
API pública
Avisos para consequências (do tipo: execute-me somente se você
estiver muito tempo disponível!)
TODO “reais”
Comentários de origem legal

12. Métodos
A sua meta é contar um pedaço de uma estória do sistema
Sua maior lei é ser muito pequeno
E fazer SOMENTE uma coisa
O número ideal de argumentos é ZERO
O máximo é TRÊS
Evite argumentos ao estilo FLAG (booleanos)
Command And Query Separation

13. Objetos e estrutura de dados
Use a mesma linguagem do domínio
Ser apenas uma coisa. E ser mesmo essa coisa.
Objetos devem esconder seus dados e expor operações
Estrutura de dados devem expor os dados e não devem possuir
operações significativas

14. Tratamento de erros
É um conceito a parte. Trate-o assim.
Use-as sempre exceções ao invés de códigos de retorno
Esqueça as exceções checadas. Use e abuse das não checadas
Nunca retorne NULL
retorne uma exceção especial
ou de preferência algo como Collections.emptyList()
Ah! E nunca passe NULL
InvalidArgumentException ou assert
Ou melhor: proíba a passagem de NULL como padrão

15. Testes unitários
Test Driven Development (TDD)
Teste e código de produção são escritos juntos
Os testes apenas alguns segundos antes
O código de teste é tão importante quanto código de produção
E devem ser tão limpos quanto eles
Um método de teste deve testar apenas uma coisa (um assert)
ou um conceito
FIRST As três leis
Fast Você não deve escrever qualquer
Independent implementação antes que você tenha escrito
Repeatable um teste que falhe
Self-Validation Você não deve escrever mais que um teste
Timely unitário para demonstrar uma falha
Você não deve escrever mais do que o
necessário para passar por um teste que
está falhando

16. Arquitetura
Como a construção de uma cidade: incremental e modular
Big Design Up Front (BDUF) inibe a adaptabiliade do sistema e é
invasiva
Normalmente resulta na frase: “Uma bazooka pra matar
uma mosca”
Com isso temos muitas decisões pequenas ao invés de poucas e
arriscadíssimas decisões
As tecnologias devem aparecer por demanda. Jamais por
insegurança futura
Pode ser um padrão ou possuir uma bela API. Se ela não for
necessária, será extremamente danosa.
Assim como o código em geral, deve ser colaborativa.

17. Design
A melhor definição: emergente, nunca final
Simples. Lembre-se sempre
SRP, DRY, OCP e Fluent Interfaces
YAGNI - You Aren’t Gonna Need It
Design Patterns
Filosofia Unix
Princípios de OO
Lei de Demeter
Um método ou objeto deveria chamar apenas: ele
mesmo; qualquer composição, qualquer parâmetro passado e
qualquer objeto criado por ele
Expressivo e refatorado constante
Ah! Testes não mentem
Avalie dia-a-dia. Evite chegar a um ponto sem retorno.

18. Programação em Par
Após ajustados, os pares produzem código 15% mais lento que
um desenvolvedor de forma individual...

19. Programação em Par
... mas com 15% a menos de defeitos.

20. Maus cheiros
Comentários obsoletos e redundantes
Builds com mais de um passo e duração maior que 10 minutos
Testes que requerem mais que um passo
Muitos argumentos e argumentos booleanos
Métodos esquecidos e métodos que fazem tudo
Muitos idiomas em um código fonte
Duplicação
Nomes que não representam intenção
Polimorfismo é deixado de lado por If/Else e Switch/Case
Números mágicos e condicionais negativos
Longas listas de imports e variáveis de instância
Constantes ao invés de enumerações
Testes insuficientes (não fuja dos testes triviais)

21. Como chegar lá?
1. Torne escrever código limpo parte do seu processo pessoal.
Atenção contínua para uma excelência técnica em um
bom desing melhoram a agilidade da equipe.
2. Aprenda como escrever código limpo.
Escrever código limpo é como realizar qualquer outro
tipo de trabalho. Requer prática, criticismo e mais
prática.
3. Valorize código limpo.

22. Finalizando
“Complexity kills. It sucks the life out of developers, it
makes products difficult to plan, build and test...
Each of us should ... explore and embrace techniques
to reduce complexity” Ray Ozzie, Chief Technology Officer,
Microsoft Corporation
Clean code por Robert C. Martin Series