Estar preparado para uma revisão de código como desenvolvedor?
Estou procurando algumas idéias aqui.
Eu li o artigo Como deve revisões de código ser realizada e revisões de código, quais são as vantagens? que foram muito informativos, mas ainda preciso de mais clareza na pergunta abaixo.
Minha pergunta é,
Sendo o desenvolvedor de destino, você pode sugerir algumas práticas recomendadas que um desenvolvedor pode incorporar antes de seu código ser revisado.
Atualmente pratico os seguintes métodos
PPT para um fluxo lógico
Comentários detalhados.
Problema: Embora eu tenha implementado as práticas acima, elas não ajudam na revisão. O problema que enfrentei é que, quando certa lógica é referida, eu continuo pesquisando a implementação e o fluxo e desperdiçando muito tempo no processo e fico irritado com as pessoas.
Eu acho que muitos desenvolvedores estariam passando pelo que eu estou passando também.
c# code-reviews
— Karthik Sreenivasan
Apenas um: não faça coisas estúpidas no seu código.
BEIJO: se o código é simples, seu cérebro é capaz de gerenciar tudo.
Quando você faz uma revisão de código em sua empresa, quem geralmente lidera a reunião? você ou uma pessoa que está revisando seu trabalho? Eu pergunto porque a reunião de revisão de código na IMO não é o lugar para gastar tempo pesquisando pedaços de código, mesmo se você fosse realmente rápido em procurar as coisas.
@DXM Obrigado pela resposta. É o meu TL lidera a reunião.
@Karthik: k, essa parte é boa. Portanto, com base na sua pergunta, você não está perguntando como escrever e produzir código de alta qualidade, pronto para revisão. Em vez disso, sua principal preocupação é a seguinte: "Eu continuo procurando a implementação e o fluxo e desperdiçando muito tempo". Você pode elaborar sobre isso? por que você está pesquisando se TL tem o código à frente e está liderando a reunião?
Portanto, com base nos detalhes fornecidos pelo OP, parece que a pergunta é: "como aprendo meu próprio código para que, quando solicitado a encontrar X ou explicar Y, eu possa responder rapidamente".
Poucas sugestões que consigo pensar:
Ao codificar, você precisa reservar um tempo para aprender e entender seu próprio código. Isso pode ser o que seu TL está tentando transmitir para você em poucas palavras. Sendo um TL no projeto atual, fiz várias revisões de código nos últimos 11 meses e noto a prática de alguns desenvolvedores de procurar por "código de exemplo" em nossa própria base de código ou em outro local (google , etc ...) e copie / cole. Pessoalmente, não aguento mais porque, enquanto o código deles passa nos testes simples de unidade, eles não entendem o que está realmente fazendo, por isso nunca garantimos que não exista ' • algum caso limite ou uma condição de falha esperada que poderia ocorrer.
Como corolário da declaração anterior, se você precisar copiar / colar, tente copiar / colar apenas o código que você escreveu anteriormente e que você entende. Certamente não há problema em "emprestar" a idéia de outras pessoas, mas, nesse caso, reescreva sua linha de código por linha porque, enquanto você a escreve, você terá uma melhor compreensão do que ela faz. Se você estiver usando APIs externas, mesmo se tiver um exemplo que use essa API, reserve alguns minutos para encontrar uma referência e aprender como ela funciona. Não pense apenas que, se funcionou antes, também funcionará na sua situação.
Leia e aprenda a amar o princípio DRY . Muitas vezes o que você é tentado a copiar / colar pode ser colocado em um local comum (função separada, classe separada, biblioteca separada ...)
Leia e aprenda a amar os princípios do SOLID e, enquanto faz isso, revise o KISS, que já foi mencionado pelo mouviciel. Esses princípios são todos orientados para a produção de código muito conciso, limpo e modular. Se você tiver grandes classes e grandes funções, será muito mais difícil encontrar coisas e, além disso, tentar explicar o que o código faz. Por outro lado, se você seguir (ou pelo menos tentar seguir) o SRP e tornar cada classe / função responsável por apenas uma coisa, seu código será pequeno e muito legível.
Pegue uma cópia do Clean Code . Livro muito bom. Ele fala sobre escrever códigos que são auto-explicativos e fáceis de ler, manter e estender. Se você pratica a escrita de código fácil de ler, não deve ter problemas ao ler seu próprio código nas revisões de código. E essa é a parte engraçada: eu pedi às pessoas que leiam seu próprio código ou simplesmente me digam o que as variáveis ​​estavam representando e elas não puderam responder, mesmo que tenham escrito esse código (novas classes, não herdadas) há apenas uma semana. . Uma boa nomeação é um longo caminho.
Se, após toda a simplificação e refatoração, você ainda tiver uma função que precisa executar algum tipo de algoritmo que não é muito aparente, reserve um tempo e escreva um bloco de comentários nessa função que explica o algoritmo. Não só será útil quando você precisar modificar essa função daqui a dois meses, mas se você for emboscado em uma revisão de código, poderá ler simplesmente o que escreveu.
Se depois de todos os itens acima, você ainda estiver com problemas? você é novo na equipe e pediu para trabalhar com muito código herdado? Nesse caso, pode ser que o seu TL esteja sendo um A $$ e você possa ser proativo, solicitando a ele antes da reunião que seja fácil e não perca o tempo de todos os envolvidos. Quando novas pessoas ingressam em uma equipe, a TL precisa ter paciência suficiente, porque trabalhar em uma nova plataforma, novo produto, novas pessoas, novo ambiente exige muita concentração de uma nova pessoa, e essa pessoa estará perdendo alguns detalhes no começo. Funciona como projetado e seu TL deve aceitar isso.
Se, após todos os itens acima, você ainda sentir que tem análises de código horríveis. Fale com o seu TL. Às vezes, as pessoas se sentem mal por causa da natureza das reuniões de revisão de código, quando, na verdade, a TL está perfeitamente feliz com você. Quando faço revisões de código, meu objetivo é destacar o que precisa ser alterado, entender as mudanças e seguir em frente. Muitas vezes não tenho tempo para ser educado e algumas pessoas ficam na defensiva e tentam responder a cada um dos meus comentários. Nessas situações, a reunião de revisão de código é interrompida, por isso tento interrompê-los e seguir em frente. Geralmente, depois da reunião, eu conversava com os novos caras para garantir que eles entendessem o processo e que não fosse nada pessoal. Após poucas revisões de código, as pessoas geralmente ficam muito mais confortáveis.
+1 em "não copie e cole o código que você não entende". Isso é intolerável! Também +1 em "fale com o seu TL"
@DXM Sua capacidade de entender as nuances mais refinadas da pergunta foi muito profissional, sem mencionar que sua resposta é muito informativa e descritiva. Mente = queimado!
@DXM Da sua referência "Por outro lado, se você seguir (ou pelo menos tentar seguir) o SRP e tornar cada classe / função responsável por apenas uma coisa, seu código será pequeno e muito legível." Você pode me informar o que significa * SRP ? * Vi outro post interessante sobre clareza de código aqui .
@KarthikSreenivasan - No contexto, é uma prática em que um método ou classe é responsável por uma coisa. Por exemplo, um método que adiciona números também não deve retornar a média. A pesquisa simples encontrou isso: en.wikipedia.org/wiki/Single_responsibility_principle
As práticas variam, mas na minha experiência:
Não faça nada de especial no código. É natural aumentar o código um pouco mais quando você descobrir que ele será revisado, e não há mal algum em corrigir coisas óbvias, como erros de ortografia e outras coisas. Mas não inclua muitos comentários detalhados ou altere o código apenas porque está programado para revisão.
O código é preparado e distribuído aos revisores com bastante antecedência. Isso geralmente é feito por terceiros neutros, provavelmente o facilitador da revisão de código. Se impresso, o código deve ser pequeno o suficiente para que as linhas não sejam quebradas com muita frequência, mas grande o suficiente para que todos possam ler com facilidade. Imprima em formato paisagem, se for o que for preciso.
O código deve ser impresso ou exibido com números de linha . De preferência, o número deve continuar de um arquivo para o próximo. É muito mais fácil se referir à "linha 3502" do que à "linha 238 de foo.c", e ter os números permite que todos falem sobre linhas específicas sem perder tempo encontrando essas linhas.
Definitivamente, deveria haver um facilitador . Seu trabalho é impedir que a revisão fique atolada em minúcias, impedir que ela se torne pessoal ou aquecida e limitar estritamente a duração da revisão.
Como autor, você deve revisar o código antes da reunião de revisão. Anote as alterações que você sugeriria se esse fosse o código de outra pessoa. Isso estimula sua memória de código que você pode não ter visto em alguns dias e também ajuda a praticar a observação de seu próprio código com um olhar crítico. Depois de passar por algumas revisões, como revisor e como autor, você descobrirá que suas próprias anotações serão mais próximas das do restante do grupo.
Esteja preparado para tomar notas durante a revisão. Essa não deve ser sua principal preocupação - alguém deve estar registrando os itens de ação com os quais o grupo concorda, para que você possa se concentrar em explicar o código e ouvir os comentários. Mas haverá momentos em que você recebe um feedback valioso que não é um item de ação e deve corrigir essas coisas à medida que elas ocorrem.
Lembre-se de que não é pessoal. É difícil evitar se sentir (e agir) na defensiva durante uma revisão. Não há problema em explicar seu código se você acha que foi mal interpretado, mas mais do que qualquer outra coisa, tente apenas ouvir.
Eu acrescentaria uma coisa: "linha 3502" seria uma grande marca vermelha. Ter arquivos muito longos é definitivamente uma coisa ruim.
@VJo: Caleb sugeriu que os números de linha continuassem nos arquivos, então a linha 3502 é na verdade a linha 238 de foo.c.
— Heinzi #
Não concordo com o número da linha que continua nos arquivos. Para mim, isso é apenas confuso e embaraçoso. Se houver algum problema, eles precisam ser rastreados por módulo (classe, arquivo, talvez até método) de qualquer maneira. Além disso, durante uma revisão de código, você não deve revisar um sistema inteiro, mas um subsistema ou mesmo algumas classes ou arquivos, portanto, não deve ser muito difícil rastrear onde estão as alterações.
@ThomasOwens Os números das linhas são exclusivamente para o propósito de descrever facilmente um local no código revisado durante a revisão. É mais rápido e menos propenso a erros do que usar o "arquivo foo.c, linha 123", e o OP pergunta especificamente sobre gastar menos tempo localizando o código. Concorde que os problemas devem ser rastreados por arquivo. No IME, as revisões tendem a abranger um grupo de classes, talvez duas grandes ou uma dúzia de pequenas. São necessárias mais de 3500 linhas para revisar de uma só vez - estava apenas tentando enfatizar que os números continuam de um arquivo para o outro.
Se você é organizado, isso não deve importar. Para mim, sinto que isso me atrasaria. Eu estive envolvido com revisões de código e sempre imprimo os arquivos, grampo-os por classe / arquivo e os leio e os anoto. Se alguém quiser me dizer onde procurar, quero um par de nome de arquivo / número de linha - isso tornaria muito mais fácil para mim, principalmente porque meu IDE imprime o nome do arquivo no cabeçalho / rodapé de cada página e imprimo o números de linha por arquivo.
Mais uma coisa a acrescentar às outras respostas: para facilitar os revisores de código formais , realize MUITAS análises de código informais ! Por exemplo:
"Ei, Bob, posso mostrar como eu implementei a função foo ()?" "Ei, Steve, você pode dar uma olhada neste diagrama de aulas e me dizer o que pensa?" "Ei, Karen, você pode me ajudar a pensar nesse problema? Acho que tenho uma boa solução, mas poderia usar sua ajuda ..."
Faça disso um hábito regular. Ao envolver seus colegas de trabalho no início do processo de design, você:
Obtenha novas idéias sobre o problema
Melhore sua capacidade de explicar o problema / solução em questão
Economize tempo mais tarde nas revisões formais de código
+1 na criação de equipes e Melhore sua capacidade de explicar o problema. Essa é realmente uma ótima idéia!