O que são processos comuns de revisão de código e o que é considerado ruim?


16

Minha empresa recentemente começou a fazer revisões de código formalizadas. O processo é o seguinte: você envia para um github, solicita uma solicitação pull, o código é revisado por aproximadamente três pessoas e, se tudo for aprovado, seu código será inserido.

O processo parece justo, no entanto, as três pessoas que fazem as revisões de código não parecem ser justas. Percebo que, quando coloco meu código para revisão, recebo algo entre 100 e 200 comentários. O número principal para mim foi de 300 comentários uma vez. Claro que você acha que são grandes mudanças, mas isso pode ser muito pequenas, com menos de 50 linhas de código (que inclui testes de unidade). Todos os comentários são considerados "obrigatórios" e sem argumentos.

Com isso em mente, meu principal problema aqui é que parece um pouco excessivo. Conversei com o grupo e eles me disseram basicamente que só porque eu tinha tantos anos de desenvolvimento em php não significa que eu sou um "desenvolvedor". Claro que isso parece mais doloroso do que não. Também noto que, dentro do grupo, eles não parecem produzir tantos comentários e na maioria das vezes ignoram ou desconsideram outros comentários ou sugestões que raramente o aceitam como um ponto válido, mesmo que algo seja quebrado.

Então, minha pergunta é se isso é justo? Ou comum?


3
Que tipo de comentários você está recebendo? Parece muito. Está formatando comentários? Codificação? É difícil responder sem saber mais sobre a natureza dos comentários (e talvez exatamente o que no seu código acionou os comentários).
MetalMikester

1
Ei - não tenho certeza se é o termo certo, mas geralmente são comentários gerais de "melhores práticas", como renomear variáveis, mover funções, renomear funções em mais de 3-5 vezes, etc. Temos phpcs instalados para que a formatação esteja correta.
user1207047

Também esqueci de mencionar neste tíquete, na verdade sou desenvolvedor de nível 3 nesta empresa. Eu tenho certificação php e tenho ido muito bem nos últimos 8 anos de trabalho aqui. Apenas recentemente isso começou a acontecer. Então, eu gostaria de pensar que depois de 8 anos, você saberia algo certo?
user1207047

1
"Então eu quero dizer que alguém gostaria de pensar que depois de 8 anos, você saberia algo certo?" - Bem, você ficaria surpreso ... As coisas que eu vejo no trabalho às vezes ...
MetalMikester 20/12/2013

Respostas:


15

Todos os comentários são considerados "obrigatórios" e sem argumentos.

IMHO essa é a verdadeira questão, uma vez que não há priorização nisso. Quando você recebe de 100 a 300 comentários, deve haver alguns deles com prioridade A (bugs reais), alguns com o prio B (com probabilidade de levar a erros mais tarde) e alguns com o prio C (tudo mais). Diga a seus colegas que você está disposto a respeitar todos os seus desejos, mas para que as mudanças sejam efetivas e seu tempo seja limitado, insista em uma prioridade. Em seguida, comece com a correção do comentário do prio A primeiro e, se você realmente tiver tempo para mais, poderá começar com B (se tiver sorte, seu chefe entenderá que a fixação do prio B e C não é tão importante e fornecerá a você algumas tarefas mais importantes em vez de desperdiçar seu tempo).


Eu tentei muitas vezes pedir prioridade nos comentários. Eu recebo algo como "é bom ter" e "obrigatório". Acontece que a grande maioria deles é "necessária".
user1207047

2
Eu já vi isso acontecer quando um desenvolvedor específico recebe muitos itens de ação de suas revisões para impedir que eles estraguem o código em outras áreas do programa. Mas isso seria para um desenvolvedor excepcionalmente pobre que é "forçado" ao projeto e o líder não pode se livrar deles por causa de decisões de gerenciamento.
quer

2
Sabe @Dunk, acho que você está bem aqui. Seu comentário realmente chegou em casa e eu aceitei esta resposta, pois acho que não posso aceitar um comentário. Sou um "outsider" desse grupo e percebo agora por que o círculo interno está ficando cada vez melhores e mais rápidos, e os que estão de fora não estão. Fui "forçado" a esta equipe pela gerência, sim e somos "forçados" a trabalhar juntos. Portanto, isso parece muito razoável e uma explicação lógica do porquê é mais difícil. Isso ou eu realmente cheira mal à codificação. A única maneira de descobrir isso é ir para outro grupo / empresa e ver por mim mesmo.
user1207047

