Revisões por pares ou programação em pares, ou ambos?[fechado]

Question

• Você participa de revisões de código por pares ou pratica programação em pares, ou ambos?
• Você conseguiu demonstrar um aumento na qualidade do software usando essas práticas?
• Que benefícios e desvantagens você observou no decorrer da prática?
• Que obstáculos à implementação você enfrentou?

No meu caso, nossa equipe de desenvolvimento buscou revisões por pares de vários artefatos de software diferentes (análises de requisitos, planos de teste, código e assim por diante).A programação entre pares nem sequer foi considerada uma opção.

A prática de revisão por pares foi empurrada de cima para baixo e os desenvolvedores nunca aderiram a ela.Tínhamos um grupo externo de SQA que coletava métricas das atividades, mas os números eram praticamente inúteis, já que o esforço era tímido.Depois de anos sendo esta a forma “oficial” de fazer as coisas, os desenvolvedores passaram a ignorar coletivamente os procedimentos prescritos.

Agora há menos visibilidade sobre quando os bugs estão sendo inseridos no ciclo de vida.E não fazer as revisões por pares levou a uma maior especialização da equipe... onde ninguém realmente conhece os requisitos/lógica dos componentes fora de sua própria área especializada do sistema.

Seria valioso conhecer suas experiências com avaliações de pares ou programação em pares, especialmente histórias de sucesso.

Answer 1

Quando eu era jovem e tolo, um dos meus primeiros trabalhos foi construir um analisador para extrair determinados campos de um longo arquivo PDF que era despejado em texto não formatado.Eu sabia o suficiente para usar alguma forma de regex, mas não o suficiente sobre regex para fazer bem o trabalho.Vários dias depois terminei a tarefa, mas na revisão por pares fiquei arrasado ao saber que poderia ter feito melhor e que o que produzi foi lixo.Aprendi a fazer análise lexical apenas para provar que não era um idiota, mas digamos apenas que o processo de revisão por pares foi uma droga.Eu não precisava de uma pessoa experiente para dançar sobre meus fracassos, eu precisava de um mentor e me lembrei disso sempre que fiz uma revisão por pares.

Gosto de avaliações de colegas quando verificamos os egos na porta.(Isso inclui o meu!) Há uma quantidade finita de tempo neste mundo e apenas um limite para o que você pode aprender e fazer.Através de uma boa revisão por pares, você pode expandir seu conhecimento e fazer mais em menos tempo.Os problemas surgem quando as coisas se transformam em verificação de sintaxe anal.

Eu tenho algumas regras por causa disso.Não reviso por pares nada que possamos automatizar.Execute uma verificação ortográfica e embelezador de código.Se você tiver algo como o FXCop disponível para você, execute-o, faça o que ele diz ou tenha um bom motivo para não ter.Então podemos ver como o código é montado, como funciona e o que podemos fazer para melhorá-lo.Dessa forma, você obtém uma perspectiva diferente sobre como resolver um problema e por que alguém pensa dessa forma.Às vezes o contrário não é realmente melhor, às vezes a nova solução é fantástica e algo que você usará pelo resto de sua vida como programador.Feita a revisão, pronto, não vou usar isso como exemplo contra você.Cabe a você aprender o que quiser com isso.Não vou conseguir por medo ou ameaça, você é uma pessoa inteligente e vou deixar você demonstrar isso.

Answer 2

Tentamos garantir que nenhum código entre em produção sem ter passado por pelo menos outro par de olhos.
Normalmente, isso significa que revisamos o código.Tentamos criar o hábito da equipe de que as revisões são uma parte inerente da escrita do código.Você escreve e depois pede a opinião de alguém.
Além disso, em projetos onde temos pessoas suficientes disponíveis (quando as tarefas são do tamanho certo) tentamos emparelhar a programação.
Devo dizer que definitivamente vimos uma vantagem nisso.Primeiro de tudo, é uma ótima maneira de orientar desenvolvedores juniores na equipe - quando você revisa o código deles, você mostra a eles o que pode ser feito melhor e, ao se juntar a eles, eles veem maneiras melhores de fazer as coisas, como as pessoas experientes pensar e até como usar melhor o IDE.
Além disso, mantém toda a equipe sincronizada no que diz respeito a saber a aparência do código.
E, além disso, simplesmente aumenta a alegria e o desenvolvimento pessoal de todos - uma equipe que é capaz de falar e raciocinar sobre código é uma equipe melhor, uma equipe que continua aprendendo e compartilhando.

Algumas coisas a serem observadas:

• Certifique-se de que os idosos deixem os juniores programarem também quando formarem pares
• Não deixe as pessoas se unirem em pequenas tarefas, geralmente é uma perda de tempo
• Observe como os pares se dão bem (não force um par)
• Lembre-se de embaralhar os pares de vez em quando
• Não deixe que as avaliações correspondam ao ego - não deixe as pessoas esmagarem outras

