Post on 11-Apr-2017
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
Fim
47
Obrigado pela participação!
Dúvidas rafacdelnero@gmail.com
GitHubhttps://github.com/rafadelnero/
https://twitter.com/RafaDelNero
Linkedinhttps://br.linkedin.com/in/rafadelnero
Android Apphttps://play.google.com/store/apps/details?id=br.com.mediaUniversidadesAndroid