O homem é o principal valor de qualquer empresa. O sucesso de tudo depende de como as pessoas se comunicam, de como alcançam seus objetivos juntos e do trabalho em equipe. Aprimorar constantemente habilidades, processos e ferramentas permite que você trabalhe com mais eficiência.
Nós do Market estamos trabalhando para oferecer novos recursos aos nossos usuários o mais rápido possível. Para isso, estudamos constantemente nossos processos e otimizamos todas as etapas da tarefa. Hoje, contaremos aos leitores da Habr sobre a otimização de um deles, a saber, o processo de revisão de código.
Primeiro, você precisa imaginar que tipo de fluxo no desenvolvimento adotamos:
A mesma coisa, apenas ponto por ponto e em palavras:
- O desenvolvedor assume a tarefa.
- Faz ela.
- Preenche o Github e abre o PR.
- Passa em uma revisão de código.
- Coleta um suporte de demonstração e o entrega a um testador.
- O testador verifica o suporte de demonstração.
- A tarefa verificada é coletada na liberação.
- Testando na liberação.
- Layout no prod.
- Teste final em batalha.
Por áreas de responsabilidade, a tarefa é dividida nas seguintes etapas:
1-5 - responsabilidade do desenvolvedor;
6-7 - responsabilidade do testador;
8-10 - responsabilidade no mestre de lançamento.
Então, eles começaram a analisar o que leva mais tempo. Felizmente, existem ferramentas de análise interna. Todos confiaram no que levaria mais tempo, é claro, no próprio processo de desenvolvimento (o status é "In Work") ... e ficou assim. Mas um momento nos surpreendeu mais. A duração média de uma revisão é de duas semanas!
Etapa 1. Analisando PR
Começando a estudar solicitações pull, eles imediatamente enfrentaram um fato muito interessante. Aconteceu que temos um enorme cemitério de solicitações de retirada não fechadas. A maioria dos autores desses PRs não trabalhava mais para a empresa, mas seu legado ainda estava conosco. Quem nunca viu dinossauros, aqui estão eles:
Essas solicitações pull adicionaram ruído e interferiram na análise correta do tempo de revisão do código. Com uma mente calma, nós os fechamos. Resta apenas contar o tempo. Mas ainda estava na área de 2 a 3 dias. Não é bom
Etapa 2: Desmontar com um Browner
O Reviewer é um sistema desenvolvido no Yandex que chama no PR duas pessoas aleatórias com experiência em um código mutável e levando em consideração férias e ausências. A análise dos PRs semanais revelou um grupo de pessoas que constantemente arrasta a revisão do código. Depois de entrevistar colegas, encontramos outro problema em nosso processo. Os colegas reclamaram que recebiam muitos pedidos por dia dos ciumentos e simplesmente não tinham tempo suficiente para o trabalho principal.
Isso não coincidiu com nossos indicadores: um ou dois RP por dia por pessoa. O estudo levou ao Github, onde temos uma equipe separada de revisores. Esta equipe não é atualizada há vários anos. Desde então, o número de funcionários dobrou, mas nenhum dos recém-chegados foi incluído na equipe de revisores. Em outras palavras, metade da equipe não participou da revisão do código! Corrigido esse mal entendido irritante.
Etapa 3. Estendendo ferramentas
Nesta fase, tentamos simplificar a vida já simples, como pensávamos, dos revisores. As seguintes ferramentas estavam no arsenal do front-end:
- verificadores de estilo de código;
- teste de execução;
- várias verificações nerds no próprio PR;
- revisionista;
- alertas no correio e rastreador de tarefas.
Parece que está tudo lá. Pegue e analise!
A primeira coisa que acabou errada: um processo diferente de revisão de código em diferentes repositórios. Unificamos e, ao mesmo tempo, provamos a afixação de etiquetas para uma pesquisa conveniente de PRs através da interface do Github.
A segunda coisa que eles notaram: o correio não é a melhor ferramenta para gerar relatórios rapidamente sobre o status das revisões de código. Muitos, para não se distraírem do trabalho, analisam sua correspondência várias vezes ao dia. Mensageiros são uma questão completamente diferente. A reação às mensagens nos mensageiros é muito maior. E foi decidido conectar o bot ao nosso messenger. O bot envia alertas sobre o status de uma revisão de código para o autor da solicitação de recebimento e incentiva as pessoas a revisar. Muito confortável
Etapa 4. Primeiro SLA
Paralelamente às ações 2 e 3, começamos a trabalhar em estreita colaboração com os funcionários e a explicar que a revisão do código é inseparável da tarefa em si. Eles explicaram que trazer para "Verificado" é de responsabilidade do desenvolvedor. Além disso, a responsabilidade não é apenas dos colegas, mas também dos usuários! Entrega rápida de recursos para vendas - era o que eu queria alcançar. E a equipe foi solidária com o processo de melhoria.
Nesse estágio, nasceu a primeira idéia da revisão de código ideal. Obviamente, todo mundo quer que isso aconteça em 5 minutos, mas isso nem sempre é possível. Considerando que temos uma equipe multirregional (com uma diferença de tempo de quatro horas), concordamos que nosso SLA será de um dia, ou seja, 24 horas Esse SLA foi anunciado a todos os funcionários e, esfregando as mãos, começou a esperar pelos resultados.
Mas a situação não mudou. Nas melhores semanas, metade das solicitações de recebimento cabem em um dia. O resto saiu por ele.
Tivemos um pequeno script que avaliava a revisão do código de tempo no PR. Começamos a culpá-los diariamente por todos os PRs em busca de "ficar para trás". Quase todos os dias havia um pacote desses.
Demorou muito tempo para analisá-los. Na maioria das vezes, o próprio roteiro calculava desonestamente o tempo da revisão. Ele não levou em consideração que alguns PRs foram criados fora do horário de trabalho (sim, algumas pessoas com habilidades corajosas gostam de trabalhar por uma ou duas horas à noite, nos procuram para trabalhar!). Tudo isso nos disse que nossas ferramentas de monitoramento de solicitação de recebimento não são as mais eficazes, pois são desonestas. Eu tenho que encontrar novas ferramentas.
Etapa 5. Rastreador de SLA
A ajuda veio de onde eles não esperaram. Nossos colegas do Tracker anunciaram uma coisa incrível: agora você pode instalar o SLA no próprio Tracker. Além disso, você pode configurá-lo completamente diferente. Um determinado cronômetro é ativado por algum evento na tarefa. Para algum evento, ele pode fazer uma pausa. E pare em algum evento. Sim, é disso que precisamos!
Eles imediatamente entraram em um estudo detalhado da documentação (a propósito, aqui está ) e montaram nossas filas (existem várias, pois existem vários repositórios). Definimos o timer para ativar quando alternamos para o status "Precisa de revisão de código" e terminamos quando ele muda para qualquer outro status, exceto para "Existem comentários" - quando o relógio é interrompido, ou seja, não perdeu tempo.
Também foi legal que o cronômetro levasse em consideração o horário de trabalho e um calendário! Definimos que 9h é atribuído à revisão de código, ou seja, um dia útil. Nesse caso, um alerta é acionado 2h após o início ou se um prazo de nove horas for quebrado. O resultado foi uma espécie de monitoramento honesto. Inicialmente, ligamos o cronômetro para o experimento, coletamos um pacote de bugs e exportamos para o Tracker.
Vale ressaltar que o cronômetro foi ativado apenas para tarefas criadas após a implementação do próprio cronômetro. Portanto, o efeito instantâneo não pôde ser visto. Mas já nesta fase, a dinâmica positiva começou. Tivemos o efeito um mês depois, quando o fluxo de novos ingressos com um temporizador começou a afastar os antigos. Foi notado que o tempo aproximado da revisão do código estava concentrado na área de mensagens de lembrete, ou seja, marca 2h e 9h.
No momento da redação deste artigo, temos 415 tarefas nas quais o cronômetro foi iniciado. Destes, 29 foram além da fronteira de nove horas. Embora, se você olhar mais de perto, também encontrará essas tarefas, cuja revisão de código foi concluída na próxima hora. Se os descartamos também, restam 17 tarefas. E isso é cerca de 4,1%!
O resultado. Samurai constantemente afiando sua espada
Olhando para trás e lembrando todas as nossas ações, uma conclusão pode ser tirada - todos os meios são bons. Todas as nossas etapas levaram ao resultado desejado: mais de 92% das solicitações de recebimento começaram a satisfazer nosso SLA ! Com tarefas cada vez menos rasgadas, a revisão de código é mais rápida. Lentamente, pouco a pouco, 75% da revisão do código começou a caber em 5 horas ! E a dinâmica de melhoria ainda é positiva. Além dos indicadores numéricos, começamos a receber críticas mais positivas dos aliados. Ainda mais satisfeito com o fato de a equipe ter reagido a todo esse processo. Mesmo um processo como a aceleração da revisão de código reuniu ainda mais a equipe. Cada participante começou a entender a responsabilidade que ele tem diante dos outros, pois um código de revisão rápida nos permite beneficiar nossos usuários ainda mais rapidamente.
Claro, 9h não é o sonho final, mas ainda assim o sucesso. Mas nele não pretendemos parar. Continuamos monitorando o processo de revisão de código e resolvendo todos os problemas técnicos e até psicológicos que os funcionários enfrentam para que nosso processo seja o mais produtivo possível e ao mesmo tempo confortável para a equipe.
Perguntas e Respostas. E se ...?
P : E se eu achar que eles estão me observando? Para que serve esse cronômetro?
R : Estamos monitorando não especificamente alguém, mas o processo. Existem dois lados da solicitação de recebimento: o autor e os revisores. Se os revisores arrastarem a verificação, o autor sofrerá. Por outro lado, também é desumano retirar imediatamente os inspetores do trabalho. É necessário encontrar um equilíbrio para que ambos os lados sejam confortáveis. O cronômetro é necessário não para punir alguém, mas para registrar todos os desvios. A maioria desses desvios não ocorre por culpa dos revisores, mas por problemas técnicos. O desafio é resolver esses problemas. Para que outros não os encontrem. Auto-aperfeiçoamento contínuo
P : E se houver PR complexo, mais de 100500 linhas de código e houver "alterar a letra". Onde está a justiça?
A : Sim, isso é verdade. Quando estávamos trabalhando na revisão de código padrão, apenas a levamos ao longo do limite superior, ou seja, A revisão de código de RP complexa deve caber no SLA. Mas, ao mesmo tempo, não temos como objetivo levar todos a esses limites. Sempre somos simpáticos a receber solicitações, nas quais há uma discussão animada e útil, apesar da barra quebrada em um dia.
Temos planos para notas de SLA em storypoints. 1SP - 1h, 3SP - 5h, 5SP - 2d, por exemplo. Felizmente, o Tracker já é capaz disso. Ainda não estamos prontos para isso - ainda temos um longo caminho a percorrer.