Quando funciona a programação em par? Quando evitá-lo?

A programação em pares funcionou para mim em pouquíssimas situações.

Onde a programação em pares falha por mim

The short story is that pair programming doesn’t work for me as the main way of developing software. I can pair program for a day, or maybe a week, especially if we’re focused on a particular problem. But after that? I’m done. Toast. I don’t want to see anyone, talk to anyone, and I need at least a couple of days in a cave until I’m fit for human company again.

It’s a sad story, but the funny thing is that I’m so much happier now with how it ended. I’m happily employed on a contract where I work from home or from a coffee shop, and I’ve made new friends and explored more of San Francisco than I ever thought possible. I have a bicycle and a laptop, and as long as I meet my deadlines and check in code regularly, my time is my own.

I’ll list the big problems I have with pair programming up front and give you the detail and anecdotes later.

1. Split focus.
2. No experimentation.
3. No high notes.
4. No pride in ownership.
5. No escape...

...I asked my co-workers if they saw what I saw, if I was missing something, anything -- I didn’t see how this could work, how people could keep doing this. They said I was doing fine, that it just took time to settle in and adjust. That it was hard for everyone at first.

Eventually, I retreated into myself. Between the blinding headaches, the insomnia, and the pounding, unmet need to write code, I stopped responding to input. I could stare at a screen and not see anything. Someone could talk to me unexpectedly and I wouldn’t hear them. I was fulfilling the rote requirements of my job, but I wasn’t there. I’d used up everything I had just showing up for the day. I started checking my iPhone when my other partner was typing.

Finally -- just shy of three months later, and for the first time ever -- I was fired for not being a team fit when pair programming.

Not Alone

I wrote this not just to understand it, but also to be able to talk about it. There’s been a presumption that pair programming works for most people and is much easier and faster than programming solo would be. This may or may not be the case, but as a long term practice, pair programming doesn’t work for me. There are many other people that pair programming doesn’t work for either. We matter too...

    

Minha equipe fez programação em pares desde a sua criação, muito antes de eu trabalhar lá, como parte de uma loja em estilo de "programação extrema". A programação em pares é o estado padrão ; as pessoas só ficam realmente solteiras se houver um número ímpar, ou ocasionalmente para investigações, especialmente aquelas que envolvem mexer com equipamentos hostis e tentar fazê-lo funcionar.

"Junior / senior" não é o único caminho a percorrer. "Intermediário / Júnior" é útil; ajuda o cara de nível intermediário a sintetizar o conhecimento obtido, forçando-o a comunicá-lo a outra pessoa. "Intermediário / Intermediário" desafia duas pessoas a trabalharem juntas para compartilhar seus conhecimentos, comunicar e trabalhar como parte de uma equipe. E mesmo se você tem dois caras realmente altos, as chances são de que eles tenham diferentes áreas de especialização e possam ter diferentes abordagens. Os aspectos de compartilhamento de conhecimento não terminam, uma vez que alguém está vagamente "atualizado" em um projeto. Em vez disso, a programação em pares é o epítome de uma organização de aprendizagem . Novas técnicas e melhores práticas se espalham rapidamente.

A programação em par também ajuda a manter a qualidade do código (menos defeitos) e a sanidade do código (ele não apenas faz o que pretende, mas faz o que deve ... idealmente sem passar por um buraco de coelho de várias semanas fazendo a coisa errada, ou duas coisas certas que vão entrar em conflito descontroladamente). Isso ajuda os programadores a manterem o foco: aqui no coração do Vale do Silício, sede das 80 horas semanais de trabalho, podemos trabalhar por apenas 40 horas por semana, porque estamos fazendo codificações intensas durante oito horas por dia, trocando coisas fora um com o outro. (Além disso, se você passasse mais tempo fazendo programação em pares, provavelmente iria embora. Ou pelo menos esgotaria.) Isso é ótimo para equilíbrio entre trabalho e vida pessoal, e também ajuda sua organização quando é importante ter retorno rápido (retorno de baixa latência, em particular).

Não é tudo, completamente, 100% pêssegos e creme; Eu acho que a programação em pares é ocasionalmente um obstáculo à minha aplicação de processos cerebrais intuitivos que são úteis em certos problemas. Mais recentemente, em uma tarefa de vazamento de memória, passei algum tempo com e sem pares; sem um, eu me senti mais livre para mexer e experimentar sem realmente saber exatamente como explicar o que eu estava fazendo em qualquer momento. Há também algumas vantagens em trabalhar singleton, sendo capaz de sair em uma tangente e fazer certas refactorings selvagens (valorizadas na metodologia XP) por um capricho.

