Clean Code

Programando lindamente
Introdução

As técnicas do Clean Code foram apresentadas pela primeira vez para a

comunidade através do livro de mesmo nome, escrito por Robert C. Martin, o
Uncle Bob, em 2008.
Essas técnicas foram adotadas como padrão de bom desenvolvimento pela
comunidade e a leitura do livro é altamente recomendada a todos os
desenvolvedores.

Livro “Clean Code” Uncle Bob

 Referências

Livro Clean Code Canal “Código Fonte TV” Site “balta.io”

https://tinyurl.com/3yc5ad6w https://www.youtube.com/watch?v=ln6t3uyTve https://balta.io/artigos/clean-code
Q
Uncle Bob

● Atua na área de desenvolvimento desde 1970;

● Signatário do Manifesto Ágil;
● Percebeu com seus anos de experiência que o gargalo no
desenvolvimento de software está em sua manutenção;
● Muito além de uma boa arquitetura e de boas práticas computacionais,
o código fonte precisa ser escrito sob princípios, e esse é o propósito da
criação do Clean Code ;
Um sistema nunca estará completamente
finalizado

Sempre haverá a necessidade de atualizações,

correções e novas funcionalidades.

Códigos envelhecem e podem ficar obsoletos!

 Também é sobre dinheiro

Um código limpo evita gastos desnecessários

com manutenção, e deixa o software
preparado para novas atualizações e melhorias
Os princípios do Clean
Code
● Regras Gerais
● Regras de design
● Regras sobre entendimento do código
● Regras de nomes
● Regras para funções e métodos
● Regras de comentários
● Estrutura de código
● Objetos e estruturas
● Testes
● Code smells
Regras Gerais

Siga as convenções KISS

Mantenha-se fiel às convenções definidas no Mantenha as coisas simples! Normalmente tendemos
projeto, sejam elas relacionadas a estrutura, a complicar coisas que poderiam ser mais simples.
padrões de nomenclaturas, etc. Então, Keep It Stupid Simple

Regra do escoteiro Causa Raiz

“Deixe sempre o acampamento mais limpo do Sempre procure a causa raiz de um problema,
que você o encontrou”. Devolva sempre um não resolva as coisas superficialmente.
código melhor do que você o obteve.
 DRY
Regras Gerais Não repita a si mesmo (Don’t Repeat Yourself).
Cada pedaço de conhecimento de um sistema
deve ter uma representação única. Não pode
existir duas partes de um sistema que realiza a
Você é o autor do código mesma função.

O código pode ser considerado uma história. Tratamento de erros

Devemos contar a história de forma clara,
simples e principalmente pequena. Siga duas As coisas podem dar errado, e quando isso
regras: 1- as funções devem ser pequenas; 2- acontece, programadores são responsáveis por
as funções devem ser menor ainda. garantir que o código faz o que precisa.

Comentários mentem Testes limpos

Códigos são atualizados, comentários não. Um código só é considerado limpo se for
Prefira utilizar comentários instrutivos e deixe validado através de testes, mas mesmo os
que o próprio código diga o que ele faz. testes devem ser limpos, e para isso, devem
utilizar a regra FIRST (Fast, Independent,
Repeatable, Self-Validation, Timely)
"Um código limpo sempre parece
que foi escrito por alguém que se
importava."
- Michael Feathers
Regras de design
Mantenha dados de configuração em alto nível
Procure manter as configurações da aplicação ou o parse delas em um
nível mais alto o possível.
Regras de design
Polimorfismo no lugar de IFs
Um IF ou condicional traz uma tomada de decisão a nossa aplicação, o que implica
no aumento da complexidade. Devemos evitar o uso excessivo.

Implementação utilizando IFs Implementação utilizando Polimorfismo

Regras de design
Utilize injeção de dependência
Sempre que possível utilize injeção de dependência, a fim de tornar o código mais
limpo e desacoplado.

Frameworks para DI em .NET:

● Microsoft.DependencyInjection
● Ninject
● SimpleInjector
Regras de design
Lei de Demeter
A Lei de Demeter (LoD) ou princípio do menos conhecimento
prega os seguintes pontos:

● Cada unidade deve ter conhecimento limitado sobre

outras unidades: apenas unidades próximas se relacionam.
● Cada unidade deve apenas conversas com os seus amigos. Mau exemplo
● Não fale com estranhos, apenas fale com seus amigos
imediatos.

Bom exemplo
Regras sobre entendimento do código
Seja consistente
Se existe um padrão estabelecido no projeto, realize manutenções, melhorias
e novas implementações mantendo o padrão definido.
Regras sobre entendimento do código
Utilize variáveis concisas
Opte por variáveis concisas, mesmo que resultem em um nome maior. Elas devem
ser auto-explicativas, sem a necessidade de comentários ou informações adicionais.
Regras sobre entendimento do código
Evite dependências lógicas
Não escreva métodos cujo funcionamento correto dependa de algo contido em sua
classe.

Mau exemplo