4
@ user1207047: Você não deve aceitar uma resposta, porque gosta de um dos comentários abaixo, por ser contrário aos padrões e ao objetivo do site (acho que estou sentindo um padrão aqui). Há uma funcionalidade de comentário positivo para isso.
Webbiedave

10

Revisões de código podem ser um processo divisivo.

Você está em um cruzamento importante, no entanto. Faça uma análise cuidadosa sobre sua revisão. Eles estão identificando questões difíceis ou destacando falhas sérias no seu estilo e lógica?

Se for o primeiro, recomendo trabalhar em direção a uma resolução (novo trabalho ou novos processos de revisão de código).

Se for o último, recomendo ler e estudar muito o código para tentar melhorar o seu código com qualidade profissional.


Ei, bons pensamentos. Pelo que pude entender, algumas delas são de fato uma análise cuidadosa, mas a maioria delas parece exigente, como mover funções ou renomear funções. O problema é que, quando eles explicam seu processo de pensamento, de fato faz sentido, mas entre si não estão fazendo a mesma coisa e cometendo os mesmos erros que eu.
user1207047

Ainda mais, a revisão do código é tão profunda que esqueço o que estava fazendo e crio mais bugs ao corrigir o aplicativo devido aos excessos de centenas de comentários. Por exemplo, uma vez me disseram para reescrever uma grande parte do código. Antes disso, o código estava correto e funcional. Após a revisão do código e quase 150 comentários, a função original e a correção desapareceram e toneladas de erros foram inseridos. Quando percebi isso e os consertei, fui informado basicamente: "Sim, nosso processo de revisão de código faz de você um programador incrível, porque agora você volta a corrigi-lo e é mais fácil".
user1207047

8
@ usuário: a nomeação de métodos / funções é importante, não é necessariamente uma escolha criteriosa. Se você faz um trabalho ruim com a nomeação, isso pode ser irritante para sua equipe. Se você não consegue criar um nome claro, provavelmente não é uma boa função. Você parece ser o cara "novo" e os outros aparentemente têm um método para a loucura que provavelmente já discutiram muitas vezes antes. Assim, a razão para menos comentários. Eu sugiro que você aprenda o que eles querem e tente se conformar, em vez de dar uma cabeçada. Ganhe algum respeito, então você estará em posição de oferecer idéias alternativas que serão atendidas com a mente aberta.
quer

1
@ Usuário: Parece que você precisa de padrões de codificação / design.
Húmido

2
@ Usuário: Tudo o que você pode fazer é tentar trabalhar dentro do sistema e demonstrar que você é um jogador da equipe. Se você fez isso. então, ou sua percepção não está correta, você está lidando com pessoas irracionais, elas percebem que sua atitude é controversa OU é simplesmente uma política desagradável para o escritório. Os únicos que você tem controle são a sua atitude / percepção. Se você está convencido de que não está de alguma forma instigando o problema, não sei por que você ficaria. Vá encontrar um lugar agradável para trabalhar, porque as pessoas se dão bem. Se os mesmos problemas ocorrerem em outro lugar, olhe no espelho.
quer

5

Parece pelos seus comentários que seus colegas estão usando o processo de revisão de código para concordar com uma metodologia ou aprimorar o código. Comecei a fazer análises de código como você e percebo que às vezes discutimos muito sobre coisas que são apenas abordagens ou melhorias de implementação. Isso não é nada ruim, na medida do razoável (300 comentários parecem muitos para mim, que devem parecer um tópico do reddit)

Talvez você precise concordar com algumas decisões de arquitetura sobre o código antes de começar a implementá-lo ou talvez esteja apenas concordando sobre convenções de nomes, padrões e boas práticas para que todos saibam o que é considerado "bom código".

Se você está em conformidade com seus padrões de código, como você diz, e o código funciona como pretendido, não deve haver muitos comentários; portanto, eles estão usando seu código como um fórum ou estão trollando você como parece que está apontando.

Eu tentaria ser crítico comigo mesmo, tentaria participar das conversas e ver o motivo de todos esses comentários e talvez conversar com eles sobre isso de uma maneira construtiva para ver por que eles estão tão descontentes com seu código e se você pode código de uma maneira que deixe todos felizes e o trabalho não fique parado na revisão de código.

