Livre tradução do artigo Pair Programming Antipatterns - disponível em https://tuple.app/pair-programming-guide/antipatterns
É possível parear bem simplesmente evitando parear mal.
Evite esses erros comuns e você vai aumentar suas chances de sucesso! :)
Para copilotos:
Apontar erros rapidamente demais
Dê ao piloto a chance de notar seus próprios erros de sintaxe e typos (erros de digitação).
Apontar constantemente pequenos erros prejudica o fluxo. O seu e o do próprio piloto. Isso também pode deixar seu par inseguro.
Lembre-se: seu trabalho é considerar o macro, e não apontar palavras erradas assim que você as vir.
Dar instruções “baixo nível”
Se você tem uma sugestão para o piloto, comunique isso no nível mais alto de abstração que ele pode entender.
Se você se perceber ditando código (ou pior, tecla por tecla), pare e veja se você consegue comunicar sua ideia num nível mais elevado.
Se isso não funcionar, peça para pilotar um pouco para que você possa demonstrar sua ideia.
Não levar seu próprio teclado
Leve seu próprio teclado para cada sessão de pair programming e plugue antes de vocês começarem.
Isso facilita na hora de trocar de papéis e permite que você mostre, em vez de falar, quando as palavras falharem.
Ter seu próprio mouse é bom também, mas não é tão essencial. (É fácil pedir para alguém clicar em algo, é mais difícil pedir para ele digitar vários caracteres.)
Para pilotos:
Pilotar muito rápido
Se você é muito experiente com o seu editor, é fácil fazer tudo rapidamente demais, de modo que até os copilotos mais experientes se percam.
A não ser que você tenha certeza que seu par está te acompanhando, não digite seu código tão rápido quanto você está acostumado.
Explicar o que você tá fazendo ajuda nisso.
Permitir um copiloto desatento(?)
(original: Allowing a checked-out navigator)
É fácil perder a atenção do seu copiloto ao ir rápido demais, ou fazendo coisas que ele não entende muito bem.
Se você perceber que a atenção do seu copiloto está vacilando, pare e sincronize.
Uma pergunta ruim: “Você entende isso, né?”
Uma pergunta boa: “Qual parte disso é mais difícil de acompanhar?”
Parear deve envolver comunicação constante em mão dupla. Se você ou seu copiloto ficaram quietos, parem e sincronizem.
Acesso à tela desigual
Sente-se de modo que o monitor fique entre vocês dois. Garanta que vocês dois possam ver igualmente bem (considere aumentar o tamanho das fontes).
Se uma pessoa está mais pro lado, isso cria uma sensação subconsciente de hierarquia desigual.
Um par é uma unidade. Nenhum de vocês é mais importante.
Não fazer pausas
Parear é exaustivo. Até mais do que programar normalmente.
Um bom jeito de garantir que vocês façam pausas adequadas é empregar o método Pomodoro. Considere combinar o tamanho dos turnos de trabalho e pausas com o seu par antes de vocês começarem.
Ouvir sem escutar
É difícil ouvir e digitar ao mesmo tempo.
Se o seu copiloto está fazendo uma sugestão, considere tirar as mãos do teclado. Melhor ainda: vire-se e faça contato visual! :)
Para os dois:
Permitir distrações improdutivas
Antes de começar a parear, desative todas as notificações (no seu computador e no telefone).
Uma sessão de pair programming deve ser interrompida por exatamente zero notificações no Slack ou mensagens de texto.
Se uma notificação aparecer, peça desculpa e desative as futuras.
Não deixe o seu e-mail aberto em outro monitor.
(Você deveria fazer isso mesmo quando não está pareando. A forma mais rápida de melhorar a produtividade programando é reduzindo interrupções.)
Não trocar os papéis
Ser piloto e ser copiloto são exaustivos por razões diferentes.
Trocar os papéis permite que você descanse as partes cansadas do seu cérebro e ative as antes ociosas.
Trocar os pilotos é um ótimo jeito de energizar uma sessão de pareamento que está perdendo o fôlego. Considere configurar um alarme para indicar toda vez que for a hora de trocar.
Esquecer que é uma habilidade
Pair programming é uma habilidade que deve ser aprendida.
Você nunca vai ser bom nisso de primeira, mas a prática consistente vai resultar em melhorias.
Não desista depois da primeira experiência. Não presuma que desenvolvedores experientes são automaticamente ótimos em pair programming. Não espere ser bom sem prática.
Considere refletir junto com seu par sobre isso, ou pedir feedback depois de cada sessão. O que vocês poderiam ter feito melhor?
Top comments (0)