O documento discute técnicas para refatorar código e mantê-lo limpo, incluindo identificar cheiros ruins no código, dar nomes significativos às variáveis e métodos, escrever métodos pequenos que fazem uma única tarefa, usar padrões de projeto para reduzir repetição, e formatar o código de acordo com um padrão de equipe.

1. Refatoração: Mantendo o
código livre de maus
cheiros
Code Smell
Pedro H.O.Silva
pedrohosilva.wordpress.com/

2. Quem é você?
Não sou esses caras

3. Quem é você?

4. Uai, má o que c vai fala, sô?
Robert C. Martin - "Uncle Bob"

5. Mas Primeiro: Teoria das Janelas
Quebradas
Em 1982 pelos americanos James Wilson e George Kelling
http://drauziovarella.com.br/drauzio/janelas-quebradas/

6. Que Diabos/Minuto
Segundo "Uncle Bob", a unidade de
medida para um código é Que
Diabos/minuto !

7. Afinal, o que é um código
SUJO?!

8. Afinal, o que é um código
SUJO?!
Bjarne Stroustrup ( Pai do C++ )
● A lógica deve ser direta, para dificultar o encobrimento
de bugs;
● Dependências mínimas;
● Tratamento de erro;
● O Código limpo, faz bem apenas uma coisa, executa
apenas uma tarefa.

9. Dave Tomas ( Criador do Eclipse )
● O código limpo tem testes de uma forma geral, como
unitários, integração, aceitação etc.
● Nome significativos (nada de “int i;”);
● Poucas dependências e fazer apenas uma tarefa (como
citado por Bjarne);

10. Dando nome aos Bois!
Nomeando as coisas ( Classes, Métodos,
Variáveis, etc… )
Bizu #01 - Sempre que encontrar um nome
ruim, mude-o ( CTRL + ALT + R );
Bizu #02 - Dê nomes que tenham dignificados,
nada de: int i, String x, Date dmahmsegs;

11. Dando nome aos Bois!
Bizu #03 - Evite nomes com mais de um
siginificado ou com duplo sentido,
Ex:. HP empresa ou Hipotenusa? ;
Bizu #04 - Evite nomes muito parecidos, Ex:.
XYZControllerForEfficientHandlingOfString
XYZControllerForEfficientStorageOfString

12. Dando nome aos Bois!
Bizu #05 - Dê nomes pronunciáveis, EX:.
genymdhms ou generationTimestamp?

13. Padrão SUN: Classes
● Substantivos;
● Primeira Letra Maiúscula;
● Para Palavras Compostas, usar o CamelCase;
Ex:. Dog, ServicoPagamentoCompleto ...

14. Padrão SUN: Interfaces
●
●
●
●
●
Primeira Letra Maiúscula;
Para Palavras Compostas, usar o CamelCase;
Alguns usam IDAO e DAO
Alguns usam DAO e DAOImpl
Sempre que possível usar nomes mais que
mostrem seu propósito, como por exemplo
List e ArrayList, no JAVA
Ex:. DAO, IDAO, DAO, DAOIml...

15. Padrão SUN: Métodos
● Primeira Letra Minuscula;
● Para Palavras Compostas, usar o CamelCase,
mas sempre manter a primeira minuscula;
● Verbo-Substantivo
Ex:. getNome, setIdade, somarSalarios ...

16. Padrão SUN: Variáveis
● Primeira Letra Minuscula;
● Para Palavras Compostas, usar o CamelCase,
mas sempre manter a primeira minuscula;
● Nomes significativos;
● Nomes Pequenos, sempre que possível
Ex:. nome, idade, enderecoEntrega ...

17. Padrão SUN: Constantes
● Marcados como Final e Static;
● Todas letras maiúsculas;
● Palavras Compostas, separar por
UnderScore ( _ )
Ex:. static final ENVIA_POR_ARQUIVO

18. Testes
● Mesmo padrão citado nos casos anteriores,
mas para as classes é padrão acrescentar o
sufixo Test, e também manter o mesmo
nome de pacote, porem em uma src
diferente.
Ex:. GeraArquivoTest.class

19. Métodos
● Pequenos, de 20 a 30 linhas ( eu já vi
métodos com mais de 1000 linhas);
● Fazer apenas uma coisa, devem fazê-la bem,
devem fazer apenas ela;
Bizu #06 - Use a extração de métodos, classes e
interfaces que as IDEs modernas possuem (
CTRL + 1 )

20. Métodos
● Evite muitos Ifs e Elses, utilizar padrões de
projeto que faça abstração, como Chain of
Responsability, Abstract, Factory, etc…
● Os blocos if, else, while, switch/case devem
conter, de preferência, apenas uma linha,
sendo ela uma chamada de função;

21. Métodos: Parâmetros
● A quantidade de parâmetros ideal, é ZERO,
0, NULO;
● Mas…
○
○
○
○
Mônade;
Díade;
Tríades;
Políade (Caso muito especial)
● Para evitar isso utilize objetos;

22. Métodos
● Evite Repetição de Código

23. Comentários

24. Comentários
● Não insira comentários em um código ruim,
reescreva-o;
● Comentários velhos são mentirosos, e o pai
da mentira é o ….
● Geralmente os comentários não são
atualizados;

25. Comentários
● Código bom é auto-explicativo, não precisa
de comentários
● Ler um código bem escrito, é como ler uma
bela poesia;

26. Comentários Bons
● Legais (Direitos autorais)
● Explicativa, tivemos que fazer isso por causa
disso, foi a melhor maneira que encontramos
de fazer isso, etc …
● Alerta sobre consequencias Ex:. Não usar
este teste porque ele gera um relatório real;
● Comentários TODO

27. Comentários Ruins
● Comentários Redundantes;
● Comentários Enganadores;
● Comentários Imperativos ( @Param do
javadoc )
● Comentários Longos;
● Comentários Ruidosos
Ex:. /*dia do mes */ private int diaDoMes;
● Marcadores de posição
Ex:. // ########################

28. Formatação
● Formatação é importante SIM!
● Entre em acordo com o time de
desenvolvimento e definam um padrão;
● Procurem por padrões já estabelecidos;
● Metáfora do Jornal;

29. Formatação: Bizus
Bizu #07 - No eclipse utilize - CTRL + 3 e
digite: Formatter, clique na opção:
Agora você pode editar sua formatação ;D

30. Formatação: Bizus
Bizu #08 - No eclipse utilize - CTRL + 3 e
digite: Save Actions, clique em:
Agora você pode habilitar a ação que toda vez
que o documento é salvo ele formata o código.
OBS:. Com o Save Actions é possível configurar
vários combos ;D

31. Tratamento de Erros
● Sempre que possível use Try/Catch;
● Faça um bom sistema de Logs no seu
projeto;
● Tente cobrir a maior parte do código com
testes;
● Build automatizado/Integração Contínua;

32. DUVIDAS?
Blog: pedrohosilva.wordpress.com
Facebook: /pedrohenrique.silva.106
E-mail: pedrospsjc@gmail.com
BitBucket: bitbucket.org/pedrosjcampos