Como funciona o processo de Review onde vocês trabalham? #480
Replies: 20 comments
-
Você quer uma posição sobre a perspectiva do revisor ou revisado? |
Beta Was this translation helpful? Give feedback.
-
@felipeuntill Você poderia falar sobre as duas perspectivas ? |
Beta Was this translation helpful? Give feedback.
-
Não entendi a pergunta. Você está se referindo a que processo de review? Code review, Sprint review, review de pessoas...? |
Beta Was this translation helpful? Give feedback.
-
@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:
Desvantagens:
Perspectiva do Avaliado: O processo de review é constrangedor, implica demasiada pressão e nem sempre é justo. Vantagens:
Desvantagens:
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. 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. |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
@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. 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). 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. |
Beta Was this translation helpful? Give feedback.
-
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.. |
Beta Was this translation helpful? Give feedback.
-
Toda metodologia é valida quando bem aplicada, o difícil é achar times que se adequem a elas... |
Beta Was this translation helpful? Give feedback.
-
@diessica de uma maneira bem enxuta Code review, mas também tenho curiosidade de falar sobre os outros tópicos que vc levantou. |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
Sou novo na área e atualmente, faço code review. É bacana pra ganhar confiança. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Code-review, pra mim, é uma das coisas mais importantes no processo de desenvolvimento de software. Eis os motivos:
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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?
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. |
Beta Was this translation helpful? Give feedback.
-
@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). |
Beta Was this translation helpful? Give feedback.
-
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! Ainda não utilizamos ferramentas, mas a maioria dos devs já rodam JSHint, PHPMD, etc... durante o desenvolvimento. |
Beta Was this translation helpful? Give feedback.
-
Peer review é uma coisa muito boa. :) |
Beta Was this translation helpful? Give feedback.
-
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 :) |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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/
Beta Was this translation helpful? Give feedback.
All reactions