longo prazo comparado com a programação em par.
Em suma, os principais benéficos da programação são melhor qualidade, equipe
mais motivada, mais confiança e trabalho em equipe, disseminação de conheci-
mento, e aprendizado contínuo [33].
Mito: Sem Programação em Par, não há Agilidade
Martin Fowler, uma das personalidades mais respeitadas no mundo
do desenvolvimento
de software, escreveu um artigo em 2006 levantando
alguns dos principais enganos sobre programação em par.
Fowler esclarece em seu artigo que não é necessário programar em
par para estar praticando um processo ágil [29], nem mesmo se pode di-
zer que para aplicar Extreme Programming você é obrigado a programar
em par. O máximo que se pode dizer é que alguém que quer aprender
XP deve tentar programar em par e ver se funciona em seu caso em par-
ticular .
A programação em par não é nem mesmo citada no manifesto ágil,
porém, é uma prática altamente recomendada para que se alcance os
princípios ágeis.
4.10
Revisão de Código
A revisão de código consiste em um ou mais desenvolvedores lerem o código fonte
com o objetivo de assegurar a qualidade do código e aprender no processo. Especi-
almente na implementação de histórias que não foram desenvolvidas com progra-
mação em par, recomenda-se, a prática de revisão de código.
A revisão de código melhora sua qualidade e reduz a taxa de defeitos [31]. As
revisões são oportunidades não apenas de se prevenir erros no código, mas também
86
Casa do Código
Capítulo 4. Entregando Valor
de compartilhar e disseminar o conhecimento entre os integrantes do time. Ao revi-
sar o código alguém pode descobrir boas práticas que não conhecia, ou, em caso de
encontrar alguma má pratica, então passa a ser uma boa oportunidade de discutir
sobre formas melhores de solucionar o problema em questão.
Para que as revisões de código sejam de fato construtivas para o time, é impor-
tante manter uma atitude de trabalho em equipe quando um problema for encon-
trado e evitar encontrar culpados ou debochar daquele que cometeu o erro.
Em um ambiente ágil, parte-se do princípio de que todos estão fazendo o seu
melhor, então, se eventualmente um problema for encontrado, procure se certificar
de que todos saibam como evitar que o problema volte a ocorrer, e siga em frente.
As revisões de código tanto podem fazer parte da definição de pronto e, conse-
quentemente, do processo, como podem ser esporádicas, sendo realizadas de tem-
pos em tempos. Em algumas equipes um desenvolvedor revisa o código de outro,
em outras equipes, a revisão é coletiva envolvendo várias pessoas.
Algumas organizações fazem uma mescla entre programação em par e revisão de
código, de forma que tudo o que não for desenvolvido em pares, é revisado. Não há
fórmula secreta para isso, é interessante testar diversos métodos e encontrar aquele que funciona melhor no contexto de sua equipe.
4.11
Dívida Técnica
Imagine que você é um desenvolvedor de software que está trabalhando em um sis-
tema de transferências bancárias. Você está fazendo uma alteração que, teorica-
mente, seria muito simples, mas percebe que o design atual do sistema precisaria
sofrer algumas alterações para que fosse possível criar testes de unidade para a alteração que está fazendo.
Você, agora, precisa tomar uma decisão: fazer um trabalho rápido e sujo para
resolver o problema rapidamente, mas deixando o código sem testes, ou refatorar e
alterar o design para que seja possível escrever testes de unidade.
Desenvolvedores precisam tomar decisões como essas diariamente e, a cada tra-
balho rápido e sujo que fazem, aumentam a dívida técnica do projeto.
Dívida técnica é uma metáfora criada por Ward Cunningham que ilustra as con-
sequências desses trade-offs. A ideia básica por trás do termo é que diminuir a qualidade aumenta o tempo de desenvolvimento a longo prazo.
Para Cunningham, divida técnica inclui coisas que você escolhe não fazer agora,
mas que impedirá o desenvolvimento futuro se deixado de lado [21]. Isso inclui,
87
4.11. Dívida Técnica
Casa do Código
protelação de refatoração, mas não inclui protelação de funcionalidade, a não ser em casos que a entrega foi boa o suficiente porém não satisfaz algum tipo de padrão
de desenvolvimento.
Dívida Técnica ou Débito Técnico
No conteúdo sobre método ágeis da comunidade brasileira, espe-
cialmente em blogs, encontra-se muito o termo débito técnico, mas
entende-se que dívida é uma tradução mais correta para debt . Em in-
glês a palavra debt quer dizer dívida (um
valor que não foi pago e deverá
ser pago futuramente), já a palavra debit significa débito (um valor que
foi retirado de uma conta bancária, por exemplo).
Depois da definição de Cunningham no início dos anos 90, a comunidade con-
tinuou a evoluir o conceito [53] e, atualmente, diversos atalhos tais como design ultrapassado, defeitos conhecidos que não foram resolvidos, baixa cobertura de testes de unidade, excesso de testes manuais, entre outros, também são considerados