Your SlideShare is downloading. ×
  • Like
Robustez de Software - Como ouvir menos reclamações dos seus chefes
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Robustez de Software - Como ouvir menos reclamações dos seus chefes

  • 1,104 views
Published

Slides da palestra apresentada no TDC 2012 na trilha de Arquitetura - A robustez é a capacidade do sistema funcionar mesmo em condições anormais. Esta palestra prentende demonstrar algumas técnicas …

Slides da palestra apresentada no TDC 2012 na trilha de Arquitetura - A robustez é a capacidade do sistema funcionar mesmo em condições anormais. Esta palestra prentende demonstrar algumas técnicas que podem ser usadas no desenvolvimento de software com intuito de auxiliar o desenvolvedor a produzir sistemas robustos.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,104
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
23
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Robustez de SoftwareComo ouvir menos reclamações dos seus chefes David Robert Camargo de Campos Mestre em Ciência da Computação Globalcode – Open4education
  • 2. quem sou eu?while42 davidrobert davidrobert@gmail.com
  • 3. Agenda (1) Lei de Murphy (2) Robustez de Software (3) Graceful Degradation (4) Lei de Postel (5) Bom Desing e Reuso (6) Combatendo Complexidade (7) Lei de Demeter (8) Código Legado
  • 4. Como se proteger?
  • 5. Mas o que issosignifica em software?
  • 6. Nem sempre as premissas que nós (desenvolvedores)assumimos como válidas, sempre serão válidas
  • 7. Objeto não é nullObjeto é do tipo que eu espero Sistema externo está no ar Resposta é bem formatadaInput do usuário é conforme o esperado
  • 8. Robustez X Precisão Precisão: Habilidade de executar as tarefas para as quais foi definido nos requisitos Robustez: Habilidade de funcionar mesmo em situações anormais
  • 9. { "cliente": { "nome" : "Jonathan Bruce Postel", "data_nascimento" : "06 de agosto de 1943", "nacionalidade" : "Estadunidense", "profissao" : "Cientista da computação" }}
  • 10. public Cliente parserDeCliente() throws JSONException { JSONObject json = // ... String nome = json.getString("nome"); String data = json.getString("data_nascimento"); String nacionalidade = json.getString("nacionalidade"); String naturalidade = json.getString("naturalidade"); String profissao = json.getString("profissao"); Cliente cliente = new Cliente(nome); // ... return cliente;}
  • 11. Faz sentido o invocador do método ter que conhecer a JSONException? Faz sentido lançar uma exceção só por não ter a naturalidade no JSON?
  • 12. Graceful Degradation (Degradação Graciosa)Permite que o sistema continue a operar adequadamente nocaso de falhas de alguns dos seus componentesA redução de qualidade é proporcional à gravidade da falha
  • 13. public Cliente parserDeCliente() throws MinhaException { Cliente cliente; try { JSONObject json = // ... cliente = new Cliente(json.getString("nome")); } catch (JSONException e) { throw new MinhaException("Faltou o nome"); } // ... try { cliente.setNaturalidade(json.getString("naturalidade")); } catch (JSONException e) { /* ... */ } // ... return cliente;}
  • 14. "Seja conservador no que você faz, sejaliberal no que você aceita dos outros" Jonh Postel
  • 15. De onde vieram oscomponentes?em software
  • 16. Bom Design é só Reuso?
  • 17. "A função de um bom software é fazercom que o complexo pareça sersimples" Grady Booch
  • 18. ALERTACombatentoComplexidade
  • 19. Qual nosso arsenal pra isso? Alta CoesãoBaixo Acoplamento
  • 20. public class Financeiro { // ...1 public void executarPagamentos() {2 for (Cliente cliente: clientes) {3 if (cliente.getCarteira().getSaldo() >= valor){4 cliente.getCarteira().subtrai(valor);5 // ...6 pagantes.add(cliente);7 }8 }9 }}
  • 21. public class Financeiro { // ...1 public void executarPagamentos() {2 for (Cliente cliente: clientes) {3 if (cliente.getCarteira().getSaldo() >= valor){4 cliente.getCarteira().subtrai(valor);5 // ...6 pagantes.add(cliente);7 }8 }9 }}
  • 22. public class Financeiro { // ...1 public void executarPagamentos() {2 for (Cliente cliente: clientes) {3 if (cliente.getCarteira().getSaldo() >= valor){4 cliente.getCarteira().subtrai(valor);5 // ...6 pagantes.add(cliente);7 }8 }9 }}
  • 23. Forte Acoplamento Acoplamento indesejado Mais responsabilidade para a classe
  • 24. Lei de DemeterÉ um conjunto de regras paraconstruir sistemas visando baixoacoplamentoPrincípio do Mínimo Conhecimento (Principle of Least Knowledge)
  • 25. Não fale com estrageiros
  • 26. Não fale com estrageiros ou sejaFale somente com amigos
  • 27. Não fale com estrageiros ou sejaFale somente com amigos (membros ou parametros)
  • 28. public class Cliente { private Carteira carteira; // ...1 public boolean fazerPagamento(double valor) {2 if (carteira.getSaldo() >= valor) {3 carteira.subtrai(valor);4 return true;5 }6 return false;7 }}
  • 29. public class Financeiro { // ...1 public void executarPagamentos() {2 for (Cliente cliente: clientes) {3 if (cliente.fazerPagamento(valor)) {5 // ...6 pagantes.add(cliente);5 }6 }7 }}
  • 30. produto.getCliente().getEndereco().getCEP()
  • 31. porque um acidente de trem vai estragar o seu dia
  • 32. produto.getCliente().getEndereco().getCEP()
  • 33. o padrão de OO no mercado é a “orgia dos objetos” pattern todo mundo pega todo mundo
  • 34. É possível aplicar o princípio em todos os projetos?
  • 35. Em algumas situações, forçar a utilização daLei de Demeter pode não ter valor maior do que manter as regras do domínio da aplicação
  • 36. “A Lei de Demeter na verdade deveria ser chamada de Sugestão de Demeter”Martin Fowler
  • 37. o mais importante em um projeto éescrever código bonito
  • 38. o mais importante em um projeto éescrever código bom
  • 39. alguém temum método zoado ai?!
  • 40. Por que ele ainda não foi refatorado?
  • 41. O que é código legado?
  • 42. “A principal coisa que identifica o código legado é a falta de testes”
  • 43. Obrigado! while42 davidrobert davidrobert@gmail.com
  • 44. Onde saber mais?RFC 793 - http://goo.gl/SeHUpArtigo: Mocks Arent Stubs - http://goo.gl/ffcLXVideo: Design de Software: As técnicas esquecidas http://goo.gl/1n42EWikipédia: Law of Demeter - http://goo.gl/PY8cmWikipédia: Fault-tolerant system - http://goo.gl/fS5POLivro: Working Effectively with Legacy Code - http://goo.gl/358zHLivro: Introdução à Arquitetura e Design de Software - http://goo.gl/uECTcSlides: Design de Código Qualidade a longo prazo - http://goo.gl/IDySHBlog: Law Of Demeter - http://goo.gl/Ahh9D