Andando de costas

Aqui vai um pequeno resumo de como adiciono recursos aos meus sistemas:

  1. Eu identifico (ou alguém me chama a atenção para) alguma necessidade
  2. Escrevo alguns testes para a necessidade
  3. Escrevo o código para fazer os testes passarem
  4. Depois que os testes estão devidamente esverdeados, reestruturo o código para que fique um pouco mais elegante
  5. Repito até que a necessidade esteja satisfeita

Este é o modo TDD de fazer as coisas e pode parecer estranho para quem não está acostumado. Mas o que não é estranho para quem não está acostumado?

Por conseqüência este modo esquisito também é o modo XP. Pelo menos para quem segue a cartilha. E, olhando por este lado, parece que XP inverte bastante as coisas. Você faz os testes antes de fazer o código e (re)define a estrutura depois de ter o código pronto. É como programação para caranguejos: você anda e consegue chegar aonde precisa, mas o modo como isso é feito não é muito parecido com o que se vê normalmente. A não ser, é claro, que você esteja vivendo entre caranguejos.

O que eu inicialmente aprendi na escola foi que deveria pensar um pouco em como estruturar a aplicação antes de começar a escrever código. Para registrar (ou documentar, para usar uma palavra um pouco mais corporativa) a estrutura, poderiam ser elaborados diagramas usando uma linguagem gráfica padrão. Depois era hora de implementar o design. Implementar, em corporativês, é escrever o código correspondente ao design (que é a palavra usada para indicar a estrutura pré-projetada). Finalmente, depois que o código estivesse escrito, chegava a hora de testar a coisa.

Em algum ponto do tempo, devo ter esquecido isso tudo. Pelo que eu descrevi, parece que estou fazendo tudo ao contrário, andando de costas. Afinal, eu começo pelos testes e só no final do ciclo me preocupo com a estrutura. Mas a verdade é que continuo fazendo tudo na mesma ordem. Os testes que faço no início servem para que eu pense um pouco e defina uma estrutura mínima para o código que estou prestes a escrever. Eles definem como o novo pedaço de código vai se ligar ao resto da aplicação, assim como fazem os diagramas. Só que têm uma vantagem bem importante: depois que eu quiser validar tudo, os testes já estão prontos. Do mesmo modo, a atividade final de reestruturação é uma preocupação principalmente com a estrutura da aplicação e, como isso tudo é um ciclo, estar no final é o mesmo que estar no início.

6 Responses to “Andando de costas”


  1. 1 Marcos Tapajos 10/jan/2007 às 18\0644

    Thiago, realmente parece estranho no início mas com o tempo tudo faz muito sentido. Também aprendi exatamente o oposto do que faço hoje e acho isso ótimo porque hoje tendo vivido as duas esperiências já sei que o melhor pra mim é fazer igual você faz.
    No nosso atual projeto eu e o Vinícius estamos dando muita atenção aos testes e mantendo eles em 100% de cobertura sempre.
    Hoje não sei como alguém programa sem testes !!!!!!! A gente aprende muito com testes simplemente porque as vezes é mais dificil faze-los do que a aplicação mas nem por isso desanimamos e esquecemos deles. Fazem parte do projeto.

    Um abraço

  2. 2 Juan Bernabó 11/jan/2007 às 18\0633

    É engraçado mais muito sobre complexidade, comportamentos humanos, sistemas complexos, teoria organizacional, ecosistemas esta convergindo.

    No livro os 7 Habitos das Pessoas Altamente Eficazes, Stephen Covey fala sobre um dos habitos que parece que pessoas altamente eficazes normalmente tem, que é de começar com o final em mente (Start with the end in mind).

    O legal de TDD, é que te deixa codificar “exatamente” como será esse final e depois automatizar o processo de verificação, ahi estes testes, que acabam funcionando como “metas” acabam optimizando os esforços para convergir em cada uma das metas atingidas.

    Eu pelo menos penso muito melhor quando tenho uma meta extremamente bem definida e binaria, o que me permite que meu cerebro, sem esforço consciente possa me dizer se uma atividade me aproxima ou não daquela meta, se tiver que cada vez “pensar” concientemente acabo me cansando muito mais e fazendo um trabalho pior.

    Por isso, acho que mesmo que não seja a forma “natural” a que estamos acostumados e pareça mais trabalhoso, os beneficios são inumeros, e o legal é que mesmo que seja dificil de subir no bonde, uma vez dentro a gente não quer descer.

    Otimo artigo!

    Abraços,
    Juan.

  3. 3 Vinícius Manhães Teles 14/jan/2007 às 13\0112

    Thiago,

    A Mary Poppendieck fala em seus livros sobre a importância de antecipar os testes ao máximo. Isso ajuda a elevar a qualidade e eliminar desperdícios de forma significativa. Porque a essência está em prevenir falhas, ao invés de detectar erros.

    Tem dois vídeos interessantes a esse respeito, ambos referentes a apresentações feitas no Google. O primeiro é com a Mary Poppendieck e o segundo com a Elisabeth Hendrickson, analista de testes de projetos ágeis.

    Passo os links abaixo onde estão mais informações sobre cada uma e o ponteiro para os vídeos.

    Mary Poppendieck
    http://blog.improveit.com.br/articles/2007/01/07/lean-software-developement

    Elisabeth Hendrickson
    http://blog.improveit.com.br/articles/2007/01/11/o-papel-de-quality-assurance-em-projetos-ageis

  4. 4 Andre Furtado 17/jan/2007 às 03\0350

    “como isso tudo é um ciclo, estar no final é o mesmo que estar no início.”

    Muito bom!

    []s
    — AFurtado


  1. 1 Qual a sequência de passos para fazer um software? « Coding Dojo Floripa Trackback em 29/jan/2007 às 23\1129
  2. 2 Tudo que quero saber! » Blog Archive » Como tornar-se inútil com TDD. Trackback em 20/abr/2007 às 02\0244
Comments are currently closed.




%d blogueiros gostam disto: