É possível ter Zero Bugs em seu projeto? Nessa apresentação vocês terão acesso as técnicas efetivas de programação para chegar a esse objetivo, são boas práticas que farão uma diferença gigantesca em seu projeto!

1. Projeto Java com Zero Bugs!
Vamos discutir sobre como
trabalharmos em um projeto mais
agradável e a ter menos estresse e
por consequência teremos mais
tempo para a família e projetos
pessoais.
1

2. Problemas graves com bugs
Acho que a maioria ou todos aqui já teve
problemas gravíssimos com bugs, vamos
falar um pouco sobre isso!
2

3. Valiosas dicas gratuitas!
http://eepurl.com/cCGHQD
Ou
3

4. É possível ter Zero Bugs?
Com técnicas efetivas de
programação e boas práticas, se não
tivermos um projeto com Zero Bugs,
chegaremos muito perto, e ainda pra
achá-los ficará absurdamente mais
fácil!
4

5. Tem mais benefícios?
O software está em constante mudança,
imagine se o desenvolvedor codificou para
funcionar, imagina a beleza que vai ser para
adicionar uma nova funcionalidade.
Então SIM, com técnicas efetivas temos
também esse ganho gigantesco!
5

6. Uma técnica muito conhecida
Clean Code! Usando-a
efetivamente já conseguimos um
resultado excelente!
6

7. Por que Clean Code?
• Todos ganham mais tempo
• A empresa gera mais lucro
• Tornamos o projeto muito mais agradável
• É recompensador ver o código bem escrito
• Todos ganham!!!
7

8. Então porque escrevemos código ruim?
• Cronograma apertado
• Visão ultrapassada de números
• Também é nossa culpa como desenvolvedor aceitar esse
cenário
• O cliente não sabe o que quer, até que mostramos a ele
8

9. Frase de Martin Fowler
Frase clássica do Martin Fowler
Any fool can write code that a computer can
understand. Good programmers write code that
humans can understand.
9

10. Frase do Bjarne Stroustrup, inventor do C++
I like my code to be elegant and efficient. The logic should be
straightforward to make it hard for bugs to hide, the dependencies
minimal to ease maintenance, error handling complete according to an
articulated strategy, and performance close to optimal so as not to
tempt people to make the code messy with unprincipled optimizations.
Clean code does one thing well.
10

11. Como saber se o código está ruim?
• Código confuso, difícil de entender
• Baixa coesão, classes ou métodos
possuem muitas responsabilidades
• Dependência excessiva de classes
• Depende de comentários
11

12. Como saber se o código está ruim?
12
• Programação estruturada
• Repetição excessiva de código
• Não usar padrão de arquitetura do sistema
• Não usar orientação a objetos de forma efetiva
• Não usar recursos que a API disponibiliza
• Atribuir qualquer nome de classe/método ou variável
• Usar números mágicos
• Programar pra funcionar

13. É difícil escrever clean code
13
• É preciso colocar mais esforço para ter código limpo
mas com o tempo de prática, isso vai ficando mais fácil.
Talvez a parte mais difícil é começar.
• É muito mais recompensador ver seu código bem
escrito e de fácil manutenção.
• Os resultados são impressionantes, você terá muito
mais tempo para sua família, e fica muito mais
agradável de trabalhar!

14. Nomes significativos
14
Parar e pensar nos nomes as funcionalidades é uma boa prática. Um algoritmo com
nomes ambíguos é muito difícil de decifrar.
Mal exemplo:
int dias; // tempo gasto em dias
Bom exemplo:
int tempoGastoEmDias;
É melhor um nome extenso e significativo do que um nome curto e confuso

15. Use nomes pronunciáveis
15
Mal exemplo:
String endrcoEntr;
String nmCli;
String nmProd;
Bom exemplo:
String enderecoDeEntrega;
String nomeDoCliente;
String nomeDoProduto;

16. Separe os pacotes do sistema por regra de negócio
16
Separar as regras de negócio core do sistema em pacotes ajuda muito o
desenvolvedor a localizar e entender tanto as próprias regras quanto até o
modelo de dados.
Parar um tempo e pensar com calma a estrutura de pacote do sistema também
é muito útil, isso é essencial para termos código de qualidade.
É muito fácil encontrar as classes de negócio quando estão separadas por
cada pacote.

