Apelo: parem de "ensinar" Comp. I nas faculdades!

Vinicius Manhães Teles — Fri, 28 May 2010 09:03:00 -0300

Faço um apelo aos cursos universitários de computação: parem de ensinar "Comp. I". Ao invés disso, usem o horário que seria da aula para os alunos fazerem Dojo de programação. Essa é uma ideia que certamente será ignorada, mas, estou certo de que poderia elevar demais a qualidade da formação dos "calouros" de computação, se fosse adotada.

Todo curso de computação tem uma matéria introdutória para os alunos "aprenderem" a arte da programação. Em alguns lugares chama-se Computação I, em outros Introdução à Programação e assim por diante. Com raríssimas exceções, o aluno começa o semestre sabendo pouco de programação e termina sabendo tão pouco quanto, mas com a falsa sensação de saber um pouquinho mais. Em outras palavras, é tempo mal investido, tanto para os professores, quanto para os alunos. Em alguns casos, é o suficiente para o aluno abandonar a Computação.

Isso não reflete a falta de esforço do professor em fazer os alunos aprenderem. Mas, sim a ineficácia do método, em comparação a outros mais poderosos e prazerosos. Estou me referindo ao Dojo, naturalmente. E para mostrar o porquê, citarei o exemplo do que está acontecendo na UFF.

Ontem estive no Dojo de programação da UFF, que acontece toda quinta à noite e é aberto a toda a comunidade de desenvolvimento do Rio de Janeiro, Niterói e adjacências. Desde a semana passada, estamos contando com a presença de muitos calouros, o que é excelente. Só que ontem foi especial.

O problema escolhido foi o Jokenpo, ou Pedra, papel e tesoura. O enunciado do problema é simples, mas a solução tem uns detalhezinhos que deixam espaço para a galera pensar um bocado.

Como acontece em todo Dojo, os participantes programaram em par, em períodos de tempo bem curtos (4 ou 5 minutos).

O pessoal sempre começa fazendo um teste automatizado e, em seguida, a implementação mais simples que possa passar no teste recém projetado. Tudo no melhor estilo baby steps. E a linguagem escolhida para ontem foi Javascript, com o uso do framework de BDD JSSpec.

A solução começou simples, mas rapidamente avançou para um código que estava desagradando a todos. Em um certo momento, havia umas vinte linhas de código com inúmeros if-then-else pelo caminho. Os testes passavam, mas o código estava horrível de entender. Eu já não conseguia mais olhar para ele. Doía demais.

Foi quando parei de olhar o código e comecei a olhar o enunciado do problema novamente. Tinha que haver uma forma decente de fazer aquilo e comecei a criar alternativas na mente. Lá pelas tantas, tive uma ideia que permitiria limpar toda aquela bagunça e reduzir aquele monte de condições a uma única condição de exceção, aliada a uma outra estratégia de solução.

Quando chegou o momento da platéia se manifestar com sugestões, dei a minha ideia. A galera viu que fazia sentido, mas antes que pudessem começar a implementar, outra pessoa deu sua ideia. E a boa notícia é que era muito melhor que a minha. Seguindo a estratégia sugerida, não teríamos mais nenhum *if* e o código ficaria incrivelmente claro e fácil de compreender.

A nova estratégia foi explicada no quadro, não porque fosse complicada, mas porque envolvia o uso de um mecanismo que não era tão familiar a todos os calouros. Nada específico de programação. Apenas um recurso simples da matemática, que não vou mencionar aqui para não estragar o prazer de quem vier a participar de um Dojo com este tema. Feito isso, aqueles que estavam pilotando o computador começaram a alterar a implementação.

Minutos depois, a nova implementação estava pronta e rodaram os testes. Todos passaram gloriosamente! E nesse momento fez-se a luz. E o código antigo foi deletado. E o povo aplaudiu! De verdade! :-)

Rafael, o autor da solução, é aluno de Computação da UFF. Está no terceiro período e bolou uma estratégia que deixou todos nós, inclusive os mais experientes, estupefatos. No meu caso, por exemplo, devo ter mais tempo "mexendo" com computadores que o Rafael tem de vida. Mas, ainda assim, ele criou uma estratégia que nem eu, nem nenhum dos demais, foi capaz de bolar. E esse é o tipo de coisa que acontece direto nos Dojos.

E então a ficha caiu para mim. Comecei a olhar para os calouros com inveja. Por que não tive acesso a esta técnica (Dojo) quando eu era calouro? Aliás, nem em toda a graduação, nem durante o mestrado! Aí percebi quanto tempo foi investido em formas menos eficazes de aprendizado.

O Dojo é um ambiente de aprendizado impressionante. As pessoas aprendem em grupo, o que é sempre muito legal. O exercício é colaborativo, então, ninguém sai perdendo. Todos saem ganhando. Os participantes programam em par e aprendem a apreciar o valor dessa técnica. Além disso, têm que fazer testes automatizados antes de implementar cada funcionalidade, portanto, aprendem a trabalhar com TDD ou BDD. De quebra, aprendem a usar o framework de teste da linguagem que está em uso. Ah sim, eles eventualmente aprendem um pouco sobre a linguagem escolhida para a sessão do Dojo. Tudo isso é muito bacana, mas é só o começo.

