Coding Dojo - Funcionamento

688 views

Published on

Coding Dojo - Funcionamento

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
688
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Coding Dojo - Funcionamento

  1. 1. CEFET Nova FriburgoFuncionamentoProf. Thiago Delgado Pinto
  2. 2.  Estrutura Premissas Rotatividade Regras Básicas Retrospectiva
  3. 3.  Em nosso Dojo temos:  Fase 1: Exposição do seu funcionamento  Fase 2: Explicação das tecnologias envolvidas  Fase 3: Exposição do problema a ser resolvido  Fase 4: Resolução do problema  Fase 5: Retrospectiva Estamos na Fase 1!
  4. 4. 1 2 Todos devem estar dispostos a:  Aprender  Explicar  Perguntar O importante não é terminar o desafio, mas aprender com ele.
  5. 5. 1 2 Tentar não fazer:  Conversas paralelas  Entrar em discussões sobre o problema  Correr para terminar o problema  Competir com outros participantes  Deixar pessoas sem entender
  6. 6. 1 2 3 4 Dependendo do modelo de rotatividade adotado, dois programadores iniciam o desafio:  um piloto, que digita;  e um co-piloto, que auxilia o piloto com orientação verbal; Cada modelo de rotatividade favorece um aspecto da continuidade.
  7. 7. 1 2 3 41. O piloto inicia, junto ao co-piloto.2. Terminado o tempo, o piloto e o co-piloto trocam de lugar.3. Terminado o tempo, ambos voltam à platéia e uma nova dupla assume. Esse modelo favorece a dupla de programadores que entram.
  8. 8. 1 2 3 41. O piloto inicia, junto ao co-piloto.2. Terminado o tempo, o piloto vai para a platéia, o co-piloto assume o lugar de piloto e alguém da platéia assume o lugar do co- piloto. Esse modelo favorece o co-piloto, que pode prosseguir com a idéia do piloto (ou não).
  9. 9. 1 2 3 41. O piloto inicia, sozinho, sem co-piloto.2. Terminado o tempo, o piloto assume o lugar do co-piloto e alguém da platéia assume o lugar do piloto. Esse modelo favorece a platéia, pois qualquer um pode assumir de onde o piloto parou.
  10. 10. 1. Use Test-Driven Development (TDD).2. Dê um passo de cada vez.3. Só fale com a dupla quando os testes estiverem passando.4. Programe em pares.5. Faça todos entenderem.
  11. 11. Regras Básicas 1/10  TDD é uma prática que cresce a cada dia em empresas do mundo todo.
  12. 12. Regras Básicas 2/10  TDD é uma maneira diferente de construir software que tem se provado extremamente eficiente.  No ciclo básico de desenvolvimento de software, a construção é feita antes dos testes.  Em TDD, a construção é feita depois dos testes.
  13. 13. Regras Básicas 3/10  Vantagens do teste antes:  Ao escrever o teste depois (e não antes), você não passa pela fase de pensar em como irá testar seu código.  Daí, pode ser que fique difícil ou mesmo impossível testá-lo, pois você não se preocupou em criar o código de forma que pudesse verificá-lo depois.
  14. 14. Regras Básicas 4/10 1. Primeiro, você cria um teste para um pequeno pedaço de funcionalidade. 2. Então, você escreve somente o código necessário para fazer os testes rodarem corretamente. 3. Após cada incremento (funcionalidade), você refatora o código para manter sua qualidade.
  15. 15. Regras Básicas 5/10  Este é o ciclo básico do TDD: INÍCIO 1. Escreva um Teste 2. Escreva o 3. Refatore Código
  16. 16. Regras Básicas 6/10  Refatorar código significa melhorá-lo alterando sua estrutura interna sem alterar seu comportamento externo.  Por exemplo:  Ao detectar código duplicado em várias funções, você pode criar uma função que substitui esse código duplicado.  Isso não muda o comportamento do programa, mas melhora a qualidade interna.
  17. 17. Regras Básicas 7/10  Existem diversas formas de refatorar o código para melhorá-lo.  Muitas dessas formas recebem nomes:  Extract Method  Extract Interface  Replace Inheritance with Delegation  Rename Method  ...  Existem catálogos e livros de refatoração de código.  A experiência, obviamente, conta.
  18. 18. Regras Básicas 8/10  Detalhando o ciclo básico... INÍCIO 1. Escreva um 2. Rode o teste e 3. Escreva o Teste veja-o FALHAR Código 6. Rode os testes e 5. Refatore 4. Rode o teste e vejam-nos PASSAR (código e testes) veja-o PASSAR
  19. 19. Regras Básicas 9/10  Principais benefícios do TDD:  Foco na solução.  Menos defeitos.  Código melhor escrito.  Código menor.  Menor reintrodução de defeitos.  Menor tempo de correção de defeitos (MTTR).
  20. 20. Regras Básicas 10/10  O uso de TDD é costuma ser regra em Dojos, pois:  Como visto, traz diversos benefícios.  Força os programadores a pensarem diferente sobre o problema (como criá-lo de forma que possamos testá-lo?).  Expõe problemas mais cedo.  Segue um ciclo de desenvolvimento que promove melhoria contínua.
  21. 21. Regras Básicas  O uso de TDD pode ser desafiador para aqueles que estão acostumados a pensar da forma tradicional.  Assim, não tenha pressa.  Reflita sobre o problema e só então codifique.
  22. 22. Regras Básicas  Haverá um período no qual, após a codificação, os testes criados não irão “passar”.  Nesse momento é vital que a platéia não ajude a dupla e deixe-a pensar sobre como resolver oINÍCIO problema. 1. Escreva um 2. Rode o teste e 3. Escreva o Teste veja-o FALHAR Código TENTE 6. Rode os testes e 5. Refatore 4. Rode o teste e NÃO vejam-nos PASSAR (código e testes) veja-o PASSAR AJUDAR
  23. 23. Regras Básicas  A programação em pares é extremamente benéfica, pois força os integrantes a manter o foco na resolução do problema.  Enquanto um codifica, o outro verifica mentalmente o código e analisa possibilidades de melhorias e correções.
  24. 24. Regras Básicas  A dupla que está programando deve tentar “programar em voz alta”, informando o que está fazendo e porque.  Todos devem entender o que está sendo feito. Perguntem !  (Afinal, o próximo a continuar o código é alguém da platéia, que deve seguir a linha de raciocínio.)
  25. 25. Regras Básicas 1 2  As práticas de TDD e Programação em Pares é um subconjunto de práticas de uma metodologia de desenvolvimento chamada eXtreme Programming (XP).
  26. 26. Regras Básicas 1 2
  27. 27.  Ao final do Dojo, faremos uma retrospectiva. Ela serve para apontar o que foi legal e o que pode melhorar. Os pontos de melhoria serão levados em conta para próximos dojos.
  28. 28. CEFET Nova FriburgoFuncionamentoProf. Thiago Delgado Pinto

×