Programação em par

Origem: Wikipédia, a enciclopédia livre.

Definição[editar | editar código-fonte]

A "Programação em par".

A programação em par (ou "programação pareada") é uma técnica de desenvolvimento de software ágil em que dois programadores trabalham juntos em uma estação de trabalho.[1] Um deles, o "piloto", escreve o código, enquanto o outro, chamado de "co-piloto" (ou "navegador"), analisa cada linha do código. Os dois programadores geralmente trocam de papel frequentemente.

Evitando distrações e criando um ambiente colaborativo, em geral, a programação pareada se prova mais produtiva do que a isolada. Enquanto está analisando, o co-piloto também considera a orientação estratégica do trabalho, dando ideias para melhorias e comenta sobre possíveis problemas futuros que devem ser resolvidos. Isso libera o controlador para concentrar toda a sua atenção nos aspectos táticos da tarefa atual.

Origem[editar | editar código-fonte]

A origem da programação em par é incerta. De acordo com Agile Alliance[2], está relacionado ao conceito "Dupla Dinâmica", observado por Larry Constantine no final da década de 70, porém algumas pessoas sugerem que já era praticado por volta dos anos 50.[3]

Em março de 1993 Judith D. Wilson publicou o artigo "The benefits of collaboration for student programmers"[4] (Os benefícios da colaboração para estudantes de programação), um estudo empírico inicial indicando os benefícios do trabalho em par para as tarefas de programação especificamente. Estudos posteriores desenvolvem melhor o assunto, sendo motivados pelo desejo de "validar a programação em par depois de já ter ganhado popularidade através do Extreme Programming[5], metodologia ágil criada por Kent Beck em 1996.

Métodos para boa implementação da Programação em par[6][editar | editar código-fonte]

Entrosamento[editar | editar código-fonte]

Uma boa química entre os participantes é essencial. Estes devem entender como o colega gosta de trabalhar, para chegar em um meio coeso de resolver os problemas.

Entender o motivo[7][editar | editar código-fonte]

É de extrema importância que os programadores entendam a sua função dentro do projeto, porém, algo mais importante que isso é o entendimento do motivo pelo qual os mesmos estão trabalhando com este sistema, para que se usufrua ao máximo deste método. Para isso, um bom diálogo e entrosamento (como já foi citado antes) são de extrema importância

Troca de Pares[editar | editar código-fonte]

Outra dica para uma melhor implementação deste método, é a troca de frequente de pares. Os times decidem quando a troca será realizada. Uma das alternativas seria realizar a troca ao fim de cada Sprint. Este método é importante para que todos os integrantes aprendam a trabalhar uns com os outros, melhorando o desempenho de toda a equipe.

Estrutura[editar | editar código-fonte]

Para que a aplicação do Programação em par seja viável, é necessária uma boa estrutura para que as duplas realizem os projetos. Com o intuito de alcançar a melhor estrutura para o trabalho, deve-se adquirir materiais como Cadeiras Ergométricas, mesas com tamanho suficiente para comportar todos os equipamentos utilizados no método, e um monitor de boa qualidade e bom tamanho de tela.

Vantagens[6][editar | editar código-fonte]

A técnica de programação em par apresenta algumas vantagens significativas se comparada com as técnicas de desenvolvimento de software mais tradicionais. Por ser um método de programação que utiliza duas pessoas ao mesmo tempo, resulta em melhor colaboração, maior qualidade, melhor código e melhores práticas de desenvolvimento sustentado. Permitindo assim, um melhor aprendizado e compartilhamento de informações entre os desenvolvedores e, em geral, mais de uma pessoa pensando no mesmo problema pode ajudar a criar soluções e cenários mais simples e eficazes.

O Departamento de Engenharia de Software e Ciência da Computação do Blekinge Institute of Technology realizou uma pesquisa em que 96% dos programadores que já programaram utilizando a técnica de programação em par, preferiram trabalhar em um ambiente com essa metodologia do que programarem sozinhos. Um forte indicativo de que além de performance, a técnica de se programar em par também é satisfatória.[8]

Dentre as principais vantagens estão:

Melhora a disciplina do time[editar | editar código-fonte]

A prática de programação e desenvolvimento de software é muitas vezes cansativa e isso pode gerar distrações durante o desenvolvimento. Quando criamos um código sozinho, é muito fácil nos rendermos à tentações externas como entrar em redes sociais, verificar e-mails, ou fazer qualquer outra coisa que tire nossa atenção da tarefa.

Compartilhar conhecimento[editar | editar código-fonte]

Como dito anteriormente, os papéis de piloto e co-piloto na programação em par são invertidos sempre que um ciclo ou uma etapa é finalizada. Permitindo assim a troca de informações, técnicas e conhecimento geral entre os dois desenvolvedores e melhorando também o nivelamento do nível técnico da equipe de desenvolvimento.

Além da rotação entre uma dupla, também é possível fazer o revezamento entre diferentes duplas de uma equipe. Dessa forma, o código é compartilhado pela equipe inteira, de maneira que todos os integrantes do time tenham conhecimento sobre as diferentes partes do código e versões do projeto. Facilitando assim, uma possível manutenção futura por qualquer membro da equipe e reduzindo algum possível impacto negativo casa algum integrante saia do grupo.

Melhor qualidade do código[editar | editar código-fonte]

Um dos grandes desafios da programação é criar códigos limpos e sem erros de forma rápida. Entretanto, essa dificuldade é superada com a técnica de programação em par, pois todo o código produzido é revisado e aprimorado constantemente por diferentes integrantes da equipe. De forma geral, muitos programadores não acham a tarefa de revisar seus códigos várias vezes agradável, porém quando se programa em par revisar o código de outro programador pode ser uma tarefa mais agradável, visto que as técnicas e formas de programar das pessoas são muito provavelmente diferentes, o que podem apresentar inovações e ganho de conhecimento. Além de que com mais de uma pessoa pensando em possíveis soluções é mais fácil identificar possíveis erros e alternativas para na produção do código.[9]

Em um estudo performado pela Universidade de Utah, equipes que utilizaram o método de programação em par completaram vários projetos com uma qualidade de código superior, além de em muitos casos certas funcionalidades terem sido implementadas com uma quantidade menor de linhas de código do que programadores sozinhos.[9]

Outro fator muito comum, é quando programadores se deparam com um problema que não conseguem resolver, e por conta disso, acabam utilizando "gambiarras", trechos de outros códigos ou soluções não muito ideais que de certa forma resolvem o problema. Já em dupla, há um rigor maior em seguir os padrões do projeto e manter uma boa qualidade no código, tendo em vista que seu algoritmo vai ser visualizado e revisador por outra pessoa.

Gera mais união na equipe[editar | editar código-fonte]

Com diversos integrantes de um time participando do desenvolvimento de diferentes partes do código, mas do mesmo projeto final, o espírito coletivo é fortalecido. Pois dessa maneira, os erros e a qualidade do código passam a ser responsabilidade do time, e não de apenas uma pessoa.

Junto a isso também temos a criação de amizades e o fortalecimento das relações interpessoais, além da troca de experiências e conhecimento citados anteriormente, que fortalece ainda mais a união. Este fator pode resultar em melhorias de performance da equipe inteira, principalmente ao longo prazo, pois um time com mais sinergia tende a gerar melhores resultados.

Dificuldades[editar | editar código-fonte]

Ao utilizar a programação em par, algumas dificuldades nas realizações das tarefas podem ser encontradas. Um grande problema é a divergência de personalidades dos programadores envolvidos no projeto, uma vez que saber aceitar críticas de um companheiro de equipe é essencial para o desenvolvimento do projeto na qual estão envolvidos. Outra grande dificuldade na programação em par é mostrar ao cliente a relevância de ter dois profissionais trabalhando em conjunto em um projeto, em vez de apenas um. É de suma importância que o cliente entenda a programação em par como um investimento, tendo em vista que o projeto com dois desenvolvedores tende a ser muito mais elaborado e completo.[6]

Experiência de projeto[editar | editar código-fonte]

O artigo “The Costs and Benefits of Pair Programming”[10] descreve uma experiência muito interessante de programação em par, onde em resumo, antes de começar a equipe já concordava que diminuiria drasticamente o risco de gerar erros que geraria um retrabalho depurando o código para serem solucionados, haveria uma revisão de código mais ampla e a oportunidade de troca de conhecimento entre o time. No começo o time teve dificuldades de implementar, uma vez que não estavam acostumados com a metodologia, mas depois com o tempo conseguiram criar sinergia entre com os pares. Trabalhando junto eles evitaram situações onde teriam que fazer coisas duas vezes e a codificação era mais rápida devido ao que foi chamado “efeito de dois cérebros” e gerando muito mais confiança na assertividade e qualidade da solução.

Neste artigo Alistair Cockburn e Laurie Williams realizaram um estudo analisando a quantidade de tempo que a programação em par consome. Foi descoberto que há apenas uma diferença de 15% de tempo a mais, comparada ao trabalho da programação tradicional, e não o dobro do tempo, como costumam afirmar. Além disso, foi percebido aumento na qualidade de código (ou seja, menos bugs), menos linhas de código (mais simplicidade) e maior satisfação do time ao trabalhar com a programação em par. Parear consome 15% a mais de tempo total de trabalho mas reduz, pelo menos, 15% a quantidade de códigos com defeito.