Answer 3

A revisão por pares deve ser OBRIGATÓRIO.

Você pode ler e encontrar vários artigos e livros que discutem diferentes maneiras de abordar isso em equipes de vários tamanhos, mas parece estar perguntando sobre experiências.

Pessoalmente, acho que a revisão por pares deveria ser divertida.Comida fornecida e manter o ambiente jovial.Realmente deveria ser tratado como um momento em que desenvolvedores/programadores podem aprender uns com os outros e não uma chance de julgar (e todos nós sabemos como todo programado parece nascer com um gene inato de julgamento).Tenho tendência a apreciar ou ajudar a organizar as avaliações para que sejam 1/3 ou 1/4 do tempo abertas.Com isso quero dizer quando o grupo se reúne e uma pessoa apresenta um projeto que está trabalhando ou mesmo revisando e que nem sequer está relacionado ao projeto atual (sei que é difícil com prazos, mas tente).

Os criativos geralmente se reúnem para exibir pinturas, designs e artistas que gostam atualmente, a fim de ajudar a facilitar a inspiração.Realisticamente, a inspiração deve ser o conceito principal que você espera promover em uma revisão.Secundariamente, as pessoas percebem naturalmente coisas que seus colegas desenvolvedores fazem e que NÃO notaram antes.“Nossa, então você conseguiu fazer isso em uma única linha de código?Legal." Inspirar os desenvolvedores e motivados sobre o que fazem, o que estão trabalhando e como eles farão mais dividendos do que usar a revisão por pares para estabelecer hierarquia e classificação.

Finalmente, vem a parte da “revisão”, mas é um fato inevitável.Seus melhores desenvolvedores verão um código de baixa qualidade e, depois de análises suficientes, é hora do programador de baixa qualidade avançar ou esquecê-lo.

Se você mantiver as coisas positivas e organizadas, geralmente será uma ótima experiência.

Quase esqueci de tocar na programação em pares.Isso é mais difícil de configurar.Obviamente você não pode ter dois dos seus programadores mais fracos trabalhando juntos ou você pode muito bem organizar um milhão de macacos com um milhão de máquinas de escrever.Tente colocar uma pessoa mais forte com uma mais fraca e ofereça incentivos para ambas de forma privada.Alguém que é mais fraco deve saber que a melhoria pode ser recompensada (se necessitar de tal incentivo) e o programador mais forte deve saber que os verdadeiros líderes começam como bons mentores.Certifique-se de que o desenvolvedor mais fraco esteja digitando.Não vice-versa ou vira uma apresentação e "bocejar"alguém pode não ganhar nada com a experiência.

Answer 4

Já fiz vários coaching ágil e, para ajudar as pessoas a superar o "estigma" da programação em pares, chamamos isso de "revisão de código e design em tempo real".As pessoas parecem entender melhor o conceito quando você o coloca nesses termos.

Answer 5

A única experiência diretamente relacionada que tenho é com revisões de design por pares (há muito tempo).E eles eram péssimos.Se você leu a literatura, ficou claro que eles quebraram várias regras de boas críticas (pular nas pessoas, foco na ortografia, nenhum resultado claro, etc.).etc.), mas era tudo o que sabíamos.

MAS desde então, estive envolvido em muitas revisões de código off-line.

Dependendo do projeto, eles foram solicitados antes do check-in na filial "ativa" ou em algum momento aleatório depois.Em 3 dos 4 projectos foram adoptados, inicialmente como um mal necessário, mas mais tarde como um contributo valioso.

O benefício de qualquer revisão de trabalho deve ser fazer com que todos escrevam códigos melhores e dar orientação até mesmo aos melhores programadores (seja honesto, seus programadores importantes realmente escrevem códigos legíveis?) Uma vez que você consiga persuadir funcionários menos experientes a dizer que não o fazem entender algo - você está ausente.Algumas das fotos quentes irão bufar, mas as melhores realmente pensarão sobre o que escreveram e realmente mudarão os nomes das variáveis ​​​​ou o layout - e talvez até adicionarão um comentário.

O quarto projeto usa um esquema imposto de revisão 'em um momento aleatório' e os líderes técnicos ainda não o implementaram (equipe quebrada?)

---

As duas práticas que você descreve são abordagens formais.Eles não funcionam bem para todas as personalidades e grupos.

Experimente algo que você acha que sua equipe pode realmente fazer e veja se pode ser melhorado.

Depois de ter esse par extra de olhos em seu código, você não vai querer olhar para trás

Answer 6