17. Use os padrões do projeto
17
• Por exemplo para fazer uma busca, use sempre buscaAlgo e não pesquisaAlgo ou
getAlgo.
• Se seu projeto não tiver padrões, talvez seja uma boa ideia criá-los.
• Se não concordar com algum padrão no seu projeto, questione o arquiteto, forneça
sugestões
• Convencionar o código são técnicas que vem sendo muito usadas até por
frameworks.

18. Use verbos para métodos
e substantivos para classes e atributos
18
class Produto{ // Substantivo
private double preco; // Substantivo
public void aumentaPreco(double valor) { // Verbo/ação
this.preco += valor;
}
}

19. Classes
19
• Devem ser coesas, devem fazer uma coisa muito bem
• Não devem conhecer muito outras classes
• De preferência use dependências por interfaces
• Use composição
• Use herança com muito cuidado
• Devem ter nomes claros e específicos, fáceis para serem localizados
• Não devem ter nomes ambíguos, Ex: Historico, HistoricoDoCliente
• Deve usar encapsulamento

20. Métodos
20
• Não deve ter muitas linhas, se tiver alguma coisa deve estar errada
• Deve ter alta coesão ou seja, deve fazer apenas uma coisa
• Não deve ter estrutura de controle aninhada
• Não deve ter muitos argumentos, se tiver mais que 3 já é demais
• Deve ser elaborado de uma forma que tenha baixo acoplamento, ou seja, não conheça tanto outras
classes.
• É interessante usar um bom comentário, principalmente em API.
• Deve ser possível testar unitariamente com Junit de forma facilitada, caso contrário o método
provavelmente não foi implementado da melhor forma.

21. Métodos
21
• Isso deve ser evitado, 4 parâmetros ou mais é muita coisa:
void criaHistoricoDoCliente(String nomeDoCliente, int idadeDoCliente,
double valorPago,
double valorDoImposto, String usuarioLogado, String
comentarioDeAlteracao)
• É melhor usarmos um objeto com toda essa informação:
void criaHistoricoDoCliente(FiltroParaHistoricoDoCliente
filtroHistoricoCliente);
• Sem efeitos colaterais:
Métodos devem ter apenas uma responsabilidade

22. Métodos
22
Método orquestrador, (Facade, Service...)
Mal exemplo, muitas regras que deviam estar externalizadas, estão jogadas pelo código:
public void geraHistoricoDoCliente(ClienteDTO clienteDTO) throws BusinessException {
Cliente cliente = new Cliente();
cliente.setNome(clienteDTO.getNome());
cliente.setValorFatura(clienteDTO.getValorFatura());
Contrato contrato = cliente.getContrato();
contrato.setNomeContrato(clienteDTO.getNomeContrato());
// Vários outros setters ....
try {
Contrato contrato = dao.findById(Contrato.class, clienteDTO.getIdContrato);
cliente.setContrato(contrato);
dao.salva(cliente);
} catch (DataNotFoundException dataNotFoundException) {
thow new BusinessException(dataNotFoundException);
} catch(InconsistentDataException inconsistentDataException) {
thow new BusinessException(inconsistentDataException);
}
}

23. Métodos
23
Método orquestrador, (Facade, Service...)
Aqui fica diferente, as regras ficam encapsuladas em seus devidos lugares.
Codifique como se tivesse contando uma história:
Bom exemplo:
public void geraHistoricoDoCliente(ClienteDTO clienteDTO) throws BusinessException {
Cliente cliente = ConversorCliente.paraEntidade(clienteDTO);
Contrato contrato = contratoDAO.buscaContratoPor(clienteDTO.getIdContrato);
historicoClienteDAO.salva(cliente, contrato);
}

