boliche, salto em altura, basquete… e TDD
Publicado: 17/04/2009 Filed under: principal 1 ComentárioHá alguns anos, uns amigos me convidaram para jogar boliche. Todos amadores, nunca havíamos jogado. Qual o objetivo do jogo? Derrubar o maior número de pinos. Eu já havia assistido a algumas partidas na tevê. Vi que os jogadores profissionais sempre utilizam a mesma técnica: arremessam a bola com efeito. Resolvi então fazer o mesmo. Resultado: desastre total. Perdi as primeiras partidas. Resolvi mudar a estratégia. Passei a jogar sem efeito, e passei a ganhar algumas partidas.
Certa vez, na escola técnica (atual CEFET) ou na universidade, não lembro direito, cheguei a praticar atletismo. Chegamos ao salto em altura. Alguns (os “seminovatos”) já haviam praticado uma ou duas vezes. Os demais eram absolutamente “novatos”, virgens no esporte, marinheiros de primeira viagem. Qual o objetivo da disputa? Passar o sarrafo o mais alto possível sem derrubá-lo. Todos os novatos queríamos passar o sarrafo com as costas viradas para o chão, como fazem os profissionais, da forma que sempre vimos na tevê. Já os seminovatos utilizavam uma técnica “especial”: passavam o sarrafo de frente, com o ventre voltado para o chão. Resultado: os seminovatos venceram-nos de lavada. Fiquei impressionado. Como eles ganharam de todos nós se utilizavam uma técnica menos eficaz? A melhor técnica para mim era a de costas, claro, já que era a que todos os profissionais usavam.
Noutra vez, brincando de jogar basquete na quadra do colégio, combinamos (todos do mesmo nível, seminovatos) uma disputa: quem acertaria mais lances livres. Qual o objetivo da disputa, então? Acertar no cesto o maior número possível de bolas. Alguns fizemos os primeiros arremessos como fazem os profissionais, impulsionando a bola apenas com uma mão, utilizando a outra como apoio. Outros, “não sei por quê”, utilizavam as duas mãos para impulsionar a bola. Foram motivo de chacota, no começo da disputa. Como podiam arremessar de forma tão desengonçada? Nunca haviam visto uma partida de basquete? Só que, à medida que a disputa se desenrolava, a chacota se transformou em perplexidade, pois os desengonçados nos venciam.
O que aprendi com essas historinhas? Que algumas técnicas são mais eficientes, mas só depois de muito treino. Para um novato, as técnicas “naturais” são melhores. Mas há técnicas que, depois de treino, são mais eficientes que as naturais.
Minha sensação é que o mesmo acontece com TDD.
Qual o objetivo de um programador? Entregar código com um bom desaine e coberto por testes unitários. A forma natural é escrever todo o código e depois ir refatorando e cobrindo por testes unitários. Se se pedir a um programador acostumado a fazer dessa forma para escrever código utilizando TDD, ele vai ser bem menos produtivo. Isso pode até ser verdade, mas só no princípio. Um programador fluente em TDD é mais rápido que um programador tradicional.
Infelizmente a analogia com as minhas peripécias esportivas não é perfeita – como qualquer analogia. No esporte, é fácil provar que técnica é mais eficiente: no boliche, quantidade de pinos derrubados; no salto, altura atingida; no basquete, quantidade de lances convertidos. Em software dificilmente – de fato, acho que nunca – conseguiremos provar que TDD é mais eficiente, já que não temos como medir produtividade. Ficaremos pela percepção de cada um.
Pois bem… Certo dessa minha intuição, de que TDD é melhor, pedi para que meus programadores passassem a escrever código utilizando TDD. O resultado inicial foi tão desastroso que abandonaram a ideia à minha revelia.
Quando soube desse abondono, me falaram: “Tales, é um desastre. Ficamos bem mais lentos.” Perguntei: “Mas vocês acreditam que TDD é melhor?” Alguns acreditavam, outros não; mas todos não-convictos. Propus: “Vamos experimentar por algum tempo. Se não gostarmos, desistimos.” Retrucaram: “Mas, Tales, vamos ficar muito improdutivos.” Sugeri: “Façamos assim: comecem programando normalmente, como sempre fizeram, mas se obriguem a fazer TDD uma hora por dia. Depois de duas semanas, aumentem para duas horas. Depois de mais duas, para três horas. E assim sucessivamente, até vocês se certificarem se TDD é melhor ou não.” Ou seja, a ideia era não ter uma queda brusca de velocidade no princípio.
Essa sugestão que dei para a equipe é recente e ainda não sabemos se a proposta deu certo. De qualquer forma, fica a ideia para os leitores, que era o que queria com esse post, lançar a ideia.
P.S.: cheguei a contar essas historinhas esportivas para uma nossas equipes. Um dos membros dessa equipe – Sávio, meu irmão – fez outra analogia. Ele contou que no princípio digitava apenas com os dois indicadores. Era até rápido. Mas ele intuía – uma obviedade, de fato – que digitaria mais rápido ainda se utilizasse todos os dedos. Só que sabia também que não seria tão produtivo no início. O que ele fez? Começou se forçando a digitar com todos os dedos meia hora por dia. A cada semana, aumentava meia hora, até chegar ao ponto de perceber que digitava mais rápido com todos os dedos que com os indicadores.

Concordo que praticar TDD para quem já começou no modelo tradicional de escrever algoritmo a produtividade cai drasticamente no inicio.
Só não sei se escrever código antes do teste é algo natural mesmo ou condicionamento por termos aprendido que era assim.
De qualquer forma é excelente a idéia de se policiar e saber que testar é algo que um profissional tem o dever ético e moral de fazer mesmo que seja tomando um pouco de tempo no inicio enquanto se aprimora.
Acredito que já exista material suficiente hoje para elevar o tempo de aprimoramento em TDD e devemos evangelizar nesse sentido.