O que devo fazer ao aguardar uma revisão?

Antes de fazer minha pergunta, devo explicar a situação.

Estou trabalhando para uma empresa como engenheiro de software júnior. Um dos idosos sempre me para quando eu termino o meu desenvolvimento e quero me comprometer.

Ele sempre quer que eu espere que ele revise. Tudo bem, porque geralmente ele encontra alguns erros e faz algumas otimizações.

No entanto, devo confirmar meu código antes do prazo. Quando terminei, ligo para ele e digo que está terminado. Ele geralmente chega atrasado. Então, meu código também está atrasado.

Minha pergunta é: o que devo fazer? Devo esperar por uma revisão?

EDIT: adição à pergunta. Estou curioso sobre mais uma questão.

Eu quero ser livre ao codificar. Como eu poderia ganhar a confiança pela liberdade de desenvolvimento?

_{Algumas explicações: eu conversei com ele sobre isso. Mas não ajudou. Já usamos um rastreador de problemas, mas não há nenhuma tarefa para revisões. Existem apenas tarefas de desenvolvimento e teste.}

Então, meu código também está atrasado.

Não, não é o seu código, é o seu e do idoso. Você está trabalhando em equipe, tem uma responsabilidade compartilhada e, quando vocês dois perdem um prazo, a culpa é de vocês dois. Portanto, verifique se quem faz os prazos percebe isso. Se essa pessoa também considerar isso um problema, certamente conversará com vocês dois - isso pode ajudar mais do que uma única conversa com seu colega de trabalho.

E para o seu EDIT:

Eu quero ser livre ao codificar. Como eu poderia ganhar a confiança pela liberdade de desenvolvimento?

A revisão do código é um dos mais importantes economizadores de qualidade. É praticamente impossível escrever um código excelente sem um segundo par de olhos, mesmo quando você tem mais de 20 anos de experiência em programação. Portanto, em uma boa equipe, o código de todos deve ser constantemente revisado - o código do seu sénior e o seu código. Isso não tem nada a ver com desconfiança contra você pessoalmente (ou, pelo menos, não deveria). Contanto que você acredite que a "codificação livre" sem um segundo par de olhos é melhor, você ainda é um programador júnior.

Em uma boa equipe, você deve ter uma fila de tarefas de desenvolvimento atribuídas a você em um rastreador de problemas .

Dessa forma, enquanto você espera por um revisor, você pode ( deve ) trabalhar na próxima tarefa que espera nessa fila. Depois de se acostumar a trabalhar dessa maneira, isso abrirá uma oportunidade para que suas alterações sejam revisadas em "lotes", diminuindo assim os atrasos.

• ^{Se você não tiver essa "fila", discuta isso com seu gerente ou, melhor ainda, com o revisor. Se sua equipe não possui um rastreador de problemas razoavelmente conveniente para coisas assim, considere estudar os quadros de empregos ou as oportunidades internas de trabalho da empresa para encontrar uma equipe melhor (você também pode discutir isso com o gerente / revisor, mas não espera que isso ajude - falta de um bom rastreador de problemas geralmente é um sintoma de algo gravemente quebrado em uma equipe).}

Eu quero ser livre ao codificar. Como eu poderia ganhar a confiança pela liberdade de desenvolvimento?

Para descobrir, você precisa primeiro entender o objetivo das revisões de código. Você mencionou confiança - essa é uma boa "aproximação", mas não totalmente precisa.

• ^{Por exemplo, em um dos meus projetos recentes, o desenvolvimento foi realizado por uma mini equipe minha e de meu colega. Confiamos e nos respeitamos mutuamente - mas, apesar disso, revisamos 100% do código. Estávamos fazendo isso porque isso nos permitiu encontrar e corrigir rapidamente alguns bugs e, o que também é muito importante, porque as revisões não demoraram muito tempo e não bloquearam nosso trabalho.}

Veja bem, seria mais preciso pensar nas revisões de código em termos de esforços investidos para evitar certos riscos . Em uma boa equipe, você pode esperar um tipo de entendimento compartilhado de como "equilibrar adequadamente" isso. Observe que não existe um equilíbrio adequado para um tamanho único, depende muito de um projeto - o risco e o impacto de bugs em um software de missão crítica diferem naturalmente daquele em um aplicativo não crítico.

Usando o seu exemplo, você pode esperar "bloquear revisões", desde que os esforços investidos pelo revisor sejam justificados por encontrar bugs e melhorias que devem ser corrigidas antes de confirmar seu código.

Eles provavelmente esperam que, com a prática e as orientações recebidas nas revisões, você melhore a codificação, para que eles encontrem cada vez menos problemas que valem a pena corrigir antes da confirmação. Assim que descobrirem que seu código ficou "seguro o suficiente" para permitir "medidas de prevenção de riscos" menos complicadas, você pode esperar que o processo mude, por exemplo, para revisar após a confirmação .

Dependendo de um projeto, em algum momento seu código pode ser considerado seguro o suficiente para ignorar as revisões, deixando a descoberta dos bugs para os testadores (mas isso não necessariamente acontecerá, veja meu exemplo acima).

Existem várias respostas possíveis aqui, dependendo exatamente de qual é o seu problema.

• Se sua maior preocupação é "Estou perdendo prazos", não. Vocês dois estão perdendo prazos juntos. Você pode (com confiança) dizer: "Termino em uma hora; podemos fazer a revisão do código?" Isso pode ser o suficiente. Você pode completar o código no dia anterior ao prazo? Isso deve ser um buffer abundante. Você está completando seu código, com bastante buffer entre "revise" e o prazo? Se o último, não é nem uma falha conjunta, eu diria.

• O código deve sempre ser revisado. Não posso fazer nada sem (pelo menos) um segundo par de olhos e outro ser humano dizendo "tudo bem". Isso vale para projetos nos quais eu sou o programador principal e também para projetos em que normalmente não contribuo (mas consegui encontrar um bug que me impactou e que eu quero corrigir). No entanto, o rigor de uma revisão é muito baseado na confiança. Se eu confiar que a pessoa que deseja enviar o código conhece bem a base de código, não serei tão rigoroso como se não soubesse quão bem a pessoa conhece a base de código.

Minha pergunta é: o que devo fazer? Devo esperar por uma revisão?

Não, você não deve apenas ficar ocioso. Há sempre algo para fazer. Como Gnat sugeriu , deve haver uma fila de tarefas. Ou, de uma maneira ágil de desenvolvimento, lista de tarefas atribuídas a você para a iteração atual. Se você ficar ocioso, há algo errado na organização da sua empresa ou da sua equipe.

Outra coisa é: seu supervisor sênior está realmente verificando cada pedaço de código que você faz? Se sim, você também pode fazer programação emparelhada.

Eu quero ser livre ao codificar. Como eu poderia ganhar a confiança pela liberdade de desenvolvimento?

Existem alguns regulamentos que exigem que o senior verifique o trabalho do junior (acho que a iso médica 62304 exige isso). Se assim for, você não pode fazer nada.

O que você pode mudar é pedir ao senior que não verifique literalmente tudo. Você pode definir o processo de revisão de código e verificar coisas importantes.

Use o git localmente, confirme suas alterações em uma ramificação e inicie na tarefa 2 enquanto espera. Então, quando ele terminar, você poderá mesclar as alterações dele no seu novo trabalho e já estará à frente da próxima tarefa.

Faça isso o suficiente e, em breve, ele poderá revisar duas ou mais coisas de uma só vez. Escolha coisas em que é improvável que as linhas se sobreponham para minimizar conflitos.

Uma solução para isso pode ser envolver o desenvolvedor sênior muito mais cedo através da Pair Programming em seu trabalho.

Página da Wikipedia sobre Programação em pares

A vantagem mais óbvia para você seria que a revisão ocorra muito mais cedo no processo, para que você não precise mais esperar pelo desenvolvedor sênior.

Além disso, você poderá ver os processos e técnicas de pensamento do desenvolvedor sênior enquanto ele escreve o código e aprender com isso.

Você pode ter o problema do desenvolvedor sênior, talvez não queira emparelhar com você. Isso pode ser difícil, mas minha própria experiência é que tanto os desenvolvedores seniores quanto os juniores ganham muita experiência com a programação em pares.

Também costuma haver a preocupação de que você terá metade da produtividade, com dois desenvolvedores trabalhando no mesmo trabalho. É difícil medir qual é o efeito na produtividade com a Programação em pares, a resposta mais comum que ouvi é que a produtividade das equipes que fazem pares e daquelas que não fazem é a mesma coisa. (Se alguém tiver alguma boa pesquisa sobre isso, eu adoraria ouvir sobre isso)

Não é uma resposta completa por si só, apenas uma adição às excelentes respostas acima ...

Você revisa seu próprio código antes de fazer o check-in? Sei que não é o mais divertido, mas tento fazer isso na maioria das vezes. Faço programação profissional há 20 anos (34 no total), mas geralmente encontro pelo menos um bug e / ou uma coisa que esqueci, ou pelo menos poderia melhorar. Concordo com o sentimento de que seu código deve sempre ser revisado e que um segundo par de olhos é melhor que um par. Mas mesmo o mesmo par revisando o código duas vezes é melhor que uma vez.

Você escreve testes de unidade para o seu código? Além dos testes de unidade, também tenho um pequeno script de shell que procura os erros mais comuns que eu pessoalmente cometi. Algumas delas são gramática e ortografia em inglês, outras são problemas de codificação que o compilador não captura. Eu o executo antes de verificar grandes alterações como uma cortesia para todos os que estão a jusante.

Normalmente, deixo as pessoas escreverem seu código e, ocasionalmente, reclamarem mais tarde, mas não reviso todos os check-in. Certa vez, trabalhei com um programador júnior, cujo código eu tinha que revisar e geralmente desfazer porque eles cometeram muitos erros. Isso não terminou bem. Você está em uma profissão em que geralmente é mais importante fazê-lo corretamente do que no prazo. Se você aprender com seus erros, irá longe.

Se você puder minimizar o número de alterações que seu revisor precisa fazer no seu código, você maximizará a chance de que eles confiem em você para escrever um código que nem sempre precisa ser revisado com tanto cuidado. Se você deseja se livrar das críticas, assuma a responsabilidade máxima pela qualidade de sua própria produção.

Algumas ou todas essas sugestões podem ser feitas enquanto se espera que outra pessoa reveja seu código.

Eu acho que executar revisões manuais de código é ... bem ... meio anos 80. Bem, talvez os anos 90.

Nesta era moderna de integração contínua e sistemas de revisão de código on-line, você realmente não deseja reter nenhum commit de código apenas porque tem medo de que "isso possa interromper o controle de origem".

Vamos lá pessoal. É para isso que serve o changeset (ou listas de alterações). Você faz com que seus programadores alimentem a fome do seu sistema de controle de origem. Em seguida, seu servidor de integração contínua entra em ação com uma série de compilações direcionadas (bem, espero que seja apenas a compilação diária, mas alguns de nós se empolgam). Se algo der errado, você coloca o troféu do código de macaco (geralmente um brinquedo de plástico que alguém encontrou em uma caixa de cereal Lucky Charms) na mesa do agressor e reverte a lista de alterações. Bem, alguns sistemas de integração contínua emitem automaticamente notificações por email / IM / área de trabalho para todos da equipe / departamento / organização que a compilação está quebrada, juntamente com um hiperlink bacana para mostrar a todos que quebraram exatamente a compilação em que arquivo ou teste. Agora é o programador infeliz '

Enquanto esse processo é executado, o sistema de revisão de código entra em ação (novamente, acionado pelo check-in). Uma lista de membros qualificados da equipe é notificada da confirmação da lista de alterações no controle de origem, uma revisão é iniciada no sistema de revisão e todos começam a fazer anotações nas alterações na lista de alterações. Espero que todos digam "LGTM". Se o programador for inteligente, ele se lembrará de orar / subornar / ocultar. Se houver problemas sérios, os revisores podem criar um defeito (que pode ser conectado ao sistema de rastreamento de bugs) ou até exigir que a lista de alterações seja restaurada. Sim, mudanças retrocedidas prejudicam não apenas o ego, mas a mente, isso é verdade. É um bom tempero para os desenvolvedores juniores, para reintegrar as listas de alterações rejeitadas.

Se seu ambiente de desenvolvimento não possui um IC ou um sistema de revisão de código, você deve investigar seriamente. Alguns links podem ajudá-lo:

Atlassian Crucible
JetBrains TeamCity
reitveld
Cruise Control

Se você deseja obter um servidor de IC, também deve pensar seriamente nas estruturas de teste de unidade. Se você é um desenvolvedor de C #, procure algo como o NUnit para começar.

Você diz a ele com antecedência quando seu código estará pronto, não no momento em que estiver pronto. Você deve poder determinar que aprox. uma semana à frente. Isso lhe dá tempo para preparar e planejar a revisão, para que ela se encaixe nos seus planejamentos.