BT

Programação em Par vs Revisão de Código

por Chris Sims , traduzido por Wagner R. Santos em 19 Jan 2009 |

Programação em Par e Revisão de Código são práticas que aumentam a qualidade do software, assim como promovem a disseminação do conhecimento. Enquanto os debates Agile vs Lean, XP vs Scrum e vi vs Emacs andam em marcha lenta, desenvolvedores são conhecidos por debater os méritos da programação em par vs revisão de código. Theodore Nguyen-Cao descreveu revisores de código como galinhas, e programadores em par como porcos.

 

A história da galinha e do porco é geralmente discutida no circulo dos agilistas. Quando é para fazer um café da manhã com bacon e ovos, a galinha é envolvida mas o porco é comprometido.

Desta maneira, o termo ‘porco’ tem sido utilizado para descrever aqueles que são totalmente comprometidos para um dado empreendimento. O termo ‘galinha’ é utilizado para descrever aqueles que são envolvidos, mas cuja responsabilidade é menor.

 

Em revisões de código, as pessoas sentam para revisar o código de outra pessoa.  Todo mundo possui uma opinião mas nem todos irão trabalhar com o código em uma base diária. Em dado momento, todos parecem estar envolvidos no processo, mas não há um interesse real. Eles estão apenas olhando para um monte de código e perguntando a si mesmos “será que este código está bom e correto?” É uma visão muito passiva. Por outro lado, programadores em par estão completamente interados (comprometidos?) na tarefa da vez.  Eles imediatamente estão utilizando o código que eles estão escrevendo em conjunto e compartilham suas idéias em relação ao design, layout do código, etc. Ambos programadores estão tomando um papel ativo e estão emocionalmente envolvidos na tarefa da vez pois estão atacando o mesmo problema juntos.

 

Theodore também apontou que o ciclo de feedback é muito melhor durante a programação em par do que durante a revisão de código. Durante a programação em par, os desenvolvedores escrevem, inspecionam, e alteram o código continuamente. Em uma revisão de código, em contraste, envolve inspecionar o código posteriormente, geralmente quando o autor pensa que ele esta pronto para deployment.

 

É geralmente aceitável que o custo de um bug de software suba drasticamente, talvez exponencialmente, conforme o tempo entre a introdução e a correção suba. Por esta métrica, bugs pegos durante uma sessão de programação em par custa muito menos do que aquelas pegas durante uma revisão de código. É claro, que para qualquer um dos dois o custo é muito menor que permitir que o bug seja liberado antes que seja pego. Talvez isto pague fazer os dois.

 

Você prefere programação em par, revisão de código, ambos, ou nenhum? Deixe um comentário e compartilhe suas idéias.

 

Avalie esse artigo

Relevância
Estilo/Redação

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

Ambos são úteis... by Wescley Costa

Penso que utilizar as duas técnicas seja algo considerável, e garantirá assim, maior qualidade ao software desenvolvido.

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

1 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.