Por Cameron Aird
A maioria das equipes de desenvolvimento e DevOps reconhece as revisões de check-in como uma parte necessária de seu fluxo de trabalho. No entanto, abordar essas revisões de commit incorretamente pode torná-las mais difíceis, mais demoradas e menos recompensadoras do que o necessário.
Aqui estão cinco ideias para colocar em prática para que as revisões de commit sejam recompensadas para sua equipe.
Habilite o teste contínuo
Os revisores consideram as avaliações enfadonhas? Eles provavelmente estão reagindo ao excesso de investimento em aspectos rotineiros da revisão. Por exemplo, alguém precisa torcer os braços das pessoas para que os revisores testem o novo código de maneira adequada? Esse problema tem solução, se chama testes contínuos (CT).
Combine políticas e ferramentas para que cada revisão chegue com seus próprios testes integrados, que a própria plataforma CT executa e exibe. Dessa forma, todas as revisões começam com os testes de rotina já concluídos. Se alguns dos testes não forem de rotina, tanto melhor. Com testes bem elaborados, os revisores humanos podem se concentrar nos aspectos complicados, deixando toda a confirmação de regressão habitual para a CT. O resultado: testes mais confiáveis e menos tédio.
Automatizar verificações
Não são apenas os testes de unidade convencionais que podem ser automatizados dessa forma. Sua equipe tem problemas recorrentes com, digamos, o uso de guias? Alguém envia arquivos de origem separados por CRLFs semelhantes a DOS no lugar de novas linhas do Unix, ou vice-versa? Não dependa de humanos sujeitos a erros para detectar essas anomalias. Escreva um script de uma dúzia de linhas que faça essas verificações estilísticas automaticamente.
Qualquer aspecto da revisão – os parênteses estão pontuados corretamente? Todas as variáveis não utilizadas foram removidas? Os valores das cores são escolhidos em uma paleta aprovada? – evitado pelos revisores é um candidato a script como um detector automático.
Dê passos menores
As avaliações esgotam os revisores? Faça mais delas – mas faça-as menores.
Aqui está um exemplo: Um único requisito funcional provavelmente envolve várias etapas de implementação distintas, incluindo novos testes, definições de classe refatoradas, talvez um layout de interface do usuário atualizado e alterações em alguns nomes de função para “abrir espaço” para a nova funcionalidade. O que para os analistas de negócios parece um aprimoramento envolve quase 200 linhas de código-fonte espalhadas por 13 arquivos-fonte. Isso é difícil de revisar!
Suponha, entretanto, que o commit seja reescrito como cinco rodadas de commits. Os três primeiros deixam a funcionalidade invariável; eles são apenas refatorações para criar uma base melhor para o aprimoramento real. O quarto e o quinto commits para esta sequência de exemplo se concentram estritamente na implementação e no teste da nova funcionalidade e estão claramente separados de tudo o que o aplicativo existente faz. Nesse ponto, cada uma das cinco rodadas de commits envolve não mais do que quatro dúzias de linhas de mudança de origem – apenas algumas telas – e é fácil de entender. As cinco rodadas de revisões menores tornam-se mais fáceis de digerir do que uma grande revisão original.
A decomposição das avaliações em unidades menores, dessa forma, recompensa a prática. O objetivo é tornar cada revisão tão fácil de entender que os revisores possam ver clara e imediatamente a exatidão do commit.
Etapas menores desse tipo também ajudam a localizar quaisquer confusões. Quando um implementador entende mal os requisitos, mas tem boa técnica para escrever várias revisões pequenas, geralmente o mal-entendido afeta apenas uma minoria das revisões. Essa minoria de commits confusos, mas pequenos, é corrigida mais prontamente, enquanto a maioria dos commits corretos e pequenos pode ser revisada e aprovada sem alterações.
Eventualmente, cada revisão deve levar apenas alguns minutos para digitalizar e compreender em alto nível, algo que pode ser praticado pelo menos algumas vezes por dia. Mesmo quando um commit é profundo e leva horas para ser totalmente entendido, deve ser possível visualizá-lo em relativo isolamento de todas as mudanças de nome, empacotamento e outras distrações de “manutenção” que muitas vezes obscurecem as ideias reais por trás de uma implementação.
Compare isso com o antipadrão muito frequente em que os commits são tão grandes que os revisores acham difícil e os adiam a perder de vista. Essa combinação de atitude e escopo leva todos ao fracasso.
Assincronizar
Outro aspecto de tornar as revisões mais fáceis é liberá-las de um calendário fixo. À medida que o mundo do desenvolvimento virtualiza cada vez mais para o trabalho remoto, permita que a maioria dos revisores estabeleça suas próprias agendas para a maioria das revisões.
Especialmente com commits pequenos e atômicos, não há nenhuma vantagem em ter todos revisando ao mesmo tempo e no mesmo lugar. Em vez disso, treine os revisores para reverter as avaliações de maneira rápida, mas conveniente.
Resolver conflitos
Para obter melhores resultados, envie solicitações de revisão sem conflitos.
É comum em algumas equipes um desenvolvedor iniciar uma implementação, finalizá-la em boa forma, enviar um branch proposto ou commit ou solicitação (dependendo do fluxo de trabalho local), começar a receber revisões … e só então perceber que o commit está em conflito com o chefe atual ou mestre ou autoridade.
Poupe trabalho extra a todos e resolva tais conflitos assim que forem detectados. A alternativa – onde as aprovações são coletadas, os conflitos são resolvidos e, em seguida, uma nova revisão da resolução do conflito é necessária – apenas cria um trabalho extra. Providencie para que os revisores vejam as solicitações sem conflito.
A maioria dos sistemas de controle de versão, integração contínua (CI) ou controle de origem podem ser configurados para detectar conflitos. Com essa configuração, pode se tornar um motivo de orgulho manter as solicitações livres de conflitos e em boa forma para os revisores.
Conclusão
As revisões têm maior probabilidade de sucesso quando os revisores esperam que elas sejam de fato um sucesso. As poucas mudanças acima ajudarão a cultivar essa atitude positiva.
Fonte: Ranorex/Idera
