BT

Como TDD e Pareamento Aumentam a Produtividade

por Mike Bria , traduzido por Samuel Carrijo em 04 Jun 2009 |

"Desenvolvimento orientado a testes" (TDD) e "Pareamento" são duas das práticas ágeis mais conhecidas, e mesmo assim não são postas em prática por muitas equipes ágeis. Com frequência, as pessoas afirmam estar "muito ocupadas" para praticarem TDD e pareamento; em essência, deixando a entender que esforçar-se para produzir um código de alta qualidade reduz a produtividade. Mike Hill explica como esta lógica está muito furada.

Mike afirma, essencialmente, que deve-se "fazer melhor" quem quiser "fazer mais rápido":

Não só não é verdade que pode-se trocar qualidade interna por mais funcionalidades, o que ocorre é o exato oposto: quanto mais produtividade se deseja, mais elevado deve ser o padrão de qualidade interna.
...
Se você quer produzir mais, procure primeiramente aumentar sua qualidade interna.

E então ele explica:

Então, por que isso funciona?
  1. Porque qualidade interna e qualidade externa não são a mesma coisa.
  2. Porque o que mais influencia a produção de hoje é a qualidade da produção de ontem.
  3. Porque digitar não é, nem nunca foi o gargalo na hora de escrever código.

Mike continua aprofundando esses três motivos.   Primeiro, ele esclarece o termo "qualidade" para distinguir qualidade externa, que pode ser entendida como o número de funcionalidade em seu produto, de qualidade interna, que se refere ao código por três dessas funcionalidades. Ele faz essa dintinção pra destacar que qualidade externa pode ser diminuída para que o produto esteja no mercado mais rapidamente, enquanto qualidade interna não pode.

Por fim, Mike descreve como "o ontem determina o hoje", ou como a qualidade interna do código já existente afeta a produtividade atual:

O dia todo, em qualquer coisa que você faça, você estará dependendo de código que já está lá. Cada linha de código que você tiver que estudar vai te deixar mais lento. Cada dependência aberta a mais vai te deixar mais lento. Cada nome de variável mal escolhido vai te deixar mais lento. Qualquer decisão de design deficiente, seja ela grande ou pequena, vai te deixar mais lento.

Se você quer trabalhar o mais rápido possível, você quer trabalhar com código limpo. Ponto final.

Por fim, fala a respeito do equívoco comum de acreditar que pareamento e TDD reduzem a produtividade, porque se vai ter [palavras deste autor] "metade do número de pessoas escrevendo metade do código de produção". Ele então dá uma lista de 11 atividades comuns que são realizadas quando alguém "codifica", e então afirma:

Note que escrever código na máquina ocupa apenas uma pequena parcela dessa lista. Isto ocorre porque a parte difícil da programação é pensar, e não digitar. Todas as demais coisas naquela lista (exceto talvez jogar coisas nos outros) está relacionada com atividade intelectual, e não com digitação.

TDD aumenta a produtividade, pois auxilia na hora de pensar. TDD limita back-tracking, e inclusão excessiva de funcionalidades, além de diminuir a necessidade de debugar o código e de ter que estudá-lo para entendê-lo. Pareamento aumenta a produtividade pelo mesmo motivo. Dois desenvolvedores juntos não digitam tão rapidamente quanto dois desenvolvedores separadamente, mas nós não nos importamos: o gargalo é pensar [e não digitar], e tanto pareamento quanto TDD ajudam nesse sentido.

Mike conclui com três sugestões resumidas de como melhorar a produtividade da sua equipe:

Se você quer aumentar a produtividade da sua equipe, faça essas três coisas:
  1. escreva um pequeno teste que falha antes de alterar qualquer coisa no código
  2. faça um acordo “sem par, nada feito”
  3. aja para que todos tenham um entendimento comum sobre qualidade interna

É provável que você conheça alguém (talvez até você mesmo) que acredita que não "tem tempo para parear ou fazer TDD". O artigo do Mike pode te ajudar.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT