Palestra GuruPi 2013 Construindo uma aplicação cheia de bugs

401 visualizações

Publicada em

Slides da palestra realizada no 1o GuruPi de 2013.

0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
401
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Palestra GuruPi 2013 Construindo uma aplicação cheia de bugs

  1. 1. Construindo uma Aplicação Cheia de Bugs Gesiel Rios @gesielrios gesielrios@gmail.comsábado, 16 de março de 13
  2. 2. sábado, 16 de março de 13
  3. 3. sábado, 16 de março de 13
  4. 4. #Who am i ???sábado, 16 de março de 13
  5. 5. #Who am i ??? ● Professor, “Apagador de incêndio”, Programador: ● Javista; ● Rubista; ● Railer; ● Apaixonado do linguagens de programação…sábado, 16 de março de 13
  6. 6. #Who am i ??? ● Professor, “Apagador de incêndio”, Programador: ● Javista; ● Rubista; ● Railer; ● Apaixonado do linguagens de programação… ● Entusiasta por: ● Metodologias ágeis ● Ferramentas open-source ● SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion)sábado, 16 de março de 13
  7. 7. #Who am i ??? ● Professor, “Apagador de incêndio”, Programador: ● Javista; ● Rubista; ● Railer; ● Apaixonado do linguagens de programação… ● Entusiasta por: ● Metodologias ágeis ● Ferramentas open-source ● SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) ● Marido, pai do Mateus e da Marianasábado, 16 de março de 13
  8. 8. #Boas Práticas e Agilidade ?sábado, 16 de março de 13
  9. 9. #Boas Práticas e Agilidade ?sábado, 16 de março de 13
  10. 10. #Boas Práticas e Agilidade ?sábado, 16 de março de 13
  11. 11. #Então o que vamos aprender ?sábado, 16 de março de 13
  12. 12. #Então o que vamos aprender ?sábado, 16 de março de 13
  13. 13. #Então o que vamos aprender ?sábado, 16 de março de 13
  14. 14. sábado, 16 de março de 13
  15. 15. #Nosso Fluxo de Desenvolvimentosábado, 16 de março de 13
  16. 16. #Nosso Fluxo de Desenvolvimentosábado, 16 de março de 13
  17. 17. #Coleção de Bugssábado, 16 de março de 13
  18. 18. #Coleção de Bugssábado, 16 de março de 13
  19. 19. #Coleção de Bugssábado, 16 de março de 13
  20. 20. sábado, 16 de março de 13
  21. 21. sábado, 16 de março de 13
  22. 22. Bilu  bilu  haaaasábado, 16 de março de 13
  23. 23. #Go Horse Process 1- Pensou, não é XGH. XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida. 2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida. XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14). 3- Quanto mais XGH você faz, mais precisará fazer. Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito. 4- XGH é totalmente reativo. Os erros só existem quando aparecem.sábado, 16 de março de 13
  24. 24. #Go Horse Process 5- XGH vale tudo, só não vale dar o toba. Resolveu o problema? Compilou? Commit e era isso. 6- Commit sempre antes de update. Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam. 7- XGH não tem prazo. Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).sábado, 16 de março de 13
  25. 25. #Go Horse Process 8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo. Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa. 9- Seja autêntico, XGH não respeita padrões. Escreva o código como você bem entender, se resolver o problema, commit e era isso. 10- Não existe refactoring, apenas rework. Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).sábado, 16 de março de 13
  26. 26. #Go Horse Process 11- XGH é totalmente anárquico. A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4). 12- Se iluda sempre com promessas de melhorias. Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10). 13- XGH é absoluto, não se prende à coisas relativas. Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!sábado, 16 de março de 13
  27. 27. #Go Horse Process 14- XGH é atemporal. Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade. 15- XGH nem sempre é POG. Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1). 16- Não tente remar contra a maré. Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.sábado, 16 de março de 13
  28. 28. #Go Horse Process 17- O XGH não é perigoso até surgir um pouco de ordem. Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos. 18- O XGH é seu brother, mas é vingativo. Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.sábado, 16 de março de 13
  29. 29. #Go Horse Process 19- Se tiver funcionando, não rela a mão. Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível. 20- Teste é para os fracos. Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.sábado, 16 de março de 13
  30. 30. #Go Horse Process 21- Acostume-se ao sentimento de fracasso iminente. O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso! 22- O problema só é seu quando seu nome está no Doc da classe. Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.sábado, 16 de março de 13
  31. 31. #Gambi Design Patterssábado, 16 de março de 13
  32. 32. #Gambi Design Patterssábado, 16 de março de 13
  33. 33. #Gambi Design Patterssábado, 16 de março de 13
  34. 34. #Gambi Design Patters O que é um código ruim ? 1. Não vai direto ao ponto; 2. Muitas dependências; 3. Cheio de duplicação (Copiator/Colator) 4. Difícil manutenção 5. Sem nenhum padrão 6. Díficil leitura/entendimento 7. Sem cobertura de teste 8. Etc…sábado, 16 de março de 13
  35. 35. #Gambi Design Patters Mantras do Gambi Design Patters: 1. Não use nomes significativos public decimal CalcS(decimal th, decimal vh) { return th * vh; }sábado, 16 de março de 13
  36. 36. #Gambi Design Patters Mantras do Gambi Design Patters: 1. Não use nomes significativos public decimal CalcS(decimal th, decimal vh) { return th * vh; }sábado, 16 de março de 13
  37. 37. #Gambi Design Patters Mantras do Gambi Design Patters: 2. Não usem nomes pronunciáveis class DtaRcrd102 { private Date genymdhms; private Date modymdhms; private final String pszqint = “102 }sábado, 16 de março de 13
  38. 38. #Gambi Design Patters Mantras do Gambi Design Patters: 2. Não usem nomes pronunciáveis class DtaRcrd102 { private Date genymdhms; private Date modymdhms; private final String pszqint = “102 }sábado, 16 de março de 13
  39. 39. #Gambi Design Patters Mantras do Gambi Design Patters: 3. Não usem nomes buscáveis for (int j=0; j < 34; j++) { s += (t[j]*4/5; }sábado, 16 de março de 13
  40. 40. #Gambi Design Patters Mantras do Gambi Design Patters: 3. Não usem nomes buscáveis for (int j=0; j < 34; j++) { s += (t[j]*4/5; }sábado, 16 de março de 13
  41. 41. #Gambi Design Patters Mantras do Gambi Design Patters: • Observação sobre o 1o Mantar: • Classes • Nunca use SUBSTANTIVOS para representar uma classe; • Métodos • Nunca use VERBOS e FRASES VERBAIS para representar um método.sábado, 16 de março de 13
  42. 42. #Gambi Design Patterssábado, 16 de março de 13
  43. 43. #Gambi Design Patters Mantras do Gambi Design Patters: 4. Sempre que puder, coloque mais do que uma responsábilidade em classes e métodossábado, 16 de março de 13
  44. 44. #Gambi Design Patters Mantras do Gambi Design Patters: 4. Sempre que puder, coloque mais do que uma responsábilidade em classes e métodossábado, 16 de março de 13
  45. 45. #Gambi Design Patters Mantras do Gambi Design Patters: 5. Não se preocupe com indentação Quanto mais código melhor; if (unlikely(prev->policy == SCHED_RR)) if (!prev->counter) { prev->counter = NICE_TO_TICKS(prev->nice); move_last_runqueue(prev); } switch (prev->state) { case TASK_INTERRUPTIBLE: if (signal_pending(prev)) { prev->state = TASK_RUNNING; break; } default: del_from_runqueue(prev); } prev->need_resched = 0;sábado, 16 de março de 13
  46. 46. #Gambi Design Patters Mantras do Gambi Design Patters: 5. Não se preocupe com indentação Quanto mais código melhor; if (unlikely(prev->policy == SCHED_RR)) if (!prev->counter) { prev->counter = NICE_TO_TICKS(prev->nice); move_last_runqueue(prev); } switch (prev->state) { case TASK_INTERRUPTIBLE: if (signal_pending(prev)) { prev->state = TASK_RUNNING; break; } default: del_from_runqueue(prev); } prev->need_resched = 0;sábado, 16 de março de 13
  47. 47. #Gambi Design Patters Mantras do Gambi Design Patters:sábado, 16 de março de 13
  48. 48. #Gambi Design Patters Mantras do Gambi Design Patters: 6. Código   não   é   Romance   e   nem   poesia.sábado, 16 de março de 13
  49. 49. #Gambi Design Patters Mantras do Gambi Design Patters: 6. Código   não   é   Romance   e   nem   poesia. Quer   lê,   compre   um   livro   seu   CABRAsábado, 16 de março de 13
  50. 50. sábado, 16 de março de 13
  51. 51. #Gambi Design Patters Mantras do Gambi Design Patters: 7. Não economize nos ifs private String getIdentifierName(Class<?> cls) { if (!identifierNames.containsKey(cls)) { String name = null; if (cls.isAnnotationPresent(Identifier.class)) { Identifier identifier = (Identifier) cls.getAnnotation(Identifier.class); if (identifier.name() != null && !"".equals(identifier.name().trim())) { name = identifier.name(); } } if (name == null) { name = cls.getName().substring(cls.getName().lastIndexOf(.) + 1); } identifierNames.put(cls, name); return name; } return identifierNames.get(cls); }sábado, 16 de março de 13
  52. 52. sábado, 16 de março de 13
  53. 53. #Gambi Design Patters Mantras do Gambi Design Patters: 8. Use e abuse de comentários /** * Default constructor. */ protected AnnualDateRule() { } /** The day of the month. */ Private int dayOfMonth; /** * Returns the day of the month. * * @return the day of the month. */ public int gatDayOfMonth() { return day ofMonth; }sábado, 16 de março de 13
  54. 54. #Gambi Design Patters Mantras do Gambi Design Patters: 9. Não se preocupe com o uso do banco de dados def acessar @consulta = Consulta.find_by_cpf_and_placa_and_renavam params[:acesso] [:cpf].gsub(/[.-]/, ), params[:acesso][:placa], params[:acesso][:renavam] unless @consulta flash[:error] = "Transferência não encontrada para o veículo informado." redirect_to action: :index return end #Validacao Recaptcha err = ActiveModel::Errors.new "" unless validate_recap(params, err) flash[:error] = "Código de Segurança inválido, tente novamente." redirect_to :action => :index else session[:consulta_id] = @consulta.id redirect_to consultas_url end endsábado, 16 de março de 13
  55. 55. #Gambi Design Patters Mantras do Gambi Design Patters:sábado, 16 de março de 13
  56. 56. #Gambi Design Patters Mantras do Gambi Design Patters: 10. Esqueça  os  TESTES,  o   importante  é  fazer  a  bagaça   funcionar.sábado, 16 de março de 13
  57. 57. #Gambi Design Patterssábado, 16 de março de 13
  58. 58. Não seja responsável por escrever código LIXO do futuro !sábado, 16 de março de 13
  59. 59. #Falando sério...sábado, 16 de março de 13
  60. 60. #Falando sério... “Qualquer   um   pode   escrever   código   que   um   computador   possa  entender. Bons   programadores   escrevem   código   que   humanos   podem   entender.”sábado, 16 de março de 13
  61. 61. sábado, 16 de março de 13
  62. 62. sábado, 16 de março de 13
  63. 63. #chega de código lixo...sábado, 16 de março de 13
  64. 64. Obrigado... Gesiel Rios @gesielrios gesielrios@gmail.comsábado, 16 de março de 13

×