Quase um ano se passou desde que me mudei para Moscou para morar e trabalhar em Yerevan. Nesta história, não falarei sobre minha vida nesta cidade maravilhosa (é muito legal aqui), mas sobre coisas mais mundanas. Ou seja, sobre as práticas que aplicamos ao desenvolver nosso produto na Vineti.
Se você ainda estiver interessado, bem-vindo ao gato.
Na Vineti, usamos
uma metodologia de
programação extrema e ativamente usamos a programação em pares. Quando cheguei à Vineti, a programação extrema era algo novo e desconhecido para mim, mas depois de um ano de desenvolvimento nesse estilo, posso dizer que agora escrever código para mim se tornou algo não muito conveniente e produtivo.
Quando há uma pessoa próxima a você que observa atentamente o que você escreve, o código é extremamente legível. Além disso, no processo de escrever o código, ocorre a transferência de treinamento e conhecimento entre os participantes do processo, e isso, do meu ponto de vista, ocorre da forma mais eficaz.
Acontece que aqueles que nunca usaram essa abordagem na prática experimentam vergonha e desconforto, porque você precisa se comunicar constantemente com seu parceiro e escrever código sob supervisão rigorosa, mas com o passar do tempo, e você entende que o parceiro está aqui, para ajudá-lo, não machucá-lo.
Benefícios da abordagem
As vantagens da programação em pares em comparação com a abordagem padrão são diversas, mas, do meu ponto de vista, a mais importante é a constante transferência de conhecimento sobre o código do aplicativo entre os participantes do processo. Você pode construir pares e rotações (mudança de engenheiros participantes) para que cada engenheiro tenha conhecimento completo de todas as partes do aplicativo. Isso é especialmente importante se você precisar manter uma grande base de códigos.
A próxima vantagem é um processo de aprendizado bastante eficaz. Você pode emparelhar para que os mais experientes estejam sempre emparelhados com os engenheiros menos experientes. Para o desenvolvedor sênior, a regra é "se você quer saber algo bem, tente ensinar outro". Há também a oportunidade de reforçar suas habilidades de comunicação, pois você precisará explicar muitas e muitas vezes.
Na Vineti, usamos o
TDD no processo de programação em pares, o que nos permite dividir inicialmente uma tarefa grande e complexa em pequenas partes e refletir sobre a arquitetura da solução antes mesmo de escrever o código. Além disso, na solução de problemas complexos, ter um parceiro com quem você possa discutir a abordagem escolhida para resolver o problema e analisar sua otimização no processo de trabalho, sem a necessidade de planejar reuniões adicionais dentro da equipe, ajuda muito.
E, finalmente, a programação de pares está bem combinada com a metodologia
TDD . Em Vineti, geralmente um engenheiro escreve testes e tenta descrever o maior número possível de situações. O segundo engenheiro grava o código do recurso, quando o primeiro engenheiro lhe diz como simplificar o código, implementando um círculo de refatoração vermelho-verde.
Desvantagens
Como desvantagens dessa abordagem, eu provavelmente atribuiria a complexidade de configurar o próprio processo e a necessidade de seleção adequada dos participantes em pares, o que exige esforços adicionais do líder da equipe e uma compreensão completa das habilidades e hábitos de todos os membros de sua equipe.
Se falamos sobre o fator humano, é importante que os engenheiros atualmente emparelhados para o período de trabalho conjunto tenham um modo comum de chegar ao escritório, almoço etc. Isso nem sempre é fácil e é necessário formar pares levando em consideração esse recurso.
Manter um padrão comum
Uma das condições para a programação eficaz de pares é a presença de uma abordagem estrita e mais padronizada para escrever código dentro de comandos. Por exemplo, usamos rublop eslint, mais bonito, para que o código fique no mesmo estilo no processo de escrevê-lo. Como ambiente de desenvolvimento, usamos o VS Code e o terminal iTerm c zsh. Essa padronização permite que você gire rapidamente os engenheiros em pares, minimizando o período de adaptação.
Na minha opinião, os casais precisam ser rotacionados após a conclusão de uma tarefa. Isso fornece a menor rotação efetiva possível. A mudança de função pode ocorrer em um dia, mas isso permanece a critério de um engenheiro mais experiente em um par. É importante não se deixar levar, não tentar resolver todos os problemas, pois a ausência de uma mudança de papel pode afetar negativamente a eficácia do casal como um todo.
Programação emparelhada com San Francisco
Pessoalmente, tive a experiência de programação remota de pares com um colega do escritório americano da Vineti, para isso usamos o plug-in Live Share para o VS Code. A experiência é interessante, mas essa situação tem várias desvantagens em comparação com a programação de pares padrão. O primeiro é a falta de comunicação pessoal direta. No meu caso, essa também é uma grande diferença de fuso horário. Eu tive que escrever código depois de quase um dia inteiro, o que, para mim, pessoalmente foi muito cansativo.
Como se adaptar à programação de pares
Tente usar a experiência de outras empresas e, eventualmente, desenvolva sua abordagem dentro da empresa. A opção ideal, conveniente e funcional para todos, infelizmente, não existe.
Também não tenho certeza de que essa metodologia seja adequada para todas as empresas. Por exemplo, se você tiver apenas 3 desenvolvedores em uma equipe, obviamente não poderá obter muitos benefícios com a implementação da programação em pares. Ou, se você tiver muitas vantagens para os jogadores da equipe, será muito difícil construir bons pares.