Como funciona o processo de Review onde vocês trabalham?

[daniloagostinho]

Bom dia a todos ;)

Gostaria de saber de vocês como funciona o lance de Review, e melhor, como vocês foram aprendendo a lidar com o processo, quando ainda eram novos na empresa. Dicas, exemplos e links para leitura seria bem vindo.

Não sei se fui claro, qualquer dúvida me perguntem. vlw o/

[felipeuntill]

Você quer uma posição sobre a perspectiva do revisor ou revisado?

[wgoulaart]

@felipeuntill Você poderia falar sobre as duas perspectivas ?

[diessica]

Não entendi a pergunta. Você está se referindo a que processo de review? Code review, Sprint review, review de pessoas...?

[felipeuntill]

@Wgoulart Claro que sim, segue a minha opnião que não vale de nada :)

Perspectiva do Avaliador: O processo de review é puro e unicamente aplicado para garantir uma supervisão e padronização do trabalho alheio, este modelo normalmente é recorrente em empresas de cunho financeiro e sigiloso.

Vantagens:

• Possibilidade de orientar novos membros a se adequarem as regras de governança da empresa.
• Garantir a qualidade das entregas.
• Centralizar o conhecimento nos recursos mais experientes.

Desvantagens:

• Time menos produtivo, uma vez que os recursos mais experientes terão de analisar o código alheio.
• Exime os avaliados de responsabilidade sobre as entregas
• Cria atritos entre os avaliadores e avaliados (comum)

Perspectiva do Avaliado: O processo de review é constrangedor, implica demasiada pressão e nem sempre é justo.

Vantagens:

• Exime o recurso de responsabilidade pós aprovação do avaliador.
• Permite que o recurso aprenda os meios corretos e resolva suas inabilidades.
• Dá margem ao recurso para explicar o motivo das decisões tomadas.

Desvantagens:

• Avaliadores demasiadamente críticos (muito comum).
• Estar sujeito aos padrões do avaliador.
• Ter o ambito de intervenção reduzido.

Avaliar alguém exige muita maturidade e vai além do técnico, um avaliador que não sabe ponderar destrói a alto estima de um time e nesta situação o tiro sai pela culatra.
Obviamente existem outros pós e contras mais decidi ressaltar aqueles que certamente vão ocorrer em um time com esta metodologia.

Eu sou totalmente contra a implementação de uma política explicita de avaliação, em ambos os cenários (avaliador / avaliado) prefiro aquele famoso review velado onde periodicamente os mais experientes dão uma olhada para ver como as coisas estão sendo feitas.

[Marlysson]

@felipeuntill Interessante, então todos os devs da equipe tem que serem maduros suficientes para auto-avaliar seu código..

O que acha do Pair-programming de acordo com esse pensamento.. já que duas pessoas ficam no mesmo código implementando-o , e dessa forma pode haver as mesmas divergências do code review.

[felipeuntill]

@Marlysson Exatamente, não sou um agilista mas acredito que não existe nada melhor que a cultura agil para empresas realmente focadas em qualidade, quanto mais vertical a empresa for mais isenção de responsabilidade os subordinados terão.
Enquanto houver alguém pra receber a culpa haverá margem pra erro. Times maduros são o que há!

Nunca ouvi falar de registros de pair programming(sendo levado a sério) fora de empresas com sistemas de missão critica(se o sistema der pau alguém pode morrer).
Nestes cenários os times são muito maduros na utilização da metodologia, se os recursos divergirem em opinião o ideal seria implementar as duas soluções e testar os pontos de qualidade quais proporcionaram a divergência ou exigir a intervenção de um imediato para definir qual o caminho a ser tomado.

Na minha opinião o pair programming em projetos comuns significa rasgar dinheiro e diminuir o poder de produção em 50% mas em situações criticas tem o seu valor.

[Marlysson]

Então pair programming do XP é uma má prática...

Penso as duas partes têm que dosar.. Quem analisa dar criticas construtivas sempre para melhorar, e quem recebe aceitar com o pensamento de melhorar o código.. E não que nunca faz código ruim..e ninguém pode criticar o código dele..

Sempre a dosagem da critica..

[felipeuntill]

Toda metodologia é valida quando bem aplicada, o difícil é achar times que se adequem a elas...

[daniloagostinho]

@diessica de uma maneira bem enxuta Code review, mas também tenho curiosidade de falar sobre os outros tópicos que vc levantou.

[daniloagostinho]

@felipeuntill valeu pelo texto, estou aprendendo sobre essas metodologias e particularmente estou gostando pois consigo aprender mais, por outro lado, no início rola um medo em saber que outra pessoa mais experiente do que vc vai ver seu código.

[daniloagostinho]

@Marlysson

@felipeuntill Interessante, então todos os devs da equipe tem que serem maduros suficientes para auto-avaliar seu código..

Sou novo na área e atualmente, faço code review. É bacana pra ganhar confiança.

[Marlysson]

Em um projeto que participo há code review e é extramamente válido - pode por causa dos participantes também - pois nela as pessoas envolvidas procuram sempre ajudar e propor melhores soluções, se é código mal feito o revisor ( qualquer pessoa da equipe ) sugere algo melhor usando fontes e documentação e não criticando sem falar nada e dizer para mudar tal trecho porque está mal feito.

Um caso de aplicação ótima seria quando um estagiário chegasse na equipe , assim alguém mais experiente ficaria disponível para ajudar em determinado código, assim não pegaria vícios de códigos mal feitos já existente de outras pessoas , o revisor ao lado iria mostrar o caminho de implementar da melhor forma possível e assim o estagiário pegaria mais rápido o ambiente e as melhores práticas.

