O
ato de debugar na minha opinião é uma faca de dois gumes. Depende muito
de o que está debugando e O QUE ESTÁ PROCURANDO. Acredito que o TDD
ajuda MUITO em saber o que está procurando. A falta de produtividade não
está no ato de debugar em si, está as vezes na falta de conhecimento,
preguiça ou até mesmo inércia em buscar entender o que procurar.
Muitas vezes vejo desenvolvedores SEMPRE rodar seu projeto em modo
DEBUG e se rodar, fizer testes e não der erro então está pronto. ERRADO.
Isso é um tiro no pé da produtividade.
A palavra DEBUG são
compostas de duas partes DE (tirar) e BUG(inseto) logo primeiro conheça o
seu bug, entenda o porque ele existiu e só depois tire (DE).
Toda metodologia que ajuda a cumprir requisitos ajuda a remover bugs antes deles existirem.
Existe um gráfico que diz o seguinte: O custo de remoção de um bug é uma exponencial de acordo com os passos do projeto.
Requisitos: 5$
Codificação: 10$
Testes: 100$
Produção: 1000$
O
mais interessante não são os valores, vamos esquecê-los por um tempo. O
mais interessante é uma fase chamada requisitos possuir bugs. Logo como
se faz uma analise de requisitos com DEBUG ligado? rsrsrs
Remover BUGS é primeiro saber onde quer chegar e depois remover
aquilo que o impede. Na fase de requisitos as vezes descobrimos itens
que podem criar um caos ao desenvolvimento desnecessáriamente.
DEBUG
é igual a remedio tarja PRETA, se tomar sem saber a doença (BUG) pode
até ficar curado mas corre um sério risco de ficar viciado. Se houver um
diagnóstico preciso da sua doença você saberá exatamente a quantidade e
por quanto tempo usará.
E o TDD? Seria igual a "pratique esportes" muitas pessoas não
gostam, as vezes dá preguiça, não temos disciplina, ou então só fazermos
exercicios que gostamos (No dojo é legal, mas no dia a dia?), porém
todo mundo sabe que é saudável além de evitar algumas doenças (BUG).