O documento discute porque erros acontecem em programas de computador e como lidar com eles. Apresenta várias causas comuns de erros como má arquitetura de software, uso inadequado de abstrações e falta de atualização de sistemas. Também dá dicas sobre como prevenir e resolver erros, como testes automatizados, deploy frequente e monitoramento. Conclui enfatizando a importância do trabalho de desenvolvedor para evitar problemas.

1. http://borba.blog.br
Merda Acontece
Luiz Borba

2. 1989Estudante
1991
Programador
1994
Empreendedor
Analista
de
Tecnologia
1998
Líder
Técnico
2000
2001
Arquiteto de
Software
2005
Scrum
Master
2010
Consultor em
Tecnologia
2014(?)
Consultor em
Negócios
Quem é
Luiz Borba?

3. Ada Lovelace
“Think of my horror then at just
discovering that the table & diagram
(over which I have been spending
infinite patience & pains) are seriously
wrong, in one or two points”.
1843

4. Grace Hopper
1952
A-0primeiro compilador já
escrito para um
computador eletrônico

5. 1947

6. “As soon as we started programming,
we found to our surprise that it wasn't
as easy to get programs right as we
had thought. Debugging had to be
discovered. I can remember the exact
instant when I realized that a large
part of my life from then on was going
to be spent in finding mistakes in my
own programs”.
(Maurice Wilkes, 1949)

7. "There is no program that, given a
description of an arbitrary computer
program, can decide whether the
program finishes running or continues to
run forever".
(Alan Turing, 1936)

8. Seja empírica ou
matematicamente, já faz
décadas que descobrimos
que MERDA ACONTECE!

9. 1º Ato
Porque a Merda Acontece?

10. Onde há catinga, há merda

11. Martin Fowler’s Code Smells
Duplicated Code
Long Method
Large Class
Long Parameter List
Divergent Change
Shotgun Surgery
Feature Envy
Data Clumps
Primitive Obsession
Switch Statements
Parallel Inheritance Hierarchies
Lazy Class
Speculative Generality
Temporary Field
Message Chains
Middle Man
Inappropriate Intimacy
Alternative Classes with Different Interfaces
Incomplete Class Libraries
Data Class
Refused Bequest
Comments

13. Merda Acontece porque
deixamos janelas quebradas

14. O milagre da multiplicação

16. Cuidado com ORM

17. Merda Acontece porque
usamos abstrações sem saber
o que acontece por “debaixo
dos panos”

18. As 2 Leis de Borba

19. Primeira Lei de Arquitetura
de Software de Borba
(Borba's 1st Software Architecture Law)

20. Primeira Lei de Arquitetura
de Software de Borba
(Borba's 1st Software Architecture Law)
Toda arquitetura definida está errada.

21. Precisa PROVAR!

22. Segunda Lei de Arquitetura
de Software de Borba
(Borba's 2nd Software Architecture Law)

23. Segunda Lei de Arquitetura
de Software de Borba
(Borba's 2nd Software Architecture Law)
Toda arquitetura definida que
comprovadamente funciona
estará errada em breve.

24. As coisas mudam
• Tecnologias mudam
• Requisitos/Planos/Negócios mudam
• Pessoas mudam
• Usuários mudam
• TUDO MUDA. O TEMPO TODO.

25. Twitter no Início

26. Twitter Hoje

27. Merda Acontece porque não
evoluimos nossos sistemas ao
longo do tempo

28. O Banco do Tio Patinhas

29. Como alterar
configurações no
computador do Banco
do Tio Patinhas

30. Merda Acontece quando
operadores são dementes

31. 2º Ato
Como lidar com a Merda?

32. Logs

33. Sua Aplicação falha, usuários lhe esculhambam

34. Crash Analysis

35. Obter os logs de execução e
analisa-los ajuda a descobrir
rapidamente os problemas
quando a Merda Acontece

36. Descomendo em
Produção

37. Deploy em
Produção

38. Como voltar no tempo?

39. $ git push heroku master

40. class AddCurrentToVendor < ActiveRecord::Migration
def up
articles = select_all('SELECT * FROM articles')
articles.each do |article|
first_vendor = select_one("SELECT * FROM vendors WHERE article_id = #{article['id']}")
if first_vendor
update("UPDATE vendors SET current=#{quoted_true} WHERE id=#{first_vendor['id']}")
end
end
end
def down
remove_column :vendors, :current
end
end
Migrations (Rails)

41. Esteja sempre preparado para
voltar atrás quando a Merda
Acontece

42. O Paradoxo do Deploy

43. Porque temos
medo do Deploy?
O Deploy de 180 Dias

44. Deploy Frequente minimiza a
chance de dar Merda e
quando acontece, é mais fácil
de detectar o problema

45. O Caso Facebook

46. Qual a frequência de deploy
em produção do Facebook?

47. 2 vezes por dia

48. E o que acontece quando dá
merda?

49. "Reverting is for losers!"
(Chuck Rossi)

50. IRC para localizar os
desenvolvedores, resolver a
bronca na hora e fazer um
novo deploy

51. Desenvolvedores
tem karma

52. Quanto tempo leva o processo
de deploy? (dezenas de
milhares de servidores e um
pacote de 1.5Gb)

55. Como descobrir se deu
merda?

56. Monitoramento do Facebook
analisa até o que o pessoal do
Twitter tá falando

57. Facebook sabe das coisas, se
você não sabe o que fazer,
copie dos melhores

58. 3º Ato
Tendências

59. Testes Automatizados

61. Só teremos velocidade de
recuperação se nossos testes
forem automatizados

62. Vagrant e Docker

64. Operação deve ser o mais
simples possível

65. Um C seguro

66. Rust

67. Linguagens e Frameworks
devem ajudar a evitar que
desenvolvedor cometa erros

68. Epílogo
Sobre Você

69. “That’s 30 Minutes Away. I’ll be there in 10.”
(Wiston ‘The Wolf’ Wolfe)
Seja Rápido

70. “No more half
measures, Walt”
(Mike Ehrmantraut)
Seja Decisivo

71. Automatize
TUDO

72. Use Unix

73. Não seja um
Embola Bosta

74. O nosso trabalho é cada vez
mais importante e se não
tivermos cuidado, muitos
inocentes vão pagar o pato

75. Skynet

76. Replicantes

77. Cylons

78. Obrigado!
http://borba.blog.br
Luiz Borba