Meus colegas devem revisar o código um do outro no sistema de controle de origem?

Então essa é a minha história: um dos meus colegas usa para revisar todo o código, hospedado no sistema de revisão. Não estou falando de uma revisão adequada das mudanças nas partes às quais ele pertence. Ele assiste o arquivo de código em arquivo, linha a linha. Todo novo arquivo e todo modificado. Eu sinto vontade de ser espionado!

Meu palpite é que, se o código já estava hospedado para controlar o sistema, você deve confiar nele como viável, pelo menos. Minha pergunta é: talvez eu seja paranóico demais e a prática de revisar o código um do outro seja boa?

PS: Somos uma equipe de apenas três desenvolvedores, e temo que, se houver mais de nós, o colega não tenha tempo para revisar todo o código que escreveremos.

Eu diria que sim!

Duas razões rápidas para isso:

1) Se o código estiver em produção, você não pode assumir que ele está correto. Qualquer alteração em outra parte do sistema pode introduzir bugs. Eu acho que é muito importante que o código seja verificado regularmente. Dessa forma, a refatoração é feita regularmente, mantendo o código limpo e "mais" correto (é provável que atualizado seja melhor).

2) Ser capaz de ler o código é uma habilidade muito importante se você for um programador. E é uma habilidade, algo em que você precisa trabalhar. Para qualquer programador que comece a trabalhar em uma base de código existente, se ele não estiver acostumado a ler o código de outras pessoas, haverá uma curva acentuada de aprendizado tentando se atualizar com o que está acontecendo.

Eu não acho que você deva se sentir espionado. Aceite qualquer crítica que alguém lhe faça (se for válida, é claro). E sinta-se à vontade para fazer críticas válidas a outras pessoas. É a maneira como aprendemos. Quando paramos de aprender (ou queremos parar), há grandes problemas.

Se o colega fornecer um feedback bom e construtivo, isso é uma coisa fantástica e você deve agradecer muito.

Isso vai pegar erros que você não pensa quando escrevê-lo. Isso vai resultar em você escrever um código melhor, porque você sabe que os outros vão vê-lo.

Seria bom se toda a equipe fizesse revisões de código em vez de uma pessoa. Idealmente, todos convidariam alguém para revisar seu código após a conclusão. É útil mantê-lo informal (manter os gerentes afastados) e deixar que o revisor fale com você sobre suas descobertas. Idealmente, o revisor apenas fornece feedback e não faz alterações no código, é claro que você pode emparelhá-lo um pouco.

Realmente ajuda ter padrões de codificação para evitar que as discussões de revisão sejam constantemente sobre espaço em branco e estilo de código. Ter alguma análise de código estático em uma máquina de compilação pode ser útil para manter algumas discussões de fora também.

Sobre o aspecto do tempo, a teoria é que você economizará tempo. As falhas posteriores são encontradas, quanto mais caras elas ficam, o princípio falha rapidamente. A revisão de código por pares pode pegar alguns problemas.

Seu colega parece um desenvolvedor diligente, você deve seguir o exemplo dele.

Eu assisto nosso sistema de controle de versão de maneira semelhante. Nossa base de código é muito grande para assistir a todas as linhas, mas tento obter uma sensação de alto nível para a maioria das alterações. Também observo os check-ins com maior probabilidade de ter efeitos colaterais e os reviso linha por linha. Pelo tempo mínimo que passo fazendo isso, a recompensa é enorme. (Observe também: eu não sou o único desenvolvedor da nossa equipe com esse hábito.)

Esse tipo de revisão tende a detectar bugs ou a invocar discussões semanalmente. Isso economiza tempo ao fazer o controle de qualidade. As discussões vão desde as melhores práticas até o design de algoritmos e muito mais. A chave nessa frente é que todo mundo vê isso como construtivo.

Pessoalmente, isso também me dá uma compreensão maior do que está acontecendo em outras partes da base de código em que não toco regularmente. Quando outras pessoas precisam de ajuda, sou capaz de entrar mais rapidamente. Além disso, quando novas idéias aparecem, posso aproveitá-las mais cedo.

Você sente como sendo espionado (!)? Mas da perspectiva do seu colega, eu diria que ele está fazendo as coisas certas para o desenvolvimento de sua carreira. Leia o código de outros e descubra como eles projetam e implementam a lógica. Isso vai lhe render muito!

IMHO Se alguém apontar algo errado no seu código, você deve aceitá-lo e aprender com eles sobre como escrever um bom código

Durante 6-7 meses eu estava fazendo o mesmo. Não para espionar, mas para controlar a qualidade. Cada linha do código de um aplicativo desenvolvido ativamente, comprometida com o repositório central, 2 idiomas principais, mais alguns idiomas, grandes arquivos de criação para 4 plataformas.

É uma prática muito ruim . Algum dia, descobri que não posso capturar tudo devido à robustez. O outro argumento contra isso é a subjetividade - todo mundo pode se enganar.

É melhor quando os desenvolvedores revisam os códigos uns dos outros e há alguém experiente para tomar decisões finais e definir direções.

Revisões de código dentro de uma equipe (usando olho de peixe , cadinho ou outras ferramentas) são extremamente importantes e úteis. a única coisa melhor é a programação direta de pares, para garantir que o código que entra no sistema pela primeira vez seja bem pensado e tenha passado pelo cérebro de mais de uma pessoa.

Isso aconteceu na minha equipe uma vez. Infelizmente, isso resultou em um jogo de culpa. As pessoas esperavam continuamente que outros fizessem o check-in do código e sempre tentavam encontrar algo errado nele e jogavam o jogo da culpa o tempo todo.

Espero que você tenha um público mais maduro.

Essa é uma prática bastante padrão na indústria. As empresas nas quais trabalhei têm diretrizes muito rígidas de revisão de código. Nem mesmo você pode confirmar, a menos que o código tenha sido revisado.

Não se ofenda ou se sinta vigiado. Pense nisso como uma rede de segurança e uma experiência de aprendizado.

Em um trabalho anterior, o desenvolvedor sênior assistiu e revisou todos os check-ins e, frequentemente, recebi excelentes comentários que me ajudaram a me tornar um desenvolvedor melhor.

No meu trabalho atual, assisto a muitos check-ins e, há três dias, encontrei um bug e notifiquei o desenvolvedor.

Esta prática absolutamente vai pegar os bugs e fazer toda a sua equipe melhor, se você abraçá-lo.