Acabei de ler seus últimos comentários, às vezes, quando você não concorda com o código, pode revisá-lo centenas de vezes e propor alterações em todos os lugares que não o deixam feliz, porque a verdadeira razão é que você teria tomado uma decisão arquitetural diferente e você simplesmente não gosta desse código, não importa quantas vezes você o refatorar. Como eu disse acima, talvez você precise concordar com a abordagem do código com antecedência, portanto, ao escrevê-lo, você sabe o que eles esperam dele e, portanto, seu código seria mais razoável para eles.


1
100% concorda com o último parágrafo: você deve discutir o design pretendido antes da implementação. Pelo menos, você está começando com uma estrutura supostamente aceitável. Depois da implementação, pode valer mais uma chance de discutir o design final (não o código). Em seguida, modifique o código para corresponder ao resultado da discussão final sobre o design. Se depois de algumas tentativas e isso não melhorar, isso deve tornar óbvio que a posição é apenas uma má opção e você deve começar a procurar em outro lugar.
quer

4

Pelo que você está dizendo, parece-me que eles podem ter um viés contra os desenvolvedores de php e, portanto, eles estão tentando encontrar tudo o que há de errado com o seu código para provar seu ponto de vista.¹

Com relação à própria revisão de código, acredito que, como você já disse, que uma quantidade tão grande de comentários menores é menos útil do que algumas críticas boas e válidas. E embora eu tenha uma experiência limitada com relação às revisões de código, a técnica a seguir funcionou bem para as equipes em que trabalhei no passado.

  • Primeiro de tudo, um analisador de código estático deve ser usado para identificar a maioria dos problemas antes da revisão do código. Por exemplo: executar seu código no Sonar, no Lint ou em qualquer outro analisador de código bom deve ajudá-lo a se livrar dos problemas menores. Especialmente porque seus revisores podem definir perfis personalizados para garantir tudo, desde colocação de colchetes, espaços em branco, comentários, nomeação adequada de variáveis ​​e muito mais ...
  • Segundo, parece que funciona bem se você dividir os comentários em diferentes categorias. Por exemplo, duas categorias em que um grupo inclui pequenas coisas que você deve observar e aplicar no futuro. E um segundo grupo para os comentários que exigem uma modificação imediata do seu código, o que exigiria outra confirmação e uma revisão subsequente. Obviamente, o número de comentários nesse último grupo deve ser menor.

Além disso, devo dizer que minhas primeiras revisões reais de código também continham mais comentários do que eu esperava inicialmente. No entanto, eu nunca considerei isso ruim. Se você continuar aprendendo com os comentários deles² e estiver disposto a aplicar essas técnicas / melhores práticas recém-aprendidas em seus futuros envios de código, os comentários deverão se tornar menos. Com certeza foi o meu caso ;-)

¹ Na minha experiência, isso acontece muito, como muitos programadores afirmam que php é o mais linguagem de programação mal, tendo os programadores mais inexperientes usá-lo. Eu me distancio dessa afirmação, pois acredito que um ótimo software pode ser escrito em qualquer idioma!

² Supondo que, embora os comentários sejam excessivos, há algum valor neles


Concordo plenamente com o que você disse. É uma experiência de aprendizado e é preciso aprender. No entanto, isso já dura tempo o bastante, a um ponto em que simplesmente não parece ser esse o caso. Ou estou ficando mais burro ou algo mais está acontecendo. Suponho que se cada solicitação pull estiver gerando centenas de comentários, ou você está errado o tempo todo ou há algo mais envolvido aqui que não está coincidindo com o que eles afirmam estar tentando fazer. Ou eles têm que dizer: "Ok, vamos parar e aprender" ou vamos direto ao ponto. Pelo menos é assim que eu estou vendo.
user1207047

1
@ user1207047 Depois de ler suas respostas para as outras respostas, parece-me que você já sabe a resposta para sua própria pergunta .. :-) Parece bastante claro que algo está suspeito com suas análises de código. Talvez seja hora de falar com um superior ou solicitar uma transferência para outra equipe?
Jérôme

3

É comum alguém receber mais de 100 comentários em suas revisões de código rotineiramente? Eu diria que não. É comum que pessoas cuja qualidade de código "deixe muito a desejar" recebam muitos comentários, absolutamente.

