Estou trabalhando em uma startup de robótica em uma equipe de cobertura de caminho e, depois de enviar uma solicitação pull, meu código é revisado.
Meu colega de equipe, que está na equipe há mais de um ano, fez alguns comentários ao meu código que sugerem que eu trabalhe muito mais do que acredito ser necessário. Não, eu não sou um desenvolvedor preguiçoso. Eu amo código elegante que tem bons comentários, nomes de variáveis, indentação e lida com os casos corretamente. No entanto, ele tem um tipo diferente de organização em mente com a qual não concordo.
Vou dar um exemplo:
Passei um dia escrevendo casos de teste para alterar um algoritmo de descoberta de transição que eu fiz. Ele sugeriu que eu lidasse com um caso obscuro que é extremamente improvável de acontecer - na verdade, não tenho certeza de que seja possível. O código que eu criei já funciona em todos os nossos casos de teste originais e em alguns novos que encontrei. O código que eu criei já passa de mais de 300 simulações que são executadas todas as noites. No entanto, para lidar com esse caso obscuro, levaria 13 horas que poderiam ser gastas melhor tentando melhorar o desempenho do robô. Para deixar claro, o algoritmo anterior que estávamos usando até agora também não lidou com esse caso obscuro e nem uma vez, nos 40 mil relatórios gerados, já ocorreu. Somos uma startup e precisamos desenvolver o produto.
Eu nunca tive uma revisão de código antes e não tenho certeza se estou sendo muito argumentativo; devo ficar quieto e fazer o que ele diz? Decidi manter a cabeça baixa e apenas fazer a mudança, embora discorde totalmente que foi um bom uso do tempo.
Eu respeito meu colega de trabalho e o reconheço como um programador inteligente. Eu apenas discordo dele em um ponto e não sei como lidar com discordâncias em uma revisão de código.
Eu sinto que a resposta que escolhi atende a este critério de explicar como um desenvolvedor júnior pode lidar com discordâncias em uma revisão de código.