Qual é a melhor maneira para um programador lidar com a revisão de código?

Eu sou bastante novo na revisão de código, mas tenho codificado há anos durante meu doutorado - o que nem sempre faz de você um bom programador!

Se o revisor alterar seu código e passar por ele linha por linha, o que você fará se discordar? Às vezes, você fez a escolha X e o revisor a alterou para Y, e você tinha Y em sua mente, mas decidiu não fazê-lo devido às desvantagens, mas o revisor afirma que essas desvantagens não são importantes. Você deve verbalizar sua discordância, ou simplesmente não, e ouvi-las?

É difícil se você não é bom em aceitar críticas e se o revisor é uma pessoa mais experiente da organização. Não seria bom parecer defensivo demais.

É verdade que parecer defensivo não ajuda; mas então - nenhum dos dois está sendo criticado; portanto, se você acha que isso está acontecendo, deve expressar suas preocupações de que a revisão de código não está ajudando a escrever um código melhor dentro da organização.

O revisor tem a responsabilidade de revisar o código quanto a não conformidade e defeitos reais, e não usá-lo como um meio para escrever seu código da maneira que eles teriam feito. Isso significa que a revisão está lá para revisar como você fez algo e apontar as áreas em que você cometeu um erro (algo que os melhores de nós fazem) ou não entendeu a estrutura, os padrões ou as "razões históricas". como é onde você está.

Portanto, se existem várias maneiras de fazer algo, é necessário que haja um bom motivo para que seu código seja alterado para uma maneira alternativa; caso contrário, é uma rotatividade simplesmente não construtiva que não ajudará.

Lembre-se também de que o revisor também não é perfeito. Eles podem ter uma idéia de que Y é o caminho para fazê-lo e não perceberam que X é melhor. Você deve explicar os motivos pelos quais fez isso da maneira X. O revisor pode concordar com você ou pode dizer por que Y é uma solução melhor - pode haver outros fatores que você não sabe que ele faz.

Em resumo, as revisões são uma maneira de fazer com que os membros da equipe se comuniquem sobre suas alterações de código. Então fale com o revisor sobre isso.

Se ajudar, fale de maneira imparcial, como se você não fosse o autor do código que está sendo revisado. O código pertence à empresa ou equipe, afinal, e a equipe terá que mantê-lo. Você acabou de ser o cara que escreveu, esse não é um fator tão importante quanto muitos acreditam.

Escrever código de computador é um excelente exemplo de tomada de decisões sob incerteza . Sempre existem pressões conflitantes, e como você decide em qualquer questão depende de quais pressões você percebe e qual o tamanho que as considera.

Portanto, quando um revisor discorda da sua decisão, isso significa que ele vê pressões / riscos diferentes dos seus, ou considera alguns deles maiores / menores do que você. Você deve absolutamente falar sobre essas diferenças, porque isso não perpetua os problemas que levaram a discordâncias em primeiro lugar.

Se o seu revisor for mais experiente, a experiência deles poderá dizer-lhes corretamente que esse ou aquele risco não é muito relevante na prática, ou eles podem saber que algum tipo de erro tem um longo histórico de ocorrência em sua organização e vale a pena ter cuidado extra para evitá-lo. Por outro lado, se você achar que sabe algo que o revisor provavelmente não sabe, deve expressá-lo absolutamente; manter silêncio equivale a um abandono do dever de sua parte.

A parte mais importante de lidar com a situação é entender que as críticas às decisões de design nem sempre são críticas à personalidade de alguém. (Nos raros casos em que ela realmente está, você perceberá que em breve, e se você realmente não puder agradar alguém, nada que faça fará alguma diferença; então, onde está o mal em seguir as práticas recomendadas? É melhor encontrar uma posição melhor como o mais rápido possível.) É apenas o resultado de pessoas diferentes terem percepções diferentes dos muitos riscos e recompensas envolvidos no código de computador, e dado o quão complexo é o código de computador moderno, isso é de se esperar. Falar sobre as diferenças ajuda a melhorar o código e a sua cooperação nesse caso e em casos futuros.