Variações no Pareamento[editar | editar código-fonte]

Especialista–especialista
O emparelhamento entre especialistas pode parecer a escolha óbvia para a maior produtividade e pode produzir ótimos resultados, mas geralmente fornece pouca percepção sobre novas maneiras de resolver problemas, pois é improvável que ambas as partes questionem as práticas estabelecidas.[11]
Especialista–novato[editar | editar código-fonte]
O emparelhamento especialista-novato cria varias oportunidades em que o especialista pode orientar o novato. Esse emparelhamento também pode introduzir novas ideias, pois é mais provável que o novato questione as práticas estabelecidas. O especialista, agora obrigado a explicar as práticas estabelecidas, também está mais propenso a questioná-las. No entanto, neste par, um novato intimidado pode passivamente "observar o mestre" e hesitar em participar de forma significativa. Além disso, alguns especialistas podem não ter a paciência necessária para permitir a participação construtiva de novatos.[12]
Novato–novato[editar | editar código-fonte]
O emparelhamento novato-novato pode produzir resultados significativamente melhores do que dois novatos trabalhando independentemente, porém essa prática geralmente é desconsiderada, já que é mais difícil para novatos desenvolver bons hábitos sem um "modelo" adequado.[10]

Programação em Par Remota[editar | editar código-fonte]

Uma opção ainda mais versátil que seria ótima para ser colocada em prática nesta atual pandemia é a Programação em Par Remota. Também conhecida como virtual pair programming ou distributed pair programming, é a programação em par em que os dois programadores estão em locais diferentes, trabalhando por meio de um editor colaborativo que funciona em tempo real, de áreas de trabalho compartilhadas, como no Anydesk[13], ou utilizando um plugin num IDE. Diferente da Programação em Par tradicional o emparelhamento remoto apresenta dificuldades como atrasos extras para coordenação e perda de comunicação verbal, resultando em confusão e conflitos sobre coisas como quem vai assumir o papel de "piloto".

Algumas ferramentas para ajudar a execução da Programação em Par Remota:

Referências

  1. «InfoQ: Como programação pareada funciona». www.infoq.com. Consultado em 22 de maio de 2012 
  2. «Pair Programming: Does It Really Work?». Agile Alliance | (em inglês). 17 de dezembro de 2015. Consultado em 28 de janeiro de 2022 
  3. Brack, Fagner (24 de novembro de 2019). «Pair Programming». Medium (em inglês). Consultado em 28 de janeiro de 2022 
  4. Wilson, Judith D.; Hoskin, Nathan; Nosek, John T. (1 de março de 1993). «The benefits of collaboration for student programmers». New York, NY, USA: Association for Computing Machinery. SIGCSE '93: 160–164. ISBN 978-0-89791-565-6. doi:10.1145/169070.169383. Consultado em 27 de janeiro de 2022 
  5. «What is Extreme Programming?». ronjeffries.com. Consultado em 28 de janeiro de 2022 
  6. a b c «Pair programming: como implementar a programação em par!». Blog da Trybe. 30 de julho de 2021. Consultado em 5 de janeiro de 2022 
  7. Datum (31 de agosto de 2020). «Programação pareada: entenda melhor o que é e como funciona». Blog Datum | Tecnologia e inovação | Porto Alegre | Fábrica de software. Consultado em 27 de janeiro de 2022 
  8. «O Que é Programação Em Par?». www.digite.com. 12 de fevereiro de 2021. Consultado em 31 de janeiro de 2022 
  9. a b «Scientific Research Into Pair Programming». tuple.app (em inglês). Consultado em 31 de janeiro de 2022 
  10. a b «The Costs and Benefits of Pair Programming» (PDF). Alistair Cockburn e Laurie Williams. Consultado em 5 de janeiro de 2022 
  11. Lui, Kim Man (Stembro 2006). Pair programming productivity: Novice–novice vs. expert–expert (PDF). [S.l.]: Int. J. Human-Computer Studies 64 (2006) 915–925.  Verifique data em: |ano= (ajuda)
  12. Williams, Laurie. Pair Programming Illuminated. [S.l.]: Boston: Addison-Wesley Professional 
  13. a b «O aplicativo de desktop remoto rápido». AnyDesk. Consultado em 7 de janeiro de 2022 
Ícone de esboço Este artigo sobre programação de computadores é um esboço. Você pode ajudar a Wikipédia expandindo-o.