24. Tratamento de erros
24
• Prefira lançar Exceptions ao invés de retornar vários códigos de erros
• Escolha Exceptions específicas para seu negócio, nunca use Exception diretamente
• Saiba quando usar checked e unchecked Exceptions
• Não trate RuntimeExceptions, evite-as com tratamentos! A não ser que seja uma caso muito
específico
• Não coloque log em todos os lugares da Exception, coloque o log somente onde a Exception vai ser
pega
• Dê nomes significativos as Exceptions, facilitará quando for encontrar o erro

25. Não repita código
25
• Seu código deve ser elaborado de forma que não haja
repetição.
• Encapsulamento ajuda muito nisso.
• O padrão copiar e colar nunca deve ser usado.

26. Comentários
26
Não comente um código mal escrito, reescreva-o.
Se na sua empresa, usa-se PMD, Checkstyle, use um breve comentário
Se o código é legível você não precisa comentá-lo:
Isso é ruim
// Checa se o funcionário é elegível para receber desconto
if (funcionario.getValorFatura() > 200 && funcionario.getDiaDaCompra() == BLACKFRIDAY_DAY)
Isso é bom:
if (funcionario.isElegivelParaReceberDesconto ())

27. Comentários
27
• Use comentários bem detalhados para sua API, inclua informação de
negócio e crie um nome bem legível, pois provavelmente será
compartilhado com outras equipes.
• Não precisa colocar o comentário novamente dizendo que retorna o
customer, basta dizer que o método retorna o Customer na marca
@return.
/**
* Return a customer based on id
* @param int $id
* @return Customer
*/
Public function getCustomerById($id)

28. Comentários
28
• Evitem usar comentários no meio dos métodos, isso só piora a
legibilidade, deixa confuso, ao invés disso, crie um método separado e
diga o que vai fazer.
Exemplo:
Em vez disso:
public void salvaHistoricoDoCliente(ClienteDTO clienteDTO) {
// verifica se cliente foi alterado
if (!clienteDTO.isInformacaoEditada) {
throw new DadoInconsistenteException();
}
}
Crie isso:
public void salvaHistoricoDoCliente(ClienteDTO clienteDTO) {
verificaSeClienteFoiAlterado(clienteDTO);
}

29. Comentários
29
Comentários redundantes são ruins:
/** O dia do mês. */
private int diaDoMes;
Nesse caso é melhor não usarmos comentários, se for pra comentar, a
informação deve ser mais concisa.

30. Use enums
30
• Prefira enums ao invés de números mágicos.
• Evite fazer parse de DML do banco de dados para enums.
• Números mágicos não significam nada.
• Evite números mágicos em queries.

31. Códigos desnecessários comentados
31
Códigos comentados pelo sistema. Receio de apagá-lo.
É muito comum vermos um código comentado
por muito tempo e dificilmente apagam.
Geralmente são muitas linhas de código.
Não precisamos mais disso, hoje temos
versionadores, ou seja, o código não vai ser
perdido.