• Sim, nossa empresa utiliza revisões de código por pares.Nós as conduzimos como revisões over-the-shoulder e convidamos o testador da equipe para participar da reunião para obter uma melhor compreensão das mudanças.

• Existem benefícios definitivos na revisão de código, como vários estudos conseguiram demonstrar.Para nossa empresa, ficou evidente que a qualidade do código aumentou à medida que o número de chamadas de suporte diminuiu e o número de bugs relatados também diminuiu.OBSERVAÇÃO:Alguns dos benefícios aqui foram resultado da implementação do Scrum e do abandono do Waterfall.Mais sobre Scrum abaixo.

• Os benefícios da revisão de código podem ser um produto mais estável, um código mais sustentável, pois se aplica à estrutura e aos padrões de codificação, e permite que os desenvolvedores se concentrem mais em novos recursos, em vez de bugs de “combate a incêndios” e outros problemas de produção.Realmente não há desvantagens se as revisões de código forem conduzidas “corretamente”.Mais sobre o “caminho certo” abaixo.

• Alguns dos obstáculos a serem superados durante a implementação de revisões de código são a ideia de que o “irmão mais velho” está me observando e a ideia de que não ter um código perfeito significa tortura e dor.Fazer com que os desenvolvedores confiem uns nos outros às vezes é difícil, especialmente quando envolve atitudes de “hierarquia” ou “mais santo que você” e colocar seu trabalho árduo sob um microscópio.A confiança é a chave para resolver esses problemas.Um desenvolvedor deve confiar que não será punido pelos colegas ou pela gerência por erros no código.Isso acontece com todo mundo.Anote o problema, resolva-o e siga em frente.

ScrumUm dos benefícios de utilizar a metodologia Scrum é que o ciclo de desenvolvimento (“sprint”) é curto.O prazo do “sprint” é determinado pelo que funciona melhor para sua organização e exigirá algumas tentativas e erros, mas na verdade não deve exceder quatro semanas de iterações.A vantagem é que isso exige que os desenvolvedores se comuniquem diariamente e comuniquem os problemas no início do projeto.Isto foi inicialmente adotado pelo nosso departamento de desenvolvimento e se espalhou por todas as áreas da nossa empresa, pois os benefícios do scrum são abrangentes.Para mais informações, veja: http://en.wikipedia.org/wiki/SCRUM ou http://www.scrumalliance.org/ .Como as iterações de desenvolvimento são menores, o processo de revisão de código revisa pedaços menores de código, tornando a revisão mais propensa a encontrar problemas do que horas ou dias de revisões formais.

“Caminho Certo”Revisões de código feitas “da maneira certa” são completamente subjetivas.No entanto, pessoalmente acredito que deveriam ser avaliações informais e indiretas.Todos os participantes de uma revisão devem evitar atacar pessoalmente a pessoa que está sendo revisada com declarações como "Por que você fez dessa maneira?" ou "O que você estava pensando?" etc.Esses tipos de comentários diminuem a confiança entre os pares, levando à animosidade e horas de discussão sobre a maneira melhor/correta de codificar uma solução.Tenha em mente que os desenvolvedores não pensam ou codificam exatamente da mesma forma e há muitas soluções para um problema.
Apenas um pequeno esclarecimento sobre revisões indiretas;eles podem ser realizados por meio de compartilhamento remoto de área de trabalho (escolha a opção aqui) ou pessoalmente.No entanto, eles não devem ser limitados apenas aos desenvolvedores.Normalmente convidamos toda a nossa equipe scrum, que consiste em dois desenvolvedores por equipe, um testador, um responsável pela documentação e o proprietário do produto.Todos os não desenvolvedores estão lá para compreender melhor as mudanças ou novas funcionalidades que estão sendo feitas.Eles são livres para fazer perguntas ou fornecer sugestões, mas não para tomar decisões de codificação ou comentários.Isso tem sido eficaz, pois serão feitas certas perguntas que podem mudar a direção do projeto, pois os requisitos iniciais podem ter perdido um cenário, mas é disso que se trata o ágil, mudança.

SugestãoEu recomendo fortemente pesquisar revisões de scrum e código antes de exigi-las.Crie as regras básicas para cada um e implemente-as como parte de sua cultura para obter um produto de melhor qualidade.Deve tornar-se parte da sua cultura para que faça parte de um processo natural e integrado em todos os níveis, pois é uma mudança de paradigma de má qualidade, prazos perdidos e frustração para produtos de melhor qualidade, menos frustração e entregas mais pontuais .

Answer 7

Uma análise comparativa depois de passar para análises de RP no github a partir da programação em pares.

O foco está em listar passo a passo o que nossas equipes seguem agora no processo de revisão de RP.

“Revisões de código versus programação em pares” https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926