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.

1. CEFET Nova Friburgo
Funcionamento
Prof. Thiago Delgado Pinto

2.  Estrutura
 Premissas
 Rotatividade
 Regras Básicas
 Retrospectiva

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

26. Regras Básicas
1 2

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. CEFET Nova Friburgo
Funcionamento
Prof. Thiago Delgado Pinto