Tem que sempre haver empatia e boa vontade para funcionar.

[eduardojmatos]

Code-review, pra mim, é uma das coisas mais importantes no processo de desenvolvimento de software. Eis os motivos:

• os comentários servem pra instigar e colocar dúvidas em algumas certezas que acabamos tendo quando estamos enviesados em resolver o problema;
• consequentemente subimos código em produção com mais de um olhar, o que diminui a chance de bugs mais previsíveis:
• o processo de aprendizagem é muito grande quando um dev sugere alterações que fazem sentido ao pull-request;
• pull-requests servem pra criar padrões entre os membros do time. As discussões geram novas ideias ou definem padrões para as próximas features;
• o avaliador aprende a fazer críticas construtivas ao invés de apenas querer provar seu ponto a qualquer custo. Pra isso acontecer é preciso haver maturidade de quem avalia;
• o avaliado precisa estar de coração aberto pra receber críticas também. Desenvolve-se aí o senso de melhora contínua, que é algo que não pode morrer num time de desenvolvimento.

Além disso, mesmo com pair programming, o ideal é que outros avaliem o código e aprendam com o que foi feito em par. Pair programming não é apenas para casos emergenciais, e sim uma prática que pode ser incentivada para haver distribuição de conhecimento, por exemplo. A ideia de que é contra-produtivo colocarmos duas pessoas fazendo a mesma feature é errada, já que duas pessoas pensando na melhor forma de resolver o problema fazem com que a entrega tenha mais qualidade, evitando possíveis refactors ou bugs.

*Eu realmente não gosto de ouvir "recurso" pra denominar uma pessoa. Me soa muito robótico e demonstra um pouco de insensibilidade com as pessoas do time. Me lembra fábricas dos anos 40.

[fernandosouza]

Onde trabalho o code review é constrante. Em times maiores, mais de uma pessoa revisa o código, 2 ao menos. O pull request só é aceito se ao menos duas pessoas concordarem com a implementação. Com essa pratica conseguimos distribuir a reponsabilidade de revisar. Claro que alguns mais experientes em uma parte do código ficam mais a vontade em revisar, porém, outros menos experiêntes ganham conhecimento ao lerem os comentários.

Nesses reviews a qualidade do código e padronização são avalidados.

Como mencioado em outros comentários isso é bastante benéfico para o time, porém, traz alguns contras, como também foi mencionado. Porém, acredito que os ganhos são maiores.

Pessoas sempre tomam mais cuidado antes enviar um pull request, talvez mais do que o necessário, pelo fato do código estar sendo avaliado. Isso pode causar algum delay, mas educa a ter um olhar mais crítico com seu trabalho.

[thulioph]

Primeiro cenário

Aqui no trabalho o code review também é constante. Faço parte de um time com 3 (três) pessoas, onde o que 1 (um) faz, os outros 2 (dois) revisam.

Tentamos seguir a revisão de duas pessoas em todos os pull-requests, mas as vezes não é possível a revisão por todos, aí pelo menos 1 (um) precisa aprovar.

O que é analisado no code-review?

• se as modificações fazem sentido.
• se a lógica aplicada é a melhor para aquela funcionalidade.
• se o código está dentro dos padrões do projeto.

Eu acho interessante esses reviews, principalmente em times remotos, sempre tem um comentário que pode melhorar sua visão sobre o que foi feito, sem falar do feedback construtivo que é bem válido, você aprende muito lendo código alheio.

Segundo cenário

Em projetos pessoais onde trabalho só e não tem um code-review feito por um ser humano, costumo utilizar ferramentas como Codacy ou Code climate que automatizam esse processo e me ajuda a manter a sanidade do projeto.

[kvnol]

@thulioph Meu sonho é trabalhar numa empresa onde haja o code-review e um time que trabalhe dessa forma. No tempo que trabalho como front-end (2 anos) nunca precisei fazer um pull-request (exceto no Github).

[thyagorafaell]

Aqui no @agenciasys uma atividade precisa ter o código aprovado obrigatoriamente por um dev back-end e por um dev front-end para ser liberada - salvo atualizações emergenciais.

O dev desenvolve, passa para o QA e cria um pull request marcado como Work in progress (WIP) no Gitlab, assim se algum outro dev quiser, já pode iniciar a revisão.

Depois que o QA aprova, o WIP é retirado e os demais devs podem fazer a revisão oficial.

O que posso dizer é que isso ajudou muito as equipes, tanto em problemas pequenos, como padronizar nomes de variáveis, quanto problemas grandes, como requisições desnecessárias para a API.

Importante: o papel do code review na empresa é validar padrão e boas práticas de código!
Validação de erro é trabalho de testes automatizados e manuais.

Ainda não utilizamos ferramentas, mas a maioria dos devs já rodam JSHint, PHPMD, etc... durante o desenvolvimento.

[bernardodiasc]

Peer review é uma coisa muito boa. :)

[nncl]

Gostaria de indicar a leitura desse post https://phauer.com/2018/code-review-guidelines/ que fala sobre melhores práticas em um code review, tanto do ponto de vista do revisor quanto do autor. Eu gostei e estou aplicando algumas coisas que tem ajudado no dia-a-dia :)

[wilsonneto-dev]

Na empresa atualmente não temos um revisor fixo, todo PR é revisado por no mínimo 2 colaboradores para se aprovado ser mergeado. Acredito que faz parte da padronização, mas até mais importante que isso garante que o código estará legível e manutenível por qualquer pessoa do squad/equipe.

Ajudando demais este processo

---

Wilson Neto
Linkedin: https://www.linkedin.com/in/wilsonnetobr/