A colaboração eficaz é uma das principais características de qualquer equipe produtiva. Todo mundo pensa de forma diferente, então ter um segundo par de olhos em um problema pode oferecer vários pontos de vista e abordagens que você poderia ignorar. Para programadores, a forma mais comum disso é a programação em pares.
Às vezes, a programação em pares tem uma má reputação. Os críticos argumentam que colocar dois desenvolvedores na mesma tarefa diminui a velocidade geral da equipe, mas economiza tempo no grande esquema das coisas. A programação em par não apenas produz código de maior qualidade, mas também ajuda os desenvolvedores a resolver problemas rapidamente e remover bloqueadores. Eu tenho programado muito em pares com meus colegas recentemente, então gostaria de compartilhar algumas dicas para tirar o máximo proveito disso.
Concentre-se nas partes desafiadoras primeiro
Cada sessão de programação em pares difere, mas o objetivo geralmente é consistente. Na maioria das vezes, você está tentando desenvolver uma solução para algum problema complicado que merece dois pares de olhos. Enquanto alguns desenvolvedores podem preferir tirar as coisas simples do caminho primeiro, eu gosto de atacar o cerne do problema antes de fazer qualquer outra coisa.
As partes fáceis geralmente são tarefas que eu mesmo posso fazer rapidamente ou tarefas mundanas que são mais trabalhosas do que qualquer outra coisa. Ao trabalhar com alguém, não quero desperdiçar seu tempo e fazê-los me ver escrever documentação para minha interface ou adicionar log de erros. Eu prefiro pular e atacar os desafios que precisam de duas pessoas para resolver.
Deixe para trás sinais para você limpar mais tarde por conta própria, como comentários ou TODOs. Defina cabeçalhos e classes de métodos vazios que podem ser implementados posteriormente ou preencha partes com pseudocódigo.
Não se preocupe com o perfeccionismo
Com base no último ponto, geralmente tento evitar picuinhas ao programar em par. Há um tempo e um lugar para lêndeas. Para mim, geralmente é no final quando eu repasso o código que foi escrito e o limpo para que eu possa enviá-lo para revisão. Insistir em um código quase perfeito é razoável no estágio de limpeza, mas se você ainda estiver na fase de resolução de problemas, então a picuinhas apenas atrasa as coisas, é obvio que você não vai disponibilizar um código mal feito em produção, a ainda não se esqueça que tem o PR que a galera enfatiza pontos de melhoria.
Mude isso
Por mais que eu ame estar no banco do motorista, é bom mudar as coisas ocasionalmente e assumir o papel de banco de trás. Observar como outra pessoa trabalha pode ser tão perspicaz quanto fazê-lo você mesmo. Gosto de observar como eles abordam os problemas e os passos que dão para superá-los. Às vezes, isso me ajuda a aprender novas técnicas que posso aplicar a outras situações.
Por outro lado, tente tomar as rédeas se você costuma ser o observador. Às vezes, você só precisa sentir o problema com suas próprias mãos para entender o ambiente e as condições com as quais está trabalhando. A experiência prática geralmente é a maneira mais eficaz de aprender e desenvolver suas habilidades. Ter um parceiro para programar atua como uma rede de segurança para ajudá-lo a escrever código de boa qualidade e superar rapidamente problemas e bloqueios.
A programação em pares é uma via de mão dupla... se você só vai em uma direção, você não consegue ver o outro lado, e nem seu parceiro. Certifique-se de que ambos pratiquem os dois lados da experiência, e você ficará melhor no final por isso.
Mantenha as coisas casuais
Às vezes, sinto que posso sofrer de ansiedade de desempenho. Quando estou sendo observado, é como se meu cérebro desligasse completamente. Eu esqueço como digitar, cometo muitos erros bobos e não consigo pensar direito. Mesmo o pensamento de programação em par costumava me fazer começar a suar nervosamente. Entenda suas dificuldades e supere-as!
Considere que seu parceiro pode estar se sentindo assim ao entrar em sua sessão. Alternativamente, você pode ser o único a se sentir ansioso. A programação em pares deve ser produtiva, não estressante. Certifique-se de que você e seu colega estejam confortáveis e não tenha medo de falar se algo estiver incomodando durante o processo.
Escusado será dizer que você deve ser respeitoso com seus colegas de trabalho (isso é obvio). Não os assedie por cometerem erros ou digitarem devagar. Não há nada a ganhar com tal comportamento. Nem todo mundo pode fazer o seu melhor quando os outros estão assistindo e isso não os torna inferiores ou incapazes de executar a tarefa que lhe foi proposta.
Esteja aberto a novas ideias
Isso se aplica a todos os aspectos da engenharia de software, mas é especialmente verdadeiro para programação em pares. Não destrua todas as ideias do seu parceiro porque elas não combinam com suas próprias filosofias. Isso apenas anula o propósito de trabalhar juntos em primeiro lugar.
Se uma ideia realmente não for viável, converse sobre ela primeiro e explique por que você acha que ela não funcionará, em vez de desconsiderá-la completamente. Ao falar sobre isso, você pode encontrar uma maneira de adaptá-lo em algo viável. Na pior das hipóteses, sempre vale a pena documentar quais opções foram consideradas, mesmo que não tenham sido aplicadas no final.
Defina um limite de tempo
Uma reclamação que tenho sobre programação em par é que às vezes é difícil encontrar um bom ponto de parada. Nessas situações, parece que a sessão se arrasta por muito tempo e passo mais tempo do que pretendia. Antes de começar, considere definir um limite de tempo rígido ou flexível apenas por precaução, entenda que o colaborador que irá “codar” com você tem outras tarefas e não pode ceder muito do tempo para estar mais de 1 hora em conjunto com você.
A duração ideal da sessão é a preferência pessoal, mas gosto de manter minhas sessões em torno de 30 minutos. Normalmente, planejo-os com antecedência e crio um evento de calendário para eles para que eu possa incorporá-los adequadamente à minha agenda e a delas consequentemente.
Uma nota sobre funções
Os livros didáticos ágeis falam sobre vários estilos de programação em pares com papéis definidos. Exemplos comuns incluem os estilos driver-navigator e ping-pong. Se você quiser usar um desses, tudo bem, mas geralmente não limito minha estratégia às especificidades de um desses estilos. Quando estou programando em pares, não estabeleço explicitamente regras sobre funções ou qualquer coisa. Eu apenas faço o que vem naturalmente para meu parceiro e para mim. Concedido, eu normalmente gosto mais do estilo clássico de navegador de driver, onde uma pessoa escreve o código enquanto a outra apresenta as ideias.
O desenvolvedor menos experiente deve ser o driver na maioria dos cenários. Implementar o projeto de um engenheiro sênior em uma sessão de programação em pares é uma experiência de aprendizado fantástica, pois ajuda você a absorver a ideia e entender os detalhes do esquema sugerido.
Desenvolvedores experientes também podem se beneficiar da programação em pares, mas, pela minha experiência, essas sessões são melhores quando as sessões são mais curtas e mais focadas. Engenheiros seniores geralmente são melhores em pegar uma ideia e executá-la, então trabalhar juntos em toda a implementação nem sempre é necessário.
Aprendizado
A programação em pares é uma prática comum em qualquer trabalho de tecnologia, portanto, ficar confortável com isso e aprender a fazê-lo bem é uma ótima maneira de obter uma vantagem extra em sua produtividade. Existem muitas variações dessa prática, então sinta-se à vontade para brincar com diferentes estilos e encontrar o que funciona melhor para você. O conselho que escolhi apresentar aqui pretendia ser aplicado a qualquer forma de programação em par e não limitando apenas a programação, tarefas em pares com uma pessoa que possui uma experiência maior do que a sua ou é novo na área, mas tem vivência em outras vertentes, pode ter certeza que vai ser super enriquecedor para vocês e acharam a solução do problema de forma bem mais rápida. Entenda e tenha a humildade de admitir que não sabemos tudo, independente da idade ou anos de experiência sempre aprendemos algo novo com as pessoas.
Top comments (0)