A programação em pares remove a necessidade de revisões de código em um projeto Extreme Programming (XP)?

Em um projeto de programação extremo, os programadores emparelham a programação na maioria das vezes.

Como esses pares também alternam, ou seja, você emparelha um programa com pessoas diferentes, e existe um senso de propriedade coletiva, o código fonte é frequentemente revisado e atualizado.

Sendo assim, é necessário revisar o código? Quero dizer, pare de programar e realmente faça revisões de código.

— Eduardo Copat
fonte

A programação em pares é apenas um inquilino do XP. Existem muitas outras metodologias ágeis que não seguem o XP. Não há nada no Manifesto para desenvolvimento ágil de software nem Princípios por trás do Manifesto ágil que mencione a programação em pares. Também não há nada sobre revisões de código. É importante não supor que todo ágil seja extremo.

Deixe-me reformular minha pergunta para incluir apenas o XP.

— Eduardo Copat 04/12/2014

Existe uma razão para você não tentar e não se esqueça de definir alguns critérios para parar? Se a equipe estiver confortável com o código do check-in, esse deve ser um motivo suficientemente bom.

— JeffO

Um dos principais recursos da Extreme Programming é o Wiki de Ward, também conhecido como Portland Pattern Repository, também conhecido como C2.com . É aqui que várias pessoas elaboram várias metodologias e as documentam enquanto as utilizam.

Dentro deste wiki, há uma página: Revisões extremas de códigos de programação com vários colaboradores, incluindo Ron Jeffries e Kent Beck.

Para isso, eles disseram:

Revisões de código são consideradas importantes por muitos gurus de grandes processos. Eles visam garantir a conformidade com os padrões e, mais importante, garantir que o código seja claro, eficiente, funcione e tenha QWAN. Eles também pretendiam ajudar a disseminar o conhecimento sobre o código para o restante da equipe.

O ExtremeProgramming exige que todo o desenvolvimento seja feito por dois engenheiros trabalhando juntos. O código é realmente revisado em tempo real, em grande parte. Isso garante que mais de uma pessoa tenha conhecimento íntimo do código o tempo todo.

O ExtremeProgramming exige que todos os objetos tenham UnitTests. Isso garante que o objeto funcione e continue a funcionar conforme modificado.

Algumas línguas são reflexivas. Nesses idiomas, os UnitTests podem verificar diretamente a conformidade com os padrões importantes. (por exemplo, os objetos devem implementar # = e #hash, ou nenhum.)

O ExtremeProgramming pratica o CollectiveCodeOwnership, o que significa que os objetos que precisam de atenção serão procurados por muitos desenvolvedores. Isso tende a pressionar aqueles que produzem código que não está em conformidade com os padrões. Os desenvolvedores visitantes são incentivados / esperados a colocar o código em conformidade quando encontrarem desvios. Isso também garante que o conhecimento do código seja disseminado além do par inicial de programadores que o criou.

Portanto, os projetos ExtremeProgramming não requerem revisões explícitas. Solte-os da sua metodologia.

Também há um pouco mais de discussão sobre o assunto por parte de outros.

Os principais pontos, porém, são que, com a combinação de testes, a propriedade colaborativa e a programação em pares, essas coisas resolvem os objetivos que uma revisão de código normalmente deve fazer, como:

Dispersar o conhecimento do que está sendo feito
Um segundo (ou mais) conjunto de globos oculares no código para garantir que está seguindo os padrões
Verifique o funcionamento correto do código

Isso está sendo feito continuamente por meio de programação em pares e testes automatizados em Extreme Programming e, portanto, uma inspeção explícita da Fagan é desnecessária.

Leitura relacionada:

Programação em pares x revisões de código na Horror de codificação.
Revisões de código consideradas prejudiciais em ExtremeProgramming.org

Argumentei em outra sessão de perguntas e respostas que a revisão de código é um desperdício desnecessário (no sentido Lean da palavra) e que a programação em pares deve ser o método preferido de fornecer todos os benefícios que uma revisão de código traria. Escusado será dizer que as pessoas se ofenderam com o meu argumento, porque eu não o apoiei com A VOZ DA AUTORIDADE (TM) como você. Para um grupo de pessoas que lidam com a lógica dia após dia, somos um grupo ilógico.

— Michael Brown

O risco de fazer a programação em pares sem revisões adicionais de código é que ambos os programadores estão muito envolvidos no momento da escrita e podem escrever código que parece completamente claro e lógico no momento, mas menos quando visto novamente depois de alguns dias. O quão grande e / ou aceitável é esse risco depende da sua organização.

— Bart van Ingen Schenau

@MikeBrown você poderia igualmente argumentar que Pair Programming é um desperdício desnecessário e que a revisão do código deve etc etc.

— AlexFoxGill

Veja o que eu quis dizer com WASTE foi a definição "enxuta" da palavra. Pense no processo típico da linha de montagem. A idéia é colocar o carro na linha o mais rápido possível e verificações de qualidade após o fato (revisão de código). Os princípios de lean defendem um pouco mais de tempo e esforço para criar qualidade (programação em pares), para que a verificação posterior se torne desnecessária.

— Michael Brown