Bom exemplo
Regras de nomes
Escolha nomes descritivos
Escolher bons nomes para classes variáveis e métodos é essencial para um código
limpo. Se você precisa explicar o seu código, então algo pode ser melhorado nele.
Regras de nomes
Faça distinções significantes
Utilize nomes nos quais quem estiver lendo o seu código possa diferenciar seu
significado de outros possíveis nomes.
Regras de nomes
Utilize nomes pronunciáveis e buscaveis
Evite utilizar nomes difíceis de pronunciar ou inventar nomes e convenções para
variáveis, classes e métodos. Tenha em mente a linguagem ubíqua definida para o
projeto.
Regras de nomes
Evite uso excessivo de strings
Evite utilizar a mesma string várias vezes, utilize constantes para isso.
Regras de nomes
Não use prefixo ou caracteres especiais
Não utilize prefixo com o tipo da variável, classe ou método e nunca use caracteres
especiais nesses itens.
Regras para funções ou métodos
Pequenas e com apenas um objetivo
Mantenha suas funções ou métodos o menor possível. É mais fácil manter métodos
menores e reutilizáveis do que tudo dentro de um método só.
Regras para funções ou métodos
Utilize nomes descritivos
Assim como na regra anterior, mantenha nomes concisos, sem caracteres especiais.
Regras para funções ou métodos
Opte por poucos parâmetros
Evite exigir muitos parâmetros para a construção de um objeto.
Regras para funções ou métodos
Não tome decisões desnecessárias
Não utilize os famosos “flags” para tomar decisões dentro dos métodos, divida-os
em vários métodos ou até mesmo outras classes.
Regras de comentários
Um código bom é expressivo Evite códigos comentados
No geral, se você precisa comentar uma parte Não deixe sujeira no código, não mantenha
do seu código, é um indicativo de que ele não códigos antigos comentados. As ferramentas
está expressivo o suficiente. de controle de versão dão o devido suporte
para analisar códigos antigos.

Não seja redundante

Evite comentários que não ajudem a explicar o
contexto ou cenário.
Regras de comentários
Intenção Consequências
Um bom uso de comentários é sobre a intenção Podemos utilizar comentários para alertar
de um método, classe ou variável. trechos de código que podem ter
consequências sérias.

Esclarecimento
Outro uso interessante para os comentários são
esclarecimentos sobre o código.
Estrutura do código
Separe conceitos verticalmente
Mantenha uma estrutura de pasta organizada. Utilize uma separação por contexto
ou feature.
Estrutura do código
Declare variáveis próximas de seu uso
Não crie todas as variáveis juntas, no começo da classe ou método. Defina-as
próximas de onde serão utilizadas.
Estrutura do código
Agrupe funcionalidades similares
Se uma função pertence a um grupo dentro de um objeto, mantenha-as sempre por perto.

Declare funções de cima para baixo

Ordene as funções por ordem de grandeza e assinaturas.
Estrutura do código
Não use alinhamento horizontal
Não há necessidade de alinhar horizontalmente variáveis, constantes ou propriedades.

Não quebre a identação

Este item dispensa comentários. Um código não identado não pode ser enviado para o projeto.
 Objetos e estruturas
Esconda estruturas internas
Este tópico abrange uma discussão extensa.
Esconder a estrutura de um objeto, ou seja,
privar as propriedades relacionadas a dados
dele, vai sempre trazer resultados positivos e
negativos.

Uma recomendação é para tornar o SET das

propriedades privados. Como consequência,
serão necessários mais métodos para
manipulação destes valores.

Se os dados não fazem sentido para objetos

externos, não há discussão, devem ser privados.
 Objetos e estruturas
Evite usar dados e objetos juntos
Outro ponto polêmico que muitos interpretam
como manter nos objetos apenas propriedades
enquanto seus comportamentos ficam em
outros objetos.

Ainda existem discussões se entidades devem

ser anêmicas ou não, a recomendação é definir
uma padrão entre a equipe para um projeto e
manter o padrão.

Talvez uma abordagem que aplique estes

conceitos de forma legal seja novamente o uso
dos value objects.
Objetos e estruturas
Mais métodos, menos tomada de decisão
Optar pela criação de mais métodos e mais sobrecargas do que tomadas de decisão.
Objetos e estruturas
Evite métodos estáticos
Classes e métodos estáticos são difíceis de gerenciar, além de serem compartilhados
pela aplicação como um todo. Em um exemplo de uma classe estática que contenha
uma lista de notificações, a mesma lista seria compartilhada para todos os usuários
do sistema.
Testes
Um assert por teste
Utilize um e apenas um assert por teste. Mais de um assert pode confundir e
comprometer a escrita do teste.
Testes
Legível
Trate os testes como parte fundamental do código, não secundária. Os testes tem que ser
organizados e bem escritos assim como o resto do software.

Rápido
Um dos objetivos principais de um teste é cobrir uma pequena porção do código. Estendendo
esta ideia para a maior parte do código possível, pode ocasionar uma ampla gama de testes.

Como os testes normalmente são executados antes de cada publicação, em cenários críticos
onde o tempo do deploy é extremamente importante, testes que demorem para serem
executados podem impactar negativamente.
Testes
Independentes
Os testes não devem depender de entidades externas, nem de outros testes. Por isso é
fundamental a utilização de Injeção de Dependência.

Repetível
Devemos ter a possibilidade de repetir o mesmo teste, mas com parâmetros diferentes.
Code Smells

Code Smells são alguns sintomas que podemos identificar e que nos remetem a uma má aplicação
do Clean Code de forma geral.

Rigidez Imobilidade
Seu software é difícil de mudar. Você não consegue reutilizar partes
Qualquer mudança, por menor que do seu código em outros projetos
seja, causa uma cascata de outras porque isso requer esforços
mudanças. gigantes. Alto acoplamento.

Fragilidade Complexidade desnecessária

Uma simples mudança quebra o Usa padrões e arquiteturas que tornam o
software em diversos locais. código mais burocrático do que efetivo.

Opacidade Repetição desnecessária

O código é difícil de entender. O código é repetido em diversos lugares.
"Qualquer tolo pode escrever código
que um computador pode entender.

Bons programadores escrevem

códigos que humanos podem
entender."
- Martin Fowler
Dúvidas,
Questões,
Comentários?
Abra o seu coraçãozinho
 Obrigado!
E até logo!

Dimas Soares
(12) 98113-4015
Dimas Soares
[email protected]