As outras respostas já contêm informações muito boas. Eu gostaria de expandir um pouco alguns aspectos que foram sugeridos por gbjbaanb (veja meu comentário na resposta dele).

Na minha experiência, observei diferentes tipos de feedback durante as revisões de código:

1. "Eu sinceramente acredito que isso está errado / abaixo do ideal e que você deve mudar dessa maneira." Normalmente, levo esse tipo de feedback a sério e só vou me opor à mudança sugerida se achar que tenho um ponto forte contra ela.
2. "Acho que sua solução está correta, considere essa alternativa, mas depende de você aceitar ou não a alteração." Também levo esse tipo de feedback a sério: o revisor está sugerindo uma alternativa, mesmo que não tenha uma forte opinião de que sua solução é melhor. Tenho a oportunidade de aprender alguma coisa e aceitarei a mudança, se quiser. Caso contrário, o revisor achará bom se eu mantiver o código de acordo com o meu gosto.
3. "Eu teria feito isso de maneira diferente, então você precisa alterá-lo, ponto final." Ou até "Ah, eu mudei seu código porque ...", a alteração não foi sugerida, já foi confirmada! É dada uma explicação rápida sobre a mudança, com a sugestão de que não há muito tempo para discutir os detalhes, porque precisamos seguir para a próxima tarefa.
4. O revisor sugere pequenas alterações de natureza trivial que não melhoram o código, mas apenas o tornam diferente. Quando solicitado a discutir as alterações sugeridas, o revisor entra em longas discussões sobre detalhes triviais até você desistir por exaustão.

As opções 3, 4 podem aparecer disfarçadas de 1 e 2: "Foi realmente importante fazer da maneira que sugeri". ou "Você pode recusar a alteração se realmente quiser", disse com um tom que de fato significa exatamente o oposto do que está sendo dito. Caso você se oponha a alterações que considere desnecessárias, a propriedade do código compartilhado pode ser usada como justificativa para essa atitude: "O código não pertence a você, pertence à equipe!" Você pode dizer quando a intenção do revisor não é honesta se o revisor não estiver muito aberto para discussão, ficar irritado e tentar empurrar a solução a todo custo. Basicamente, eles já decidiram, e qualquer discussão adicional é apenas uma perda de tempo.

As opções 1 e 2 da OMI são um sinal de um revisor honesto que está tentando ajudar, está tentando ensinar alguma coisa a você, respeitando seu trabalho, e também está aberto para aprender alguma coisa. Nesse cenário, tento não me orgulhar muito quando recebo feedback construtivo de um revisor.

As opções 3, 4 sugerem que existe algum jogo de poder: o importante é fazer do meu jeito ou do seu jeito, não que tentemos encontrar uma boa solução que satisfaça a ambos. Isso pode estar relacionado ao ego do revisor, mas também à impossibilidade de entender qualquer código que não segue seu modo de pensar. Eles normalmente são perturbados por códigos que não lhes parecem familiares e gostariam de impor seu caminho em toda a base de códigos.

Se as situações 3 e 4 acontecem com muita frequência, o trabalho em equipe pode ficar bastante desagradável. Em tal situação, eu consideraria deixar a equipe.

Para resolver seu problema do que fazer quando você discorda ...

Falando nisso, é o caminho a percorrer, como a maioria das pessoas já apontou.

Se você já fez isso, talvez mais de uma vez, uma técnica útil que usamos é se ainda houver discordância em algumas áreas: dizer 'sim, seria bom refatorar isso -

Podemos colocar um ingresso separado para isso?

Um tíquete separado permite que você insira o código, em vez do temido modo de "agitar e nunca seguir em frente" que eu conheço bem em alguns lugares. Isso se encaixa bem com o ágil, fazendo a menor quantidade possível e espalhando a carga. Às vezes, o yagni acaba aplicando. Algumas vezes, o gerente de produto decide que há mais necessidades prementes do que refatorar em termos de valor para o cliente, prazos e recursos.

