O documento discute princípios de código limpo, incluindo: 1) tratar erros com exceções em vez de códigos de retorno; 2) limitar dependências de código de terceiros; 3) escrever testes de unidade limpos e automatizados para guiar o desenvolvimento. Ele também aborda tópicos como classes pequenas com responsabilidade única, separação de construção e uso de sistemas, e refinamento contínuo aplicando boas práticas.

1. Clean Code
Francisco Clauvane

2. Sobre
Esta apresentacao teve como base o livro
Clean Code, minha experiencia profissional e
as dicas dadas por profissionais mais
experientes. Onde o objetivo da mesma e
mostrar na teoria e na pratica o que e um
codigo limpo.

3. Sumario
1. Tratamento de erro
2. Limites
3. Teste de unidade
4. Classes
5. Sistemas
6. Emergencia
7. Concorrencia
8. Refinamento Sucessivo

4. 1-Tratamento de erro
● Tratamento de erro em codigo limpo?
● Esse recurso e importante, mas se
obscurecer a logica, esta errado.
● O tio bob nos traz algumas tecnicas e
consideracoes para que voce crie um codigo
limpo e robusto e que trate os erro com
estilo e elegancia.

5. 1-Tratamento de erro
Use excecoes ao inves de retornar codigo.
public class AppVenda{
public static void main (String args []){
Produto produto = produtoServise.load(produto.getCodigo());
seters... if(produto.getStatus().equals(StatusProduto.
PRAZO_DE_VALIDADE_EXPIRADO)){
System.out.println("Erro ao salvar o pedido: Prazo de validade expirado");
}else {
produto.save();
}
}
}

6. 1-Tratamento de erro
Use excecoes ao inves de retornar codigo.
public class AppVenda{
public static void main (String args []){
Produto produto = produtoServise.load(produto.getCodigo());
seters... if(produto.getStatus().equals(StatusProduto.
PRAZO_DE_VALIDADE_EXPIRADO)){
throw new Exception("Prazo de validade expirado");
}else {
produto.save();
}
}
}

7. 1-Tratamento de erro
● Crie primeiro sua estrutura try-catch-finally
para depois construir o codigo.
○ TDD
● Use excecoes nao verificadas
○ Excecoes verificadas sao 'CARAS'
○ Use excecoes verficadas apenas em situacoes
criticas, por exemplo: Biblioteca
○ De maneira geral, o custo da dependencia e maior
que o das vantagens.
● Forneca excecoes com contexto
○ Nao use Exception no seu catch.
○ Use mensagens informativas.

8. 1-Tratamento de erro
● Defina as classes de excecoes segundo as
necessidades do chamador.
○ Transformar varios catch em um tipo comum.
● Defina o fluxo normal
○ try{
○ MealExpenses expenses = dao.load(employee.getId);
○ m_total += expenses.getTotal();
○ }
○ catch {
○ m_total += getMealPerDiem();
○ }

9. 1-Tratamento de erro
● Nao retorne NULL
● Nao passe NULL

10. 2-Limites
● Raramente controlamos todos os softwares
em nossos sistemas.
○ Compramos pacotes de outros fabricantes
○ codigos livres
○ outras equipes
● O uso do codigo de terceiros
○ Ha uma tensao natural entre os fornecedores e o
seu usuario.
○ java.util.Map
● Nao use os limites
○ Evite retorna-los ou aceita-los como parametros em
APIs publicas.

11. 2-Limites
Explorando e aprendendo sobre limites
● Codigo de terceiros nos ajudam a obter mais
funcionalidades em menos tempo.
● Por onde comecar com codigo de terceiros?
● Problemas ao integrar com codigo de terceiros:
○ tempo para ler a documentacao
○ escrever codigo para testar se a funcionalidade
executa como esperavamos
○ deuparacao para descobrir se os bugs sao do nosso
codigo ou do codigo do terceiro

12. 2-Limites
Explorando e aprendendo sobre limites
● Problemas ao integrar com codigo de terceiros:
○ Entender codigo de terceito e dificil.
○ Integra-lo ao seu e mais ainda.
○ Fazer os dois anteriores ao mesmo tempo e muito
mais ainda
○ Solucao: Testes!
○ Testes de aprendizagem
■ Gratuito
■ Robutez quanto a novas distribuicoes

13. 2-Limites
Uso de codigo que nao existe ainda
● Novo tipo de limite: Separa o conhecido do
desconhecido.
Limites Limpos
● E melhor depender de algo que voce
controle do que pegar algo que controle
voce.

14. 3-Teste de unidade
Evolucao da nossa profissao
● Testes
TDD
● As tres leis que a regem
○ Nao se deve escrever o codigo de producao ate que
o primeiro teste de falha tenha sido criado
○ Nao se deve escrever mais de um teste do que o
necessario para falhar, e nao compilar e falhar.
○ Nao se deve escrever mais teste de produco do que
o necessario para aplicar ao teste de falha atual.

