Como fazer com que os desenvolvedores façam análises de código em tempo hábil

A empresa em que trabalho exige que todo o código seja revisado por outros desenvolvedores antes de ser confirmado. Os membros da minha equipe geralmente ficam frustrados porque os outros desenvolvedores estão muito ocupados em codificar para fazer uma revisão, especialmente se for muito longo. Como você incentiva outros desenvolvedores a fazer análises oportunas de código?

(Usamos o git-svn para podermos continuar a codificar enquanto aguardamos uma revisão. No entanto, ainda acho frustrante ter que esperar muito tempo para confirmar meu código.)

Veja como o Facebook faz isso com seu próprio aplicativo, chamado phabricator: http://phabricator.org/

Eles se comprometem basicamente por problema e, para cada problema, o código é mostrado, que deve ser revisado por alguém. O código não entra em seu repositório principal até que o revisor tenha dito que não há problema em fazê-lo.

Eu acho que isso torna mais divertido.

Além disso, talvez um código deva ser atribuído a duas pessoas: uma que o faz e outra que o revisa.

Embora talvez seus colegas de equipe não acreditem nessa crítica.

Pessoalmente, na falta de revisores, usei testes de unidade para funções de nível inferior e "o teste do zelador" para todo o resto: o teste do zelador é chamado dessa maneira, porque até o zelador deve ser capaz de entender seu código.

Geralmente removia algumas partes menores, como colchetes de escopo de bloco / função, notações de visibilidade, às vezes até tipos, e a mostrava a gerentes, especialistas em domínio, parceiros, quem solicitava o código: "é isso que você deseja?"

Além disso, ir para lá pessoalmente e não sair até que a revisão seja feita ajuda.

Ou, caso você não esteja bem com a equipe, ou eles não estejam bem com você, "se você pode 'mudar de empresa, mudar de empresa" ...

Vou basear isso em algumas suposições:

1. Todo mundo parece querer escrever código (caso contrário, você tem pessoas que precisam ir.).
2. Todo mundo quer que seu próprio código seja registrado.

Permita que apenas aqueles que concluam suas revisões tenham seu código verificado.

Talvez um certo período de tempo possa ser dedicado às revisões de código, na esperança de evitar o problema de ser interrompido.

O objetivo deve ser o check-in do código de qualidade. Você não deseja punir / forçar as revisões a um ponto em que todo mundo apenas concede uma aprovação de "carimbo de borracha".

Se você tem níveis diferentes (sr., Sr. Etc), a promoção e a manutenção de um título devem depender do desempenho do seu trabalho.

Em alguns empregadores anteriores, trocávamos quem fazia a Revisão do Código diariamente. Geralmente, três pessoas compartilham um dia de RC e cada RC deve ser assinado por dois dos revisores. Isso garantiu que, quando fosse o seu dia, você soubesse que o RC era esperado de você, independentemente de seus outros projetos. Então, a cada cinco dias, mais ou menos, era a sua vez e você poderia ajustar suas tarefas de desenvolvimento de acordo.

Atualmente, temos um líder de equipe que faz um CR superficial no código de sua equipe. Dependendo de qual área do aplicativo foi atualizada, após a conclusão do CR, ele pode ser enviado para a Equipe de Revisão Global, onde verificamos itens que têm impacto global no (s) aplicativo (s), em vez de itens que são relacionado a um único recurso. Quando há uma grande revisão a ser feita, geralmente a dividimos entre algumas pessoas, para que ninguém tenha que lidar com alterações em um número ridículo de arquivos.

Dito isso, só estamos revendo o código que foi confirmado na ramificação / variante atual do desenvolvedor. O código deve passar pela Revisão de Código, Revisão Global, Revisão de Banco de Dados e Revisão da UI (cada uma conforme necessário) antes de poder ser promovido para o próximo ambiente (por exemplo, Alfa).

Por fim, concordamos com um SLA sobre a rapidez com que as análises são feitas. Quase nada fica na fila por mais de 48 horas e a maioria das revisões é feita em menos de 24 horas.

A empresa em que trabalho exige que todo o código seja revisado por outros desenvolvedores antes de ser confirmado. Os membros da minha equipe costumam ficar frustrados ...

A menos que você esteja executando um software de missão crítica ou patches críticos para o código candidato à liberação de produção, não há motivos convincentes para seguir rigidamente o tipo específico de revisão de código.

