O documento discute os princípios do código limpo e fornece exemplos de boas práticas para produzir código legível e de fácil manutenção. Algumas dessas boas práticas incluem ter apenas um nível de indentação, nomear entidades de forma significativa, focar cada classe em uma única responsabilidade e seguir o princípio da programação para interfaces ao invés de implementações. O documento também lista 8 itens considerados importantes para produzir código limpo, como entender bem o domínio do problema e sempre buscar

1. Clean Coder
Camilo Teixeira de Melo
Arquiteto de Soluções e Engenheiro
de Software
Github: github.com/camilotx

2. O que é Clean Code?
• O termo clean code surgiu com o livro, do mesmo título, do Especialista e
desenvolvedor Robert C. Martin (Uncle Bob);
• O livro é uma compilação de boas práticas realizadas pelo autor durante sua
vida como desenvolverdor;.
• o Martin, convincentemente, argumenta que código limpo não é somente
desejável - é necessário.
"A arte de programar é, e sempre foi, a arte de desenhar linguagens.
Grandes programadores quando pensam em sistemas, pensam em
histórias para serem contadas em vez de programas para serem
escritos. Eles usam as ferramentas que a linguagem de programação
escolhida lhes proporciona para construir uma linguagem muito mais
rica e expressiva que possa ser usada para contar a história."

3. Object Calisthenics
Termo criado por Willian Durand, que baseado no livro do Uncle
Bob e a técnica de definição muscular, calistênia, criou uma de
uma lista de exercicios que o desenvolvedor deve realizar para que
seu código fique legível e com uma boa manutibilidade.
A lista os itens da lista são:
• Apenas um nível de indentação por método;
• Não use a palavra-chave ELSE;
• Encapsule todas as primitivas e nós;
• Coleções de "primeira classe";
• Um ponto por linha;
• Não abrevie;
• Mantenha todas as entidades pequenas;
• Nenhuma classe com mais de duas variáveis de instância;
• Nenhum Getters / Setters / Properties;

4. Mas o que realmente
funcionou?
• Li e reli o livro do Robert C. Martin e cheguei a me
tornar um xiita do Object Calisthenics.
• Quanto mais me emprenhava, mais improdutivo me
tornava.
• Adaptei alguns itens para a minha realidade;
• Códigos factíveis e prazos apertados.
• Foco em escrever códigos que expliquem o seu
contexto.
• Lista de 8 itens que eu considero os mais importantes.

5. 1 – Conheça o Domínio
• Entender ao máximo o problema a ser
resolvido
• Pensar bem nas tecnologias a serem
usadas
• Sinta prazer em saber mais do que
qualquer pessoa sobre o domínio a ser
resolvido.

6. 2 – Nomes são de
extrema importância
• Os nomes são as nossas identidades
• Cada nome possui um significado e um
contexto
• Dedicar mais tempo aos nomes das suas
pacotes, classes, metódos e variáveis;
• Nome de interfaces devem representar
capacidades ou qualidades: Callable,
Runnable, Observable, Contextable
• Nome de classe abstrata representam
executores de ações:
Validator, Observer, Repository
• Classe devem ser nomeadas com as suas
funções reais: EmailValidationService,
UserRepository

7. 3 – Somente um nível
de endentação
• Aumento da legibilidade
• Auxilia na contextualização do código
• Melhora na manutenção do código
• Diminuição da complexidade
ciclomática

8. 3 – Somente um nível de endentação
Código Sujo Código Limpo

9. 4 – Sempre programe
para interface
• Segregar no máximo de
comportamento possível.
• Comportamentos são contrato
comportamentais
• A interfaces representas as qualidades
que suas classes possuem.
• Métodos e classes devem aguardar
comportamentos e não objetos.

10. 5 – Uma única razão de
existir
• Tudo que você criar, deve ter
uma razão para existir. Uma
classe, um método ou até
mesmo uma variável.
• Quando um método possui
muitas linhas, provavelmente
ele está fazendo mais do que
deveria.

11. 6 – Sem medo de
usar variáveis
publicas
• Se você precisa inserir e resgatar
dados a todo instante de uma classe,
uma variável pública é mais legível do
que dois métodos públicos.

12. 7 – Interfaces Funil
• Desenvolver pacotes, módulos,
classes ou métodos com poucos
pontos de acessos.
• Muita classe, métodos privados,
médio protegidos e poucas
públicas.
• Acesso e extensão somente de
classes importantes

13. 7 – Melhoria Contínua
• Algo sempre pode ser melhorado
• Não há melhoria a onde não há
comprometimento
• É responsabilidade de todos
melhorar o ambiente de trabalho.
• Faça Code Reviews

14. Hands-on
Vamos refatorar uma classe da start-up Quinto
Andar.
Repositorio
https://github.com/quintoandar/consultasbr

15. Perguntas
PERGUNTAS ?