15. 3-Teste de unidade
Testes limpos
● "Os codigos de testes sao tao importantes
quanto o codigo de producao. Ele nao e
componente secundario. Ele requer
raciocinio, planejamento e cuidado. E
preciso mante-lo tao limpo quanto o codigo
de producao."
● O que torna um teste limpo?
○ Tres regras:
■ Legibilidade,legibilidade e legibilidade.

16. 3-Teste de unidade
Padrao duplo
● Um teste nao precisa ser mais eficiente que
um codigo de producao.
○ Ambiente de teste e ambiente de producao sao dois
ambiente que possuem requisitos diferentes.
Uma afirmacao por teste
Um unico conceito por teste

17. 3-Teste de unidade
F.I.R.S.T.
● First
● Independent
● Repeatable
● Self-Validating
● Timely

18. 4-Classes
Organizacao das classes
● Toda classe deve comecar com uma lista de
variaveis
○ public,public static e constantes devem vir primeiro
○ private static, privates devem vir depois
● Encapsulamento
○ Protected, somente quando for o ultimo recurso.
● Classes deve ser pequenas
○ Diferentemente das funcoes as classes nao sao
medidas atraves da quantidade de linhas, mas sim
atraves da sua quantidade de responsabilidades.
■ Responsabilidade != metodos

19. 4-Classes
● O nome da classe e muito importante
○ Se o nome for generico entao provavelmente sua
classe tera muitas responsabilidades
○ Principio da responsabilidade unica
■ Devemos escrever um texto descritivo da classe
sem utilizar as palavras: 'se','e','ou','mas'. O uso
destas palavras sao um indicio de excesso de
responsabilidade
■ Melhor um sistema com muitas classes
pequenas do que um sistema com poucas
classes grandes
■ Coesao

20. 5-Sistemas
"Complexidade mata. Ela suga a vida dos
desenvolvedores, dificulta o planejamento, a
construcao e o teste dos produtos."
● Nivel de abstracao mais alto
○ O nivel de sistema
Separe a construcao e uso do sistema
● Cosntrucao != utilizacao

21. 5-Sistemas
Comecaremos pela construcao:
public Service getService(){
if(service == null){
service = new MyServiceImpl(...);
}
return service;
}

22. 5-Sistemas
● Possui uma dependencia da classe
MyServiceImpl
● Possui uma violacao ao principio da
resposabilidade unica
● Possivel dificuldade para Testar
○ Mock para a classe MyServiceImpl
● Nao temos garantia alguma que a classe
MyServiceImpl sera sempre correta.
● Injecao de dependencia

23. 5-Sistemas
Desenvolvimento gradual
● Analogia a construcao de um pequeno
vilarejo que se torna uma grande cidade

24. 6-Emergencia
Segundo Kent, um projeto e "simples" se
seguir as seguintes regras:
1. Efetuar todos os testes
2. Sem duplicacao de codigo
3. Expressar o proposito do programador
4. Minimizar o numero de classes e metodos
Estas regras estao em ordem de relevancia

25. 7-Concorrencia
● Muito dificil escrever programas
concorrentes limpos
● Estrategia de desacoplamento
○ Separa o que e executado de quando e executado
● Mitos e conceitos equivocados
○ A concorrencia sempre melhora o desempenho
○ O projeto nao muda ao criar programas concorrentes
○ Entender as questoes de concorrencia nao e
importante quando se trabalhacom um conteiner
○ A concorrencia gera um certo aumento, tanto no
desempenho como na criacao de codigo adicional
○ Uma concorrencia e complexa, mesmo para
problemas simples

26. 7-Concorrencia
● Mitos e conceitos equivocados
○ Os bugs de concorrencia geralmente nao se repetem,
portanto sao frequentemente ignorados como casos
unicos em vez dos defeitos que realmente sao
○ A concorrencia geralmente requer uma mudanca
essencial na estrategia do projeto.
Desafios
● A seguir um trecho de codigo para
exemplificar os possiveis problemas em
concorrencia

27. 7-Concorrencia
public class X{
private int ultimoIdUsado = 42;
public int getProximoIdUsado(){
return ++ultimoIdUsado;
}
}
O que Aconteceria se duas threads usassem o
este metodo ao mesmo tempo?

28. 7-Concorrencia
Possiveis resultados:
1. Thread A recebe 43, Thread B recebe 44 e o ultimoIdUsado e 44
2. Thread A recebe 44, Thread B recebe 43 e o ultimoIdUsado e 44
3. Thread A recebe 43, Thread B recebe 43 e o ultimoIdUsado e 43
O incrivel terceiro resultado ocorre quando as threads se cruzam. Isto ocorre
po r que elas possuem inumeros caminhos a percorrer onde alguns destes
caminhos podem retornar resultados incorretos.
para o tipo int sao 12.870 caminho possiveis
para o tipo long sao 2.704.156 caminho possiveis

29. 8-Refinamento sucessivo
Como ja foi visto e quaseimpossivel encontrar
a melhor solucao na primeira tentativa. O mais
natural e que durante o dia-a-dia voce melhore
sempre que possivel ou necessario o seu
codigo aplicando as boas praticas de
desenvolvimento, desta forma voce em algum
periodo de tempo ira encontrar um codigo bem
"simples" e que atenda todas as necessidades.