Data: 14/02/2009 - 13:30
Participantes: Carol, Célio, Cícero, Túlio, Willi e Victor.

Problema: http://groups.google.com.br/group/dojo-brasilia/web/Problema-robosExploradores.pdf?hl=pt-BR

Repositório:  http://github.com/tulios/dojo-brasilia-robosexploradores

Histórico do GIT: http://github.com/tulios/dojo-brasilia-robosexploradores/commits/master/

Objetivo: Resolver o desafio dos robos exploradores.

duplas:

Inicialmente houve uma discussão entre todos para a resolução do problema.

Célio e Victor

     Definiram uma lógica recursiva para o método andar, mudando o seu retorno para char[][]; 

Victor e Túlio

      Retiraram a recursividade do explorarMapas para deixá-la apenas com o método andar.

Colocaram como parâmetro um valor para o número de passos dados pelo robô. 

Túlio e Cícero

      Adicionaram a cada movimento dentro de andar, uma nova chamada recursiva. 

Cícero e Carol

      Tentaram comentar a condição de parada em caso de caminho sem saída, mas isso não resolveu o problema,

gerou uma recursão infinita, voltaram ao normal depois disso. Mudaram a condição de retorno no explorarMapas,

mas também não obtiveram sucesso. Melhoraram a condição de parada do naoPodeAndar para

naoPodeAndar e arraymapa1 == null e conseguiram passar quase todos os testes menos o de beco sem saída.

Carol e Célio

      Construíram uma lógica para identificar a posição vertical do robô em relação ao final que retorna nulo ao

identificar um beco sem saída e todos os testes passaram. Em seguida iniciaram um refactory.  

Célio e Victor

      Na verdade Célio queria simplificar a lógica utilizada e decidiu reescrever o andar. Decidiram testar

e perceberam que da forma simplificada a maioria dos testes passavam e decidiram investir nessa nova abordagem. 

Victor e Túlio

      Para que a reescrita do Célio funcionasse teríamos que fazer várias outras condições. Então decidiram por ficar

com a idéia anterior, que já funcionava. Decidiram pela lógica de verificar quantos caminhos o robô pode fazer na

posição em que ele está. Para então chamar o método andar para caso posição possível. 

Túlio e Cícero

      Criaram uma condição dentro de andar que verifica em quantas direções há a possibilidade de movimentação.

Dentro desta condição, criaram um contador para cada possível direção (cEsquerda, cDireita, ...) e este contador

receber o resultado retornado por andar() passando cada uma das possíveis direções. Após isto, é retornado o menor

de todos os percursos.

 

Cícero e Willi

      Identificaram a pequena falha no algoritmo escrito, que era a falta de verificação da possibilidade de andar antes

de andar. Escreveram as verificações antes de andar, e ficaram apanhando para erros de compilação por

variáveis não inicializadas. Conseguiram resolver o problema e ficaram apanhando com um nullPointer, precisavam

verificar se os mapas existiam antes de andar neles. Conseguiram verificar os mapas e ficaram com um erro pequeno,

eles não perceberam que os mapas que não foram movimentados não poderiam entrar na contagem, por isso a solução

ainda não passou todos os testes.

Willi e Carol

      Fizeram a correção dos mapas que não foram movimentados para não entrar na contagem

(Caso não mude o valor, ou seja maior que -1), a solução ainda não passou nos testes. Willi digitou $ várias vezes.

A seta pra direita ta no lugar errado!! 

Carol e Célio

      Os testes estão dando erro sempre que há bifurcações. Fizeram um chinesinho pra descobrir onde está o erro.

As variáveis de posicionamento não estavam sendo incrementadas. Após incrementar, os testes novamente não

passaram. O código ta cheio de IF... Tem um monte de IF pra cada decisão. Eu mesmo só fui chutando modificações

pra ver se funcionava. Aprendi que essa não é uma boa estratégia. Mas enfim, pelo menos eu não fiquei parado na

frente do código com cara de bunda... Fizeram mais não-sei-o-quê e o teste não rodou de novo. 

Célio e Victor

      Continuando a busca do detalhe perdido. Tiveram certa dificuldade para identificar a recursividade depois da

composição dos algoritmos (Com mais de um caminho e com apenas um caminho). O tempo acabou e eles não

conseguiram avançar na solução.

Victor e Túlio

      Continuaram com o problema das bifurcações. Debugaram o método para encontrar onde estava o problema.
Viram que quando não há caminhos possíveis ele não retorna null. Porém não chegaram a uma solução para o problema.