SlideShare uma empresa Scribd logo
CEFET Nova Friburgo




Funcionamento
Prof. Thiago Delgado Pinto
   Estrutura
   Premissas
   Rotatividade
   Regras Básicas
   Retrospectiva
   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!
1 2



   Todos devem estar dispostos a:
     Aprender
     Explicar
     Perguntar


   O importante não é terminar o desafio, mas
    aprender com ele.
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
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.
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.
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).
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.
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.
Regras Básicas


                                                    1/10



      TDD é uma prática que cresce a cada dia em
       empresas do mundo todo.
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.
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.
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.
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
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.
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.
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
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).
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.
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.
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
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.
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.)
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).
Regras Básicas


                 1 2
   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.
CEFET Nova Friburgo




Funcionamento
Prof. Thiago Delgado Pinto

Mais conteúdo relacionado

Mais procurados

TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação
Icaro Camelo
 
Seja Um Programador Pragmatico
Seja Um Programador PragmaticoSeja Um Programador Pragmatico
Seja Um Programador Pragmatico
Leonardo Fernandes
 
Test driven development teste e design no mundo real by mauricio aniche (z-li...
Test driven development teste e design no mundo real by mauricio aniche (z-li...Test driven development teste e design no mundo real by mauricio aniche (z-li...
Test driven development teste e design no mundo real by mauricio aniche (z-li...
GessdaSilvaMachado
 
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Gabriel Rubens
 

Mais procurados (20)

TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação
 
Testes Unitários
Testes UnitáriosTestes Unitários
Testes Unitários
 
O programador pragmático
O programador pragmáticoO programador pragmático
O programador pragmático
 
O Programador Pragmático
O Programador PragmáticoO Programador Pragmático
O Programador Pragmático
 
TDD - Pós Graduação em Engenharia de Software Ágil
TDD - Pós Graduação em Engenharia de Software ÁgilTDD - Pós Graduação em Engenharia de Software Ágil
TDD - Pós Graduação em Engenharia de Software Ágil
 
TDD
TDDTDD
TDD
 
Clean Code - Fork In Tuba
Clean Code - Fork In TubaClean Code - Fork In Tuba
Clean Code - Fork In Tuba
 
TDD - Test Driven Development
TDD - Test Driven DevelopmentTDD - Test Driven Development
TDD - Test Driven Development
 
Refactory Worshop
Refactory WorshopRefactory Worshop
Refactory Worshop
 
Desenvolvimento dirigido por comportamento e por teste
Desenvolvimento dirigido por comportamento e por testeDesenvolvimento dirigido por comportamento e por teste
Desenvolvimento dirigido por comportamento e por teste
 
Tdd direto das trincheiras
Tdd direto das trincheirasTdd direto das trincheiras
Tdd direto das trincheiras
 
Seja Um Programador Pragmatico
Seja Um Programador PragmaticoSeja Um Programador Pragmatico
Seja Um Programador Pragmatico
 
Test driven development teste e design no mundo real by mauricio aniche (z-li...
Test driven development teste e design no mundo real by mauricio aniche (z-li...Test driven development teste e design no mundo real by mauricio aniche (z-li...
Test driven development teste e design no mundo real by mauricio aniche (z-li...
 
TDD - A Verdadeira Face do Teste
TDD - A Verdadeira Face do TesteTDD - A Verdadeira Face do Teste
TDD - A Verdadeira Face do Teste
 
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
 
Qualidade no desenvolvimento de Sistemas por Anderson Augustinho (Celepar)
Qualidade no desenvolvimento de Sistemas por Anderson Augustinho (Celepar)Qualidade no desenvolvimento de Sistemas por Anderson Augustinho (Celepar)
Qualidade no desenvolvimento de Sistemas por Anderson Augustinho (Celepar)
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
TDD Direto das Trincheiras versao 2
TDD Direto das Trincheiras versao 2TDD Direto das Trincheiras versao 2
TDD Direto das Trincheiras versao 2
 
Dojo abril
Dojo abrilDojo abril
Dojo abril
 

Destaque

Destaque (12)

Mapa Conceptual Blog De Informatica 11 6 Portada Y Cuadro
Mapa Conceptual Blog De Informatica 11 6 Portada Y CuadroMapa Conceptual Blog De Informatica 11 6 Portada Y Cuadro
Mapa Conceptual Blog De Informatica 11 6 Portada Y Cuadro
 
Big data
Big dataBig data
Big data
 
Vamos Descobrir AntóNimos
Vamos Descobrir AntóNimosVamos Descobrir AntóNimos
Vamos Descobrir AntóNimos
 
Grp2 )
Grp2  )Grp2  )
Grp2 )
 
Mind map
Mind mapMind map
Mind map
 
P and e
P and eP and e
P and e
 
Big Fat Maricar's Road to 50th Floor
Big Fat Maricar's Road to 50th FloorBig Fat Maricar's Road to 50th Floor
Big Fat Maricar's Road to 50th Floor
 
Actor planning
Actor planningActor planning
Actor planning
 
Οδηγός Μουσείων Θεσσαλονίκης
Οδηγός Μουσείων ΘεσσαλονίκηςΟδηγός Μουσείων Θεσσαλονίκης
Οδηγός Μουσείων Θεσσαλονίκης
 
SR PRESS RELEASE
SR PRESS RELEASESR PRESS RELEASE
SR PRESS RELEASE
 
I Live in a World (D 'Originals)
I Live in a World (D 'Originals)I Live in a World (D 'Originals)
I Live in a World (D 'Originals)
 
Skates
SkatesSkates
Skates
 

Semelhante a Coding Dojo - Funcionamento

Introdução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCastingIntrodução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCasting
Pedro Pereira Martins
 
Programação Pragmática
Programação PragmáticaProgramação Pragmática
Programação Pragmática
elliando dias
 

Semelhante a Coding Dojo - Funcionamento (20)

TDD: A Essência do Mantra
TDD: A Essência do MantraTDD: A Essência do Mantra
TDD: A Essência do Mantra
 
Sobre TDD - Tech Friday da Everis Uberlândia
Sobre TDD - Tech Friday da Everis UberlândiaSobre TDD - Tech Friday da Everis Uberlândia
Sobre TDD - Tech Friday da Everis Uberlândia
 
UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27
 
TDC 2012 TDD e 20 coisas que você precisa saber
TDC 2012 TDD e 20 coisas que você precisa saberTDC 2012 TDD e 20 coisas que você precisa saber
TDC 2012 TDD e 20 coisas que você precisa saber
 
Refatoração de Código Legado
Refatoração de Código LegadoRefatoração de Código Legado
Refatoração de Código Legado
 
Introdução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCastingIntrodução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCasting
 
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
 
Treinamento TDD - Atech
Treinamento TDD - AtechTreinamento TDD - Atech
Treinamento TDD - Atech
 
Os Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de softwareOs Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de software
 
Codigo limpo
Codigo limpoCodigo limpo
Codigo limpo
 
Como TDD pode influenciar na construção do seu Produto?
Como TDD pode influenciar na construção do seu Produto?Como TDD pode influenciar na construção do seu Produto?
Como TDD pode influenciar na construção do seu Produto?
 
Teste Driven Development
Teste Driven DevelopmentTeste Driven Development
Teste Driven Development
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Tdd x testes unidades
Tdd x testes unidadesTdd x testes unidades
Tdd x testes unidades
 
Programação Pragmática
Programação PragmáticaProgramação Pragmática
Programação Pragmática
 
Introdução ao Test Driven Development (TDD)
Introdução ao Test Driven Development (TDD)Introdução ao Test Driven Development (TDD)
Introdução ao Test Driven Development (TDD)
 
Coding Dojo Aplicado ao Ambiente Organizacional
Coding Dojo Aplicado ao Ambiente OrganizacionalCoding Dojo Aplicado ao Ambiente Organizacional
Coding Dojo Aplicado ao Ambiente Organizacional
 
Debugging node
Debugging nodeDebugging node
Debugging node
 
O que é ser um bom programador?
O que é ser um bom programador?O que é ser um bom programador?
O que é ser um bom programador?
 
Test-Driven Development serve pra mim?
Test-Driven Development serve pra mim?Test-Driven Development serve pra mim?
Test-Driven Development serve pra mim?
 

Mais de thiagodp (6)

Coding Dojo - Conceitos
Coding Dojo - ConceitosCoding Dojo - Conceitos
Coding Dojo - Conceitos
 
CEFET Coding Dojo - Divulgação
CEFET Coding Dojo - DivulgaçãoCEFET Coding Dojo - Divulgação
CEFET Coding Dojo - Divulgação
 
CEFET Coding Dojo - Desafios
CEFET Coding Dojo - DesafiosCEFET Coding Dojo - Desafios
CEFET Coding Dojo - Desafios
 
TDD em C++
TDD em C++TDD em C++
TDD em C++
 
DOJO - TDD com C++
DOJO - TDD com C++DOJO - TDD com C++
DOJO - TDD com C++
 
I CEFET Coding Dojo - Divulgação
I CEFET Coding Dojo - DivulgaçãoI CEFET Coding Dojo - Divulgação
I CEFET Coding Dojo - Divulgação
 

Coding Dojo - Funcionamento

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