Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ZeroBugsProject - Técnicas de programação efetivas

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

  • Login to see the comments

ZeroBugsProject - Técnicas de programação efetivas

  1. 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. 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. 3. Valiosas dicas gratuitas! http://eepurl.com/cCGHQD Ou 3
  4. 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. 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. 6. Uma técnica muito conhecida Clean Code! Usando-a efetivamente já conseguimos um resultado excelente! 6
  7. 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. 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. 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. 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. 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. 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. 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. 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. 15. Use nomes pronunciáveis 15 Mal exemplo: String endrcoEntr; String nmCli; String nmProd; Bom exemplo: String enderecoDeEntrega; String nomeDoCliente; String nomeDoProduto;
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 46. Segunda chance! http://eepurl.com/cCGHQD Ou 46
  47. 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

×