Uma das coisas mais legais que acontecem em um Dojo é que os participantes são expostos a diferentes abordagens para resolver o mesmo problema. Portanto, eles têm acesso a inúmeras estratégias novas para modelar o problema. Se comparássemos o aprendizado da arte de programar com o aprendizado de um novo idioma, diria que estamos ampliando nosso vocabulário, toda vez que somos expostos a novas formas de modelar o mesmo problema, por mais simples que seja o problema.

O resultado inevitável disso é a refatoração. Os participantes aprendem uma nova estratégia ao longo da sessão do Dojo, refatoram o código e, com os testes, verificam se tudo continua funcionando. Portanto, refatoração é mais um tema aprendido. E ainda não acabou.

Sempre há uma retrospectiva no final de cada Dojo, na qual as pessoas avaliam o que funcionou bem e o que poderia ser melhorado. Retrospectiva é uma técnica aclamada em todos os métodos ágeis de desenvolvimento de software. Está presente no XP, no Scrum e em qualquer abordagem bem sucedida de desenvolvimento.

Para que não haja dúvidas, vamos fazer uma rápida revisão de tudo o que é aprendido no Dojo:

Programação em par
TDD e/ou BDD
Refatoração
Novas formas de modelar um problema
Aspectos de uma linguagem de programação
Como usar o framework de teste da linguagem adotada
Baby steps
Retrospectiva

E tudo isso em apenas 2 horas de Dojo, exatamente o mesmo tempo que dura uma aula convencional nas universidades. Compare o aproveitamento dessas duas horas com o aproveitamento de duas horas de uma aula tradicional de programação! A diferença é escandalosa.

Em muitos cursos de computação os calouros têm alguma matéria do tipo "Comp. I" com duas aulas por semana, cada uma com duas horas de duração. Imagine se não houvesse aula, mas apenas Dojo. Então, teríamos duas sessões de Dojo por semana, durante um semestre inteiro. Se isso fosse adotado, tenho absoluta certeza de que os calouros chegariam no final do semestre sabendo programar mais e melhor que 90% daqueles que se formam em computação. E não só isso, eles saberiam programar mais e melhor que a maioria dos professores universitários que "ensinam" programação!

Afinal, quantos professores dominam TDD e BDD, boas práticas de orientação a objetos, técnicas de refatoração, tudo isso em diferentes linguagens e ainda têm o hábito de programar em par e fazer retrospectivas? Garanto que poucos. E é aí que a minha ideia começa a ir por água abaixo.

Porque para que ela fosse adotada, seria preciso, primeiro, vencer uma barreira cultural que me parece intransponível. A ineficiência do "cuspe e giz" aliada à insanidade das "provas" que não avaliam absolutamente nada, compõem uma muleta atrativa demais para deixar de ser usada. Mas, ainda que fosse possível vencer essa barreira, teríamos que lidar com um mar de professores que simplesmente não sabem programar bem.

Quando penso em tudo isso, não consigo deixar de lembrar da Fábula dos Porcos Assados. E vejo o quanto as universidades "queimam florestas" para "ensinar" muito pouco, ao longo de muito tempo, quando há atualmente uma abundância de técnicas de ensino mais úteis, quase sempre envolvendo algum tipo de jogo.

Aliás, cada vez mais me dou conta da importância de trazer jogos para o processo de aprendizado. Eles são muito poderosos, tanto no sentido de transmitir a mensagem, como fazer com que ela fique gravada para sempre. Quando fazia consultoria de XP, costumava usar instrumentos como o Jogo da Comunicação, o XP Game, o Extreme Hour, entre outros. Todos eram muito eficazes, embora consumissem pouco tempo e fossem muito divertidos.

Seria fantástico se pudéssemos remodelar o sistema de ensino em torno de jogos como esses. Estou certo de que todos aprenderíamos muito mais, em menos tempo e nos divertiríamos demais no processo.

Participe de um dos muitos Dojos do estado do Rio. Acesse o site do Dojo Rio, entre na lista de discussão e apareça no Dojo mais próximo de você! De quebra você ainda vai ter a chance de curtir o pós-Dojo, que torna tudo ainda mais divertido.

Escrito por: Vinícius Manhães Teles (Twitter).

Obs: a maioria das fotos deste artigo são de autoria do Pedro Menezes que as disponibiliza como Creative Commons. O vídeo foi feito pelo Henrique Bastos.

Podcast "Tudo que quero saber"

Marcos Tapajós — Mon, 27 Aug 2007 18:03:00 -0300

Eduardo Fiorezi publicou mais um podcast da série "Tudo que quero saber!". Dessa vez foi sobre disciplina em projetos com eXtreme Programming e eu fui entrevistado junto com o Danilo Sato.

Fiquei muito feliz com o convite do Eduardo e em conhecer o Danilo, com quem já troquei algumas figurinhas sobre o Dojo-SP. Obrigado Eduardo !

Mais informações sobre o podcast aqui.

Desenvolvimento Ágil - Blog da Improve It: Tag dojo

Apelo: parem de "ensinar" Comp. I nas faculdades!

Podcast "Tudo que quero saber"