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

Problemas graves com bugsAcho que a maioria ou todos aqui já teve problemas gravíssimos com bugs, vamos

falar um pouco sobre isso!

2

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

Ou

3

É 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

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

Uma técnica muito conhecida

Clean Code! Usando-a efetivamente já conseguimos um resultado excelente!

6

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

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

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

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

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

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

É 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!

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

Use nomes pronunciáveis

15

Mal exemplo:String endrcoEntr;String nmCli;String nmProd;

Bom exemplo: String enderecoDeEntrega;String nomeDoCliente;String nomeDoProduto;

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.

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.

Use verbos para métodos e substantivos para classes e atributos

18

class Produto{ // Substantivoprivate double preco; // Substantivo

public void aumentaPreco(double valor) { // Verbo/ação this.preco += valor;}

}

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

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.

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

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);

}

}

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); }

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

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.

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 descontoif (funcionario.getValorFatura() > 200 && funcionario.getDiaDaCompra() == BLACKFRIDAY_DAY)

Isso é bom:if (funcionario.isElegivelParaReceberDesconto ())

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)

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 alteradoif (!clienteDTO.isInformacaoEditada) {

throw new DadoInconsistenteException();}

}

Crie isso:public void salvaHistoricoDoCliente(ClienteDTO clienteDTO) {

verificaSeClienteFoiAlterado(clienteDTO);}

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.

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.

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.

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.

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);

}

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

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.

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

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.

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.

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.

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

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.

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.

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.

Design Patterns

44

Padrões de criaçãoAbstract FactoryBuilderFactory MethodPrototypeSingleton

Padrões estruturaisAdapterBridgeCompositeDecoratorFaçade (ou Facade)FlyweightProxy

Padrões comportamentaisChain of ResponsibilityCommandInterpreterIteratorMediatorMementoObserverStateStrategyTemplate MethodVisitor

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

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

Ou

46

Fim

47

Obrigado pela participação!

Dúvidas rafacdelnero@gmail.com

GitHubhttps://github.com/rafadelnero/

Twitter

https://twitter.com/RafaDelNero

Linkedinhttps://br.linkedin.com/in/rafadelnero

Android Apphttps://play.google.com/store/apps/details?id=br.com.mediaUniversidadesAndroid