Como o TDD me ajudou a ser um programador melhor.

Eu acredito que depois do Scrum o TDD foi a metodologia que mais ajudou meu crescimento profissional. De certa forma uma coisa acabou me levando diretamente à outra.

Logo que comecei a dar os primeiros passos no Scrum em 2007 comecei a sentir dificuldades em alguns aspectos do desenvolvimento como:

• Dificuldade em determinar quando a tarefa estava pronta;
• Tarefas prontas que quebravam em produção e voltavam para o backlog;
• Coluna “teste” do backlog que acabava gerando gargalo no sprint.

Esse é o papel do Scrum, evidenciar problemas no processo de desenvolvimento. Cabe a equipe de desenvolvimento ir atrás das soluções e colocar em prática um plano de melhorias para os próximos sprints. Foi numa dessas que cheguei ao TDD.

Mas independentemente da metodologia utilizada, se você pensa em melhorar a qualidade do seu código em todos os aspectos; legibilidade, manutenibilidade, organização, confiabilidade, estilo e etc…Antes de qualquer outro método ou antes de estudar design paterns, comece pelo TDD. Não dá pra pensar em boas práticas de programação sem ter como principal pilar o TDD.

O conceito raiz do TDD é muito simples, mas confesso que é de difícil domínio:

• Crie um teste.
• Rode o teste (espere a falha).
• Codifique o mínimo para o teste passar.
• Refatore (passe a limpo) o seu código.
• Recomece.

Principalmente para um programador que se formou e passou os primeiros 8 anos da carreira programando sem teste unitário somente testando após o sistema “pronto”, que foi o meu caso. Foi uma quebra de paradigma muito grande passar a pensar em “teste primeiro”.

A mudança de mentalidade é primordial pra quem quer usar TDD. “Open your mind” senão não vai rolar. Realmente vai exigir muita paciência e disciplina. Mas o esforço vale a pena e se paga a curto prazo.

Fiz um vídeo onde eu explico com mais detalhes esses conceitos e mostro na prática como usar TDD com a linguagem PHP.

Quando você entende os conceitos e começa a praticar, em pouco tempo vai começar a enxergar pontos de melhoria no código. Vai confiar mais no código e vai ter mais vontade de arriscar melhorias que antes dariam um frio na espinha só de pensar em fazer.

Aquela famosa frase “tá funcionando, não vamos mexer…” fica para trás. Agora você tem uma “corda” e essa corda não vai deixar seu sistema cair. Com esse apoio dá pra mudar o nome daquela variável ou método. Extrair um trecho de código para outro método e melhorar o entendimento daquela classe.

Agora você não terá mais desculpas para não reler o código algumas vezes e pensar em melhorias para que o próximo programador a ter que lhe dar com aquele código entenda rapidamente e seja capaz de expandi-lo. Afinal o próximo programador muito provavelmente será você daqui alguns anos, meses ou até dias.