O documento discute princípios de robustez e qualidade de software, incluindo a Lei de Murphy, degradação graciosa, Lei de Postel, baixo acoplamento, Lei de Demeter, e legado de código. O objetivo é ensinar como desenvolvedores podem escrever software que seja resistente a falhas e problemas imprevistos.

1. Robustez de Software
Como 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

5. Como se proteger?

7. Mas o que isso
significa em software?

8. Nem sempre as premissas que
nós (desenvolvedores)
assumimos como válidas, sempre
serão válidas

9. Objeto não é null
Objeto é do tipo que eu espero
Sistema externo está no ar
Resposta é bem formatada
Input do usuário é conforme o
esperado

10. 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

11. {
"cliente":
{
"nome" : "Jonathan Bruce Postel",
"data_nascimento" : "06 de agosto de 1943",
"nacionalidade" : "Estadunidense",
"profissao" : "Cientista da computação"
}
}

12. 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;
}

13. 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?

14. Graceful Degradation
(Degradação Graciosa)
Permite que o sistema continue a operar adequadamente no
caso de falhas de alguns dos seus componentes
A redução de qualidade é proporcional à gravidade da falha

15. 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;
}

16. "Seja conservador no que você faz, seja
liberal no que você aceita dos outros"
Jonh Postel

17. De onde vieram os
componentes?
em software

18. Bom Design é só Reuso?

19. "A função de um bom software é fazer
com que o complexo pareça ser
simples"
Grady Booch

20. ALERTA
Combatento
Complexidade

21. Qual nosso arsenal pra isso?
Alta Coesão
Baixo Acoplamento

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. 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 }
}

24. 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 }
}

25. Forte Acoplamento
 Acoplamento indesejado
 Mais responsabilidade para a classe

26. Lei de Demeter
É um conjunto de regras para
construir sistemas visando baixo
acoplamento
Princípio do Mínimo Conhecimento
(Principle of Least Knowledge)

27. Não fale com estrageiros

28. Não fale com estrageiros
ou seja
Fale somente com amigos

29. Não fale com estrageiros
ou seja
Fale somente com amigos
(membros ou parametros)

30. 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 }
}

31. 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 }
}

32. produto.getCliente().getEndereco().getCEP()

33. porque um acidente de trem vai estragar o seu dia

34. produto.getCliente().getEndereco().getCEP()

35. o padrão de OO no mercado é a
“orgia dos objetos” pattern
todo mundo pega todo mundo

36. É possível aplicar o princípio em
todos os projetos?

37. Em algumas situações, forçar a utilização da
Lei de Demeter pode não ter valor maior do que
manter as regras do domínio da aplicação

38. “A Lei de Demeter na verdade
deveria ser chamada de Sugestão
de Demeter”
Martin Fowler

39. o mais importante
em um projeto é
escrever código bonito

40. o mais importante
em um projeto é
escrever código bom

41. alguém tem
um método zoado ai?!

42. Por que ele ainda não foi
refatorado?

43. O que é código legado?

44. “A principal coisa que identifica o código legado é a
falta de testes”

45. Obrigado!
while42 davidrobert
davidrobert@gmail.com

46. Onde saber mais?
RFC 793 - http://goo.gl/SeHUp
Artigo: Mocks Aren't Stubs - http://goo.gl/ffcLX
Video: Design de Software: As técnicas esquecidas http://goo.gl/1n42E
Wikipédia: Law of Demeter - http://goo.gl/PY8cm
Wikipédia: Fault-tolerant system - http://goo.gl/fS5PO
Livro: Working Effectively with Legacy Code - http://goo.gl/358zH
Livro: Introdução à Arquitetura e Design de Software - http://goo.gl/uECTc
Slides: Design de Código Qualidade a longo prazo - http://goo.gl/IDySH
Blog: Law Of Demeter - http://goo.gl/Ahh9D