No entanto, isso também depende das "regras" do processo de revisão de código. Todo mundo tem suas próprias idéias sobre como algo deveria ter sido feito. Se o seu processo de revisão de código permitir que os comentários tenham o formato "Você deve fazer desta maneira, e não dessa maneira", provavelmente receberá MUITOS comentários, mesmo para o código adequado. Se seu processo se destina a encontrar "defeitos", o número de comentários deve ser muito menor.

Na minha experiência, as revisões que permitem "sugestões" para métodos alternativos são uma perda de tempo. Essas "sugestões" devem ser tratadas uma a uma fora do processo de revisão. As revisões de defeitos são mais úteis, pois levam as pessoas a se concentrarem nos bugs, em vez de "por que você não fez o que eu faria?". Também é mais útil porque não há como negar um bug se alguém encontrar um. Portanto, não há sentimentos feridos, mas provavelmente gratidão.

ATUALIZAÇÃO: Com tudo isso dito, algum código é simplesmente ruim, mesmo sem defeitos. Nesse caso, o comentário da revisão deve ser um único comentário que diz algo parecido. "Este código precisa ser limpo. Adie a revisão até que o código seja discutido com [seu nome aqui]." Nesse caso, a revisão adicional do código deve parar até que o comentário seja retificado.

UPDATE2: @ Usuário: Você discute seu código / design com um deles enquanto o desenvolve, para poder implementar o que eles estão procurando antes de chegar ao ponto de fazê-lo do seu jeito? Você está mudando alguma coisa sobre como está desenvolvendo o código com base nas sugestões deles ou continua pensando que está bem? Você está aprendendo alguma coisa com os comentários deles?

Quando sou o líder de um projeto, é meu trabalho ser responsável por TODOS os produtos de trabalho. Se eu aprovar um produto de trabalho, estou reivindicando que o produto é aceitável. Quero ter uma reputação por criar produtos de qualidade. Portanto, tenho expectativas e não aceitarei menos que satisfatório. Ao mesmo tempo, tento ensinar e explicar os motivos de minhas preferências. Essas preferências podem nem sempre ser ideais (principalmente aos olhos dos outros), mas a maioria dessas preferências vem da experiência. Geralmente uma reação para evitar repetir os ruins. Portanto, existem alguns dos meus "defensores" pessoais que são necessários para obter minha aprovação, independentemente da resposta.

Por outro lado, você precisa aprender as expectativas necessárias para obter seus produtos de trabalho aprovados. Você pode discordar, mas como não parece ter autoridade para dominar, aprenda o que é esperado. Duvido que a equipe esteja tentando fazer você falhar. Como isso os faz parecer ruins também. Nesse sentido, apenas demonstre que você está ansioso para aprender (mesmo que não esteja), aceite o que eles dizem e faça o possível para se adaptar às preferências deles, e você provavelmente os verá recuar um pouco. Talvez encontre o que você pode pelo menos tolerar e veja se eles vão dar um pouco de mãos dadas para ensinar seus caminhos. Quem sabe, no processo, você pode aprender algo que realmente poderia levar suas habilidades para o próximo nível.


Concordo, e você não ouviria nenhum argumento meu por esse motivo. No entanto, o processo não é bem assim. Eles dizem que sim e, na maioria dos casos, parece que apenas pessoas fora desses três grupos estão sob um escrutínio mais pesado que elas. Eles afirmam que outros são maus desenvolvedores, mas são os únicos "desenvolvedores" da equipe.
user1207047

Uma coisa, porém, é que, se você não consegue entender o código, ou o desenvolvedor reinventou a roda em vez de usar um método existente, ou se o método dele tem uma complexidade ciclomática de 50, então esse é definitivamente um caso para um comentário, mesmo se não há bug. Código e duplicação difíceis de ler são uma obrigação, mesmo que não seja um bug. É por isso que nunca hesito em apontar que uma variável é mal nomeada ou que a solução introduz um acoplamento temporal que dificulta a compreensão do código. A dívida técnica deve ser gerenciada.
Laurent Bourgault-Roy

1
@ Laurent: Eu sei o que você está dizendo e de muitas maneiras concorda. No entanto, isso abre uma lata de vermes que tende a bola de neve. Se sua empresa possui os fundos e o cronograma para permitir que as revisões de código ocupem uma parte significativa do esforço, tudo bem (como equipamentos médicos / projetos de aeronaves). Mas a maioria dos projetos não tem o luxo. Portanto, limitar o escopo dos comentários da revisão é muito útil. Para compensar suas preocupações, o trabalho do sw é supervisionar os desenvolvedores e o trabalho deles. Eles devem saber quem monitorar mais de perto e corrigir esses problemas antes da revisão do código.
quer

Teremos que concordar em discordar aqui :). Dívida técnica é algo que você terá que pagar mais cedo ou mais tarde (e quanto mais você espera, mais juros paga). Você não economizará um centavo atrasando a limpeza. Se você não reservar um tempo para limpá-lo agora, a próxima alteração poderá custar o dobro da quantidade de tempo, pois você terá dificuldade em entender o código. Eu trabalho com uma base de código de 8 anos e o desenvolvimento ficou lento devido a problemas de qualidade. Agora temos uma regra oficial de "qualidade interna não é negociável". Eu posso atestar que nos salvou!
Laurent Bourgault-Roy

Reli o seu comentário e percebo que talvez tenhamos uma perspectiva diferente devido à nossa metodologia. Eu trabalho em uma equipe ágil onde não há liderança. Como somos todos iguais e todos responsáveis ​​pela qualidade do código, todos devemos monitorar um ao outro. E a revisão do código é feita a cada 3-4 horas antes de cada integração. Portanto, a limpeza de uma grande solicitação de recebimento é de algumas horas se formos muito nazistas ou se fizermos um refator que impactou uma parte antiga e suja do software. Por isso, vejo o comentário de qualidade de código como um "nada demais".
Laurent Bourgault-Roy

2

Algumas diferenças importantes com o processo de inspeção da equipe:

  • a base de uma inspeção é uma lista de verificação, compilada por toda a equipe.
  • Foco são defeitos (presente e futuro), não estilo por uma questão de estilo.
  • os três inspetores (incluindo o autor) se reúnem para passar por cima dos comentários. Apenas comentários com voto majoritário permanecem.

2

Por 50 LOC 300, os comentários parecem um pouco excessivos e - uau - 3 revisores para cada solicitação de recebimento? Sua empresa deve ter muitos recursos.

Da minha experiência para um processo útil de revisão de código, deve haver algumas regras e / ou diretrizes:

  • Prioridade dos comentários
  • Classificação dos comentários (erro, estilo do código etc.)
  • Arquitetura / design acordados a seguir
  • Estilo de código acordado

Se você não obtiver prioridade dos revisores, pergunte ao gerente de projeto / líder de equipe responsável; a pessoa responsável pelos custos deve ter uma opinião sobre as prioridades.

Se você tiver uma arquitetura definida, um entendimento comum de quais padrões de design você usa em seu projeto e um estilo de código acordado, os comentários da revisão devem ser apenas sobre "problemas reais", como problemas de segurança, bugs não intencionais, casos de canto não cobertos pelo especificado arquitetura etc.

Se sua equipe de desenvolvimento não concordou com "questões de sabor" (por exemplo, se uma variável de membro começar com "m_"), todo revisor forçará você a seguir seu estilo, que é apenas uma perda de tempo / dinheiro.


1

Isso realmente me parece um problema de comunicação. Você espera que seu código não seja ruim o suficiente para merecer 300 comentários. Os revisores parecem pensar que você precisa de muito feedback. Discutir de um modo assíncrono para frente e para trás vai desperdiçar muito tempo. Caramba, escrever 300 comentários é uma tremenda perda de tempo. Se esses nem todos são defeitos, é possível, como novo membro da equipe, que você ainda não conheça o estilo da equipe. Isso é normal e algo que deve ser aprendido para acelerar toda a equipe.

Minha sugestão é economizar tempo. Acelere o feedback. Eu gostaria:

  • Faça mais revisões intermediárias para evitar cometer o mesmo erro e gerar o mesmo comentário 50 vezes
  • Sente-se com um revisor enquanto ele revisa seu código para que você possa falar sobre os problemas à medida que surgem, evitando assim documentar 300 "problemas" que serão apagados no próximo commit
  • Emparelhe com um desses desenvolvedores "reais" por algum tempo enquanto você escreve o código para ver o que eles fariam de diferente

As pessoas podem argumentar contra o emparelhamento porque "levará mais tempo", mas obviamente isso não é um problema aqui.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.