Dojo#3: Batalha Naval (JavaScript)

O que?
Coding-Dojo #3

Por que?

- Por que no Dojo#2 já deixamos marcado que queríamos continuar praticando;

- Para experimentar e disseminar a técnica e as práticas relacionadas (TDD, Programação em Pares, Refatoração, Baby Steps...).

- E, como sempre, por que é divertido!!!

Quando?
29/07/2010, das 10 as 12h

Onde?
Serpro, Sala de Treinamento 06, 1o andar

Como foi a agenda?
10' - Visão geral sobre Dojo
5' - Apresentação do desafio
60' - Programação em pares, rodízio a cada 5 minutos, comentários só com teste passando
30' - Retrospectiva

Quem participou?
Serge, Márcio, Thiago, Cleverson, Marlon, Gustavo, Luis Apodi, Cleiton, Rogério, Luis Gustavo (Serpro), Otávio (Área 1), e o Fernando, Fabrício, Leandro e Tiano (Avansys).

Qual foi o desafio?
O Jogo Batalha Naval.

Em qual linguagem?

JavaScript com JSUnit, usando editor de textos Gedit e Firefox para rodar os testes unitários.

O que aprendemos?

Pontos positivos :-)
- Mudar foco do trabalho;

- Programação em pares;

- Presença de novas pessoas;

- Outras pessoas continuaram vindo;

- Compartilhamento de conhecimentos;

- Entendimento prático de acertos e erros;

- Aplicação prática de tecnologia;

- Garantia de implementação com redução de falhas;

- Adaptação a uma nova linguagem;

- Interação entre os programadores;

- Aprendizado;

- Trabalho em equipe;

- Motivação para solucionar o problema;

- Conhecimento novo na linguagem;

- Trabalho em equipe;

- Dividir a solução com várias pessoas para alcançar o resultado;

- Conhecer novas ferramentas xUnit;

- Maior participação externa;

- O desconhecimento da linguagem estimulou a criatividade;

- Rodízio de linguagens com padronização de testes com xUnit;

- Desperta o interesse em trabalha em equipe;

- Desperta o interesse em novas linguagens;

Pontos de melhoria :-(
- O tempo deveria ser de 10 minutos;

- Custo de desenvolvimento elevado;

- É interessante a elaboração de um roteiro: minimizar gaps;

- Melhorar o apoio dos participantes na resolução dos problemas;

- Muito copy and paste;

- Problema poderia ser simplificado;

- Sintaxe javascript;

- Os pilotos e copilotis ficaram muito isolados, sem comunicação com as outras pessoas;

- Falta de conhecimento da linguagem;

- Tentar não se repetir nos testes - Testar coisas diferentes como a jogada de cada um;

- Um script poucos tinham domínio;

- O desconhecimento da linguagem atrapalhou em um momento;

- Só com a prática constante é possível ter um conhecimento duradouro;

- Dimensionar melhor o problema;

- Conhecer o problema proposto;

- Evitar copiar e colar por parte dos pares;

- Perdeu um pouco o foco no objetivo: TDD.

Teve slides?
Sim, os mesmos dos Dojo 1 e 2, só que desta vez apresentados por Cleverson, para explicar os conceitos gerais sobre Coding-Dojo. Veja e ouça o SlideCast abaixo ou então baixe o PDF.

Coding Dojo em 5 Minutos

E fotos?

Então, mostre-me o o código!
Veja aqui o código que conseguimos produzir.


Você quer comentar (edita/salva e coloca também seu nome)?
Esse Dojo foi muito legal, principalmente pelas lições aprendidas. Por não simplificarmos o problema, do meio pro fim o Dojo virou muito "copy & paste" para preencher tabuleiros com os vários tipos de objeto (encouraçado, cruzador, destroyer) e nas várias posições (pra cima, pra baixo, pra direita, pra esquerda). Resultado: refatoramos muito pouco código e não testamos uma "jogada completa", ou seja, se fosse um caso real não teríamos entregue valor real para o cliente. Algo a se pensar...
Serge Rehem

Reforço a visão de Serge. Valeu muito pelas lições aprendidas. Deveríamos ter simplificado o problema para facilitar. Contudo, as pessoas pensaram pouco no TDD e na refatoração, se preocupando mais em codificar alguma coisa, para não passar em branco na sua vez. Talvez a ideia passada no início, durante a apresentação sobre o que é o Dojo, não tenha sido bem fixada: Dojo não é competição ou exibicionismo. Estamos lá para errar e acertar. Este problema também pode ter originado da falta de cultura na prática de TDD, o que leva as pessoas a não conseguirem imaginar os testes possíveis e ficam presas às ideias de primeiro codificar a funcionalidade. Neste caso, o copy + paste pode ter sido um sintoma deste problema.

Marlon Silva Carvalho