32. Espaçamento e formatação do código
32
• Use a formatação automática da sua IDE, no Eclipse por exemplo, use o atalho control + shift + f
e não se esqueça de configurar os caracteres máximos por linha para 120.
Nunca faça isso:
System.out.println(I + “Texto para preencher mais de 120 caracteres, Texto para preencher mais de 120……..............
Sempre deixe seu código bem indentado, às vezes a auto-formatação da IDE
vai prejudicar a indentação, nesses casos faça a indentação manualmente.

33. Espaçamento e formatação do código
33
Espaçamento entre funcionalidades:
void metodoComBomEspacamento() {
int numero1 = 0;
int numero2 = 0;
int numero3 = 0;
for (int i = 0; i < 10; i++) {
System.out.println(i);
}
int x = 0;
while(x < 5) {
x++;
}
System.out.println(x);
}
Sem espaçamento entre funcionalidades:
void metodoComMalEspacamento() {
int numero1 = 0;
int numero2 = 0;
int numero3 = 0;
for (int i = 0; i < 10; i++) {
System.out.println(i);
}
int x = 0;
while(x < 5){
x++;
}
System.out.println(x);
}

34. Conheça bem a API da linguagem
34
• Conhecer os recursos da API é fundamental para termos código de
qualidade.
• A API da linguagem é muito rica, possui muitos recursos úteis que
usamos no dia-a-dia. Usando-a efetivamente não corremos o risco de
reinventar a roda.
• Conheça também a API dos frameworks, EXTREMAMENTE IMPORTANTE,
ao menos o básico
• Keep it simple

35. Não recriar a roda com frameworks internos
35
• Ainda existem empresas
que insistem que vão
conseguir desenvolver
um framework interno
melhor que outros que já
estão no mercado por
muito tempo, maduros e
estáveis, onde pessoas
do mundo inteiro estão
continuamente
melhorando-o.

36. Use orientação a objetos!
36
• Encapsulamento
• Polimorfismo
• Composição
• Herança com muita
cautela
• Inversão de controle
• Sobrecarga
• Design Patterns
• Princípios SOLID

37. Encapsulamento
37
• Se você sabe como uma classe se comporta por fora
dela, você não está usando encapsulamento.
• Programe para interface, saiba o que a classe
faz e não como ela funciona.

38. Alta coesão
38
Classes e métodos devem ser responsáveis por apenas
uma tarefa.
Métodos com muitas linhas são questionáveis, e
precisam de refatoração.
Se seus métodos possuem uma regra muito
complexa, uma boa ideia é encapsular cada regra
em métodos privados.

39. Baixo acoplamento
39
Classes muito acopladas deixam a manutenção muito difícil.
Herança por exemplo gera um acoplamento muito alto,
quando não é necessário, é preferível usarmos composição
ao invés de herança.
Uma mudança pequena na super classe e todo seu código
pode quebrar.
Código desacoplado gera manutenção flexível.

40. Use Testes Unitários
40
• Seu código deve ser fácil de testar
• Se está difícil de testar, provavelmente seu código está
muito responsável, com alto acoplamento
• Se perceber que precisa criar mil mocks para seu teste e
tem muitos fluxos, algo também está errado, repense em
seu método
• Não adianta gerar números com testes unitários, deve-se
testar efetivamente a regra de negócio

41. SOLID
41
Os padrões SOLID são considerados uma
boa prática de programação orientada a
objetos que visam diminuir o
acoplamento entre classes e separar
responsabilidades como forma de
melhorar o código da aplicação
desenvolvida.

42. Princípios SOLID
42
· Single Responsibility Principle: princípio da responsabilidade única;
· Open Closed Principle: princípio do aberto/fechado;
· Liskov Substitution Principle: princípio da substituição de Liskov;
·Interface Segregation Principle: princípio da segregação de Interfaces;
· Dependency Inversion Principle: princípio da inversão de dependência.

43. Design Patterns
43
São soluções elegantes elaboradas para problemas recorrentes de
programação. Está completamente relacionado a Clean Code, pois
com Design Patterns é possível desenvolver código flexível,
escalável, coeso e com baixo acoplamento.
O problema é saber onde aplicar o Pattern, seu uso indevido pode
deixar o código mais complicado que deveria.

44. Design Patterns
44
Padrões de criação
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Padrões estruturais
Adapter
Bridge
Composite
Decorator
Façade (ou Facade)
Flyweight
Proxy
Padrões
comportamentais
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor

45. Bibliografia
45
Livro Clean Code – Uncle Bob
Palestra sobre SOLID e orientação a objetos com Uncle Bob
https://www.youtube.com/watch?v=QHnLmvDxGTY&list=PL0t9k9FlHnTki4D06nfKTfO9aw0xaEIwx
CodingDojo Blog
http://www.codingdojo.com/blog/clean-code-techniques/
Geeks Blog
https://geeks.uniplaces.com/clean-code-101-meaningful-names-and-functions-3d37fb12182f#.fcino5f80

46. Segunda chance!
http://eepurl.com/cCGHQD
Ou
46

47. Fim
47
Obrigado pela participação!
Dúvidas
rafacdelnero@gmail.com
GitHub
https://github.com/rafadelnero/
Twitter
https://twitter.com/RafaDelNero
Linkedin
https://br.linkedin.com/in/rafadelnero
Android App
https://play.google.com/store/apps/details?id=br.com.mediaUniversidadesAndroid