21/03/2006
Raony wrote:
Bom dia!
Existiu um motivo para não termos o Acordando e testando de ontem, e o motivo é que esse é o último drops do programa e vamos juntar ontem e hoje num especial de duas horas de duração.
No último drops eu prometi que ia falar sobre como os padrões do TDD funcionam juntos. Bem, então vamos lá:
Por que Vermelho vem antes?
– Por que antes de escrever código eu tenho que pensar com calma no que eu fazer;
– Por que se eu penso em objetivos em termos de resultados esperados nada mais natural que traduzir isso em código de teste;
– Por que eu estou mais concentrado e disposto antes de uma sessão de programação do que depois dela;
– Por que eu ainda não comecei a resolver o problema, portanto posso olhar para o objetivo (o teste) em termos mais imparciais, sem estar bitolado no código;
– Por que o teste vai me acompanhar a cada momento para me dizer se o que estou fazendo é certo ao invés de só me prover feedback no final;
Por que Verde vem antes de Refatore (ou mais profundamente, por que fazer o teste passar a todo custo e depois resolver o problema decentemente)?
– Por que a implementação pode não ser óbvia e preciso começar de uma forma simples;
– Quanto mais rápido eu passar o que tem na minha cabeça para código, mais rápido é o feedback eu tenho sobre o que estou pensando;
– Por que me possibilita andar em um ritmo que eu possa prosseguir com segurança. Depois que eu deixo o teste verde com alguma das técnicas simples apresentadas pelo padrão Verde eu passo para a Refatoração com a certeza de que qualquer passo errado que eu der, o teste vai quebrar;
Por que eu Refatoro no final?
– Por que você vai ter testes para assegurar que você não quebrou nada a cada passo;
– Por que outras pessoas vão usar o seu código e ele precisa estar o mais simples e legível possível;
– Por que você mesmo vai usar o seu código após algum tempo e ele precisa estar simples e legível;
– Por que seu código precisa ser fácil de manter, corrigir, alterar e estender;
TDD não é a técnica suprema de programação, não é para todos os problemas, não é para todas as pessoas. Mas na minha opinião TDD serve para uma grande variedade de problemas e pessoas, e nesse contexto, é extremamente eficiente.
TDD é uma forma disciplinada de programar que não exclui disciplina na modelagem, nem na aquisição de requisitos, gerência ou o que seja. Talvez arriscado seja achar que uma forma disciplinada de modelar, levantar requisitos e gerência exclua a necessidade de disciplina na programação.
Finalmente, TDD funciona muito bem em uma estrutura BDUF (Big Design Up Front), ou qualquer outra. Porém, ao usar TDD, é possível que a taxa de defeitos no código seja reduzido o suficiente para que a equipe perceba que:
+ Qualidade passa a ser um processo proativo do programador ao invés de um processo reativo de verificação;
+ Com o número de surpresas desagradáveis menor, suas estimativas vão ficando mais precisas;
+ O design pode crescer organicamente com testes para prover feedback nos momentos de decisão;
Das três possibilidades acima, eu gostaria de dar minha opinião pessoal sobre a terceira.
No final das contas o resultado é código. O que a máquina entende é código. Se depois você quiser saber como algo funciona, você vai rodar o código. Em última instância a única documentação garantida de como o código funciona é o próprio código. Não interessa ter uma excelente modelagem, elicitação de requisitos ou gerência se o resultado não é código limpo que funciona.
Em minha opinião pessoal, enquanto eu não estiver trabalhando com um compilador de modelos, modelos não passarão de ser modelos. Os físicos não entendem o mundo como uma implementação de seus modelos teóricos e sim fazem modelos do mundo para entendê-lo melhor. Da mesma forma eu não entendo meu código como uma implementação de modelos, mas entendo modelos como uma forma de entender o meu código.
Eu concordo com a utilização de qualquer ferramenta que me permita entender melhor meu problema e como solucioná-lo, e isso inclui modelos. O problema está quando acreditamos que o modelo *é* a solução do nosso problema. Pra mim, os modelos nada mais são que uma boa forma de comunicar e abstrair, mas no final o que vai resolver o meu problema vai ser código limpo que funciona.
Design orgânico é tomar decisões de projeto só quando são necessárias. O que isso quer dizer? Eu não projeto para o futuro. Absurdo? Talvez. Discutir a validade dessa idéia não é algo para um e-mail, mas resumindo: projetar arquiteturas para o futuro é baseado no medo de que seja necessário mudar algo no futuro, e todo mundo foi evangelizado desde pequeno que quanto mais tarde algo mudar no desenvolvimento de software, mais caro vai ser essa mudança.
O problema é que esse medo é baseado numa conjuntura de 40 anos atrás, onde não existiam IDEs que facilitavam a vida do desenvolvedor. Design Patterns e Refatoração eram palavras reservadas a gurus e experts da programação. E principalmente, é fruto de uma conjuntura em que testes eram feitos no final do processo.
Ter um código 100% coberto de testes ou pelo menos 100% do que eu acho relevante coberto de testes automatizados quer dizer que, quando eu precisar mudar algo eu vou lá e mudo. Se eu quebrar alguma coisa enquanto eu estiver mudando, o teste vai dizer.
Se o teste não disser que eu quebrei algo e mesmo assim quebrei, é porque não tem um teste para esse algo, então é porque ou eu não achei relevante ou nem tinha conhecimento desse algo para início de conversa, e se eu não achava relevante ou nem conhecia é muito pouco provável que eu tomasse decisões de projeto corretas se eu estivesse fazendo o projeto da arquitetura todo de início para facilitar mudanças futuras.
Design orgânico não é nem de longe a maior vantagem possivelmente advinda em usar TDD (se é que você considera uma vantagem), a maior vantagem é, de longe, de longe, estimativas mais precisas. Mas esse é um assunto que não vou tratar aqui. Existe todo um mundo por trás disso e que eu convido a todos a começarem a conhecê-lo a partir do TDD.
Os drops Acordando e testando foram escritos baseados no livro Test-Driven Development by Example de Kent Beck, que sugiro como leitura. Lá ele indica mais livros de clássicos da área de Teste para leitura também.
Os objetivos desse drops foram:
– Servir de quick start da cultura de testes unitários;
– Servir de referência rápida para o básico de código de testes em j2me;
– Apresentar a idéia por trás de TDD;
Espero que tenha sido válido para todos.
Tenhamos todos um bom dia,
Abraços,
raony
Vc é muito prolixo, não me surpreende que ninguém te leia…