A revisão de código é provavelmente uma coisa boa em geral, mas, pela minha experiência, é melhor servir como uma ferramenta para desenvolvedores de novas equipes que usam novas diretrizes de codificação ou para corrigir bugs importantes, para reduzir o risco de cometer erros. Se você acredita que conhece melhor que o revisor, pergunte por que a solução que ele propõe é melhor e discuta com suas idéias sobre o assunto. Como ninguém sabe tudo de melhor, a revisão de código deve ou pode ser uma experiência valiosa de aprendizado para ambos.

A revisão de código é uma oportunidade para detectar possíveis problemas e transmitir conhecimentos, tanto para revisores quanto para codificadores.

Como revisor de código, a responsabilidade é destacar possíveis áreas de risco, não conformidade com a prática padrão, melhorias e, geralmente, apenas outro ponto de vista na mesma área de código.

Isso não deve resultar em uma alteração no código sem discutir / entender as decisões dos codificadores no momento do desenvolvimento.

Se o revisor estiver fazendo alterações, ele poderá ter dificuldade em delegar trabalho a outras pessoas, o que é difícil para muitas pessoas inteligentes.

Como codificador que recebe uma revisão, você está sendo protegido de um possível problema quando implantado, tendo a chance de aprender algo novo e a oportunidade de compartilhar seu conhecimento com o revisor.

Independentemente da antiguidade, seu modo de pensar pode apresentar uma solução que simplesmente não ocorre para alguns; portanto, a revisão pode ser sua chance de brilhar apenas fazendo o que você acha que é certo.

Desde que o codificador e o revisor aceitem que eles podem estar errados e que não há problema em estar errado, uma revisão se torna algo que fortalece a equipe porque você trabalha em conjunto na solução.

Parece que você não teve seu código revisado ainda :-)

O objetivo da revisão de código é obter um código de qualidade decente e saber que você possui um código de qualidade decente. Quando o código de um desenvolvedor inexperiente é revisado, ele pode ser usado para ensinar como escrever um código melhor, evitando frustrar esse desenvolvedor.

O revisor nunca deve alterar seu código. Eles podem fazer sugestões mais ou menos fortes sobre como gostariam que seu código fosse alterado e podem decidir se aceitam ou não seu código.

Se a revisão for boa / se eu revisar seu código, provavelmente você receberá alguns comentários sobre como eu escreveria o código que você pode aprender ou ignorar - essas são as coisas em que tenho uma opinião e você é livre para ter uma opinião. opinião diferente. Na minha área, uma boa nomeação de funções, variáveis ​​e assim por diante é considerada importante, para que você possa obter algumas sugestões para melhorar a nomeação. Normalmente, você deve fazer alterações nesse caso (às vezes, encontrando um nome ainda melhor para algo). Às vezes eu vou encontrar bugs. Você os conserta. Às vezes, encontro coisas que considero insetos e estou enganada. Se for difícil ver que o código está correto, você o tornará mais óbvio. Se eu entendi errado, você me diz.

Se eu acho que o design geralmente não está certo, isso deveria ter sido discutido anteriormente. Devemos então pensar se o seu design é bom o suficiente, levando em consideração quanto trabalho está envolvido em uma mudança, ou talvez eu estivesse errado e seu design seja melhor. Deveríamos terminar com um acordo.

Se o revisor e o revisor não concordarem, temos um problema. Porque isso significa que um de nós é incapaz de trabalhar em equipe, ou um de nós é incapaz de distinguir entre um design bom ou ruim, ou ambos. Isso não é necessariamente sua culpa. Infelizmente, existem desenvolvedores que são seniores e sem noção, e isso será um problema para a empresa e para você.

Se isso acontecer, pense muito, muito: você tem algum problema em aceitar críticas bem fundamentadas? Se for esse o caso, você precisa mudar sua atitude. Você é inexperiente demais para ver por que o revisor está certo? Se for esse o caso, não há problema. Confie no revisor e aprenda. Tem certeza de que conhece melhor que o revisor? Aceite a revisão, mas pergunte a um terceiro desenvolvedor confiável sobre sua opinião. Lembre-se de que você pode ter certeza de si mesmo e estar certo, mas também pode ter certeza de si mesmo e estar errado.