1. O documento descreve as regras e fases de funcionamento de um Dojo realizado no CEFET Nova Friburgo.
2. O Dojo tem 5 fases: exposição do funcionamento, explicação das tecnologias, exposição do problema, resolução do problema e retrospectiva.
3. As regras incluem usar Test Driven Development, programação em pares, explicar o raciocínio em voz alta e não ajudar a dupla quando os testes não passarem para que eles resolvam o problema.
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. 1 2
Todos devem estar dispostos a:
Aprender
Explicar
Perguntar
O importante não é terminar o desafio, mas
aprender com ele.
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. 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. 1 2 3 4
1. 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. 1 2 3 4
1. 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. 1 2 3 4
1. 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. 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. Regras Básicas
1/10
TDD é uma prática que cresce a cada dia em
empresas do mundo todo.
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 o
INÍ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. 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. 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. 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).
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.