Mas, apesar de tudo, os benefícios superam em muito os custos, e o emparelhamento funcionou muito bem para nós: desde o estágio inicial até a aquisição por uma empresa maior, e nossa integração subsequente. (Falando nisso, a programação em par nos ajudou a manter uma continuidade da cultura através da expansão e apesar de um pequeno volume de negócios).

(Desenvolvemos um aplicativo de software em Perl, preço de tabela entre US $ 4.000 e US $ 40.000).

    

Eu nunca trabalhei em uma configuração de "Programação em Par" e ainda posso afirmar que fiz parte das três circunstâncias listadas. O cenário que você menciona parece mais "programação regular" com fases de ajuda / treinamento lançadas. Nós não fizemos tudo isso antes da "programação em pares" ter surgido? Pair Programming, eu diria que exigiria uma abordagem mais comprometida, onde o processo de compartilhamento dentro de uma equipe não pararia no minuto em que você resolvesse a tarefa imediata ou o problema em questão. Mas então é isso que eu "penso" não é o que eu "sei".

Pessoalmente para Programação em Par Eu gostaria de trabalhar em uma equipe onde tenho a chance de aprender e compartilhar meus conhecimentos. Uma equipe desequilibrada, na qual todos que trabalham com você estão a quilômetros à frente de você, ou então muito abaixo do nível de par pode ficar bem desinteressante rapidamente. Além disso, tenho medo de trabalhar com pessoas que são definidas em suas crenças e difíceis de convencer.

    

Temos experimentado a programação em pares em nossa equipe nos últimos meses. Sinto que é bastante útil quando você está trabalhando em algo novo (nova tecnologia, novo recurso, etc.), pois você pode rapidamente trocar ideias com outra pessoa da equipe e validá-la / invalidá-la. Além disso, uma análise de pares lado a lado ajuda a evitar erros.

Outro colega de equipe tentou usar programação em pares com um teste para fazer ATDD e eles ficaram muito felizes com os resultados (de acordo com seus cálculos, um aumento no custo de desenvolvimento de 20% levou a uma diminuição de cerca de 50% no tempo de teste)

    

Boa noite

Muitas vezes debatemos sobre práticas de Extreme Programming e a par programming . Voltando no tempo, somos capazes de entender que a programação é uma atividade solo porque os programadores precisavam de concentração e isolamento. Os programadores da época estavam na zona , um estado mental em que podiam focar eficientemente no código e tomar decisões agradáveis e criativas.

A programação pareada também parece ser arriscada se você assumir que um programador interrompe um ao outro. Por outro lado, é mais difícil interromper dois programadores trabalhando juntos. Na programação Solo, por exemplo, será mais fácil ser interrompido, então é quase impossível que um programador solo permaneça na "zona".

A qualidade do código é outra quando a linha morta está ao virar da esquina. As pessoas estarão sempre com pressa, sejam programadores emparelhados ou programadores solo: eles não aplicarão certas práticas recomendadas e apenas esquecerão os testes unitários.

Eu ficaria com a programação em pares. Porque quando se trata de riscos, quando um programador se vai, você sempre terá outro cara para documentar o processo e ensinar a todos como funciona.

    

Trabalhar com qualquer coisa de complexidade não trivial tende a ser um bom candidato para programação em pares, de modo que várias pessoas entendam o código, em vez de apenas um desenvolvedor conhecer uma parte da base de código. Outro caso é quando alguém está querendo transferir algumas habilidades. Um exemplo aqui pode ser ter alguém que é realmente bom em testes de unidade emparelhar com alguém não tão familiarizado com o conceito e, assim, ajudar a obter um hábito inicial em algo.

Quanto a onde evitar a programação em par, faça tarefas de trabalho simples, onde seria melhor dividir o trabalho em dois grupos e permitir que cada desenvolvedor fizesse parte do trabalho separadamente para realizar o trabalho. Algumas tarefas podem exigir apenas um pouco de digitação, mas não são tão grandes que vale a pena gastar algumas horas tentando encontrar uma maneira melhor de fazer isso, já que cada desenvolvedor pode usar uma abordagem de força bruta por alguns minutos. horas.