InfoQ

InfoQ

Notícias

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

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

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

Seções
Processos e Práticas
Tópicos
Agile ,
Técnicas Ágeis
Tags
Pair Programming

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.

 

Ambos são úteis... por Wescley Costa Enviado
  1. Voltar ao topo

    Ambos são úteis...

    por Wescley Costa

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

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.