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.