• ^{A ideia por trás dos requisitos da sua empresa parece razoável superficialmente (código 100% revisado), mas os meios que eles decidiram usar são contraproducentes - porque, como você ressalta, isso leva os desenvolvedores a ficarem frustrados.}

Seguindo seu caminho, eu gostaria de apontar primeiro para o gerenciamento que as revisões de código pós-confirmação são consideradas tão respeitáveis ​​quanto as pré-confirmação . Esses termos são pesquisáveis ​​na Web - se necessário, encontre referências para fazer backup disso. Não é necessário necessariamente revisões pré-confirmadas para obter um código 100% revisado.

Com base no exposto, a seguir sugiro que abandonem a atitude de microgerenciamento e permitam que os desenvolvedores tentem da maneira que lhes parecer mais conveniente. As revisões antes ou depois da confirmação são deixadas para os programadores escolherem. Se a empresa conhece melhor que os programadores, por que eles não escrevem o código?

Você tem vários problemas a resolver - precisa conquistar corações e mentes e garantir que haja tempo disponível para revisões de código.

A segunda parte é provavelmente mais fácil - você concorda (coletivamente e isso deve incluir o gerenciamento) de que a primeira coisa que um desenvolvedor faz todas as manhãs são as resenhas de códigos - isso é simples, compreensível, eficaz e oferece a você uma boa e clara idéia para derrotar as pessoas. se eles não cumprirem. Melhor, você não está interrompendo nada, não está pedindo para que parem de trabalhar no código deles, não está pedindo para as pessoas colocarem algo em sua lista de tarefas ...

A primeira parte é o problema real - os participantes no processo de revisão precisam vê-lo como tendo valor; caso contrário, nunca farão uma revisão de código (que é percebida como não tendo valor) quando poderiam escrever código ou corrigir bugs (que é certamente mais importante ...?).

Se você puder juntar os dois - primeiro, garantindo que todos acreditem (ou entendam) que há valor nas análises de código -, no mais básico, deve significar menos bugs, o que significa mais código novo, geralmente mais divertido - e depois organizar novamente coisas para que haja um espaço livre na programação para que as revisões de código sejam feitas, então espero que boas coisas aconteçam ... isso se tornará parte da cultura.

Uma vez que faz parte da cultura, pode não ser mais necessário dizer "a primeira coisa todos os dias" - mas tendo dito que acho que se encaixa bem no padrão em que provavelmente se quer que um desenvolvedor trabalhe.

Na maioria das empresas em que trabalhei, você tem três dias para concluir uma revisão. Não é aceitável não fazer as revisões. Faz parte do seu trabalho. Se você não fizer análises decentes a tempo, isso afetará sua avaliação de desempenho. E sim, as revisões sempre parecem acontecer nos momentos mais inoportunos. Pena, aprenda a incluir o tempo de revisão em suas estimativas. De qualquer forma, se a gerência realmente acredita que as revisões são importantes (isto é, exige que todo o código seja revisado), então adotaria uma política semelhante. Além disso, se as pessoas não concluírem a revisão no prazo estipulado, isso será aceito pelo material.

Considere usar uma ferramenta como o Painel de Revisão . É muito útil, especialmente para críticas longas.

Você pode fazer o upload dos seus diffs e aguardar até que um revisor termine a revisão. Se você tiver revisões abertas que o impedem de continuar seu trabalho, você pode denunciá-lo durante as reuniões diárias (sua equipe deseja que novos recursos sejam verificados para que possam ser testados o mais rápido possível, não é?).

Alguns pontos a acrescentar que não estão nas outras respostas.

O código a ser revisado deve ser verificado

• para que você esteja revendo uma versão estável.
• Pode estar no ramo principal de desenvolvimento se uma versão estiver longe o suficiente
• Pode estar no ramo se houver uma boa razão para não poluir os principais

As tarefas de bloqueio têm prioridade; portanto, as revisões de código devem ter prioridade sobre outros trabalhos (mas tentando não interromper o fluxo). Como desenvolvedor, você deve desejar que outras pessoas revisem seu código (como você pretende melhorar). Nesse conhecimento, você deve executar revisões para outras pessoas prontamente.

As perguntas mais difíceis são quando e como fazer revisões de código bem.

Uma regra que funcionou para nós no momento é que o código compartilhado deve ser revisado, pois tem um impacto mais amplo, enquanto que no código de um único aplicativo (especialmente porque estamos usando o desenvolvimento orientado a testes) é menos importante.