Revisão de PR e relações pessoas - O dilema de PRs

É difícil dizer com certeza se seu colega está barrando suas mudanças propositalmente ou se ele está apenas seguindo as políticas da empresa ou as orientações da equipe. Pode ser que ele tenha suas próprias razões para preferir o código da forma como estava e talvez não tenha expressado adequadamente essas razões para você.

No entanto, é importante lembrar que, como especialista na empresa, você possui conhecimento e experiência valiosos, e suas sugestões de melhoria podem trazer benefícios significativos para a equipe e o projeto. Seria útil conversar diretamente com seu colega e tentar entender suas preocupações ou reservas sobre suas alterações. Uma comunicação clara e aberta é essencial para resolver qualquer mal-entendido ou conflito, você precisa obrigatóriamente como especialista ter a inteligência emocional de não se frustrar sem saber todos os motivos, por isso vá até ele e pergunte abertamente e liquide o problema em vez de sofrer sem saber exatemente o que ocorre e pior inventando mil hipóteses e sofrendo com cada uma.

Em relação à PR em si, é geralmente aceitável incluir mudanças de nomenclatura e ordenação de parâmetros, desde que essas mudanças estejam dentro do escopo da tarefa e não alterem o comportamento do código existente. Se suas alterações foram rejeitadas, pode ser útil perguntar ao seu colega especificamente por que elas foram consideradas desnecessárias ou fora de escopo.

Lembre-se também de que, nem sempre é possível implementar todas as melhorias de uma vez. A equipe pode ter prioridades diferentes ou prazos e restrições específicos. É importante ter flexibilidade e estar aberto a compromissos, desde que eles não comprometam a qualidade e a estabilidade do código.

No geral, a chave para resolver essa situação é a comunicação aberta e respeitosa com seu colega e tentar entender os motivos por trás das decisões dele.

Cada caso é um caso, não trabalho na sua empresa e não sei como é a cultura no geral, mas se tem algo que aprendi é que tudo se resolve na conversa. Chama o mano pra trocar uma idéia, pra entender o porque não dá pra andar com as alterações, e como você pode fazer para andar com elas. As vezes de fato um sistema é complicado, e não é "saudável" refatorar muito código de uma vez, mas aplicar uma mudança/melhoria por vez, de vez em quando sempre é válido, ainda mais quando o processo de deploy não é custoso (por exemplo, quando a empresa não possui uma politica de CAB/COR).

99% dos problemas no trabalho são resolvidos com comunicação assertiva; um mal entendido ou algo do tipo sempre pode acontecer, então se comunicar é a melhor saída. Se você mesmo depois de todos esses esforços se encontrar na mesma situação, tente escalar! Sempre vai ter alguém acima de você numa hierarquia dentro da empresa, e geralmente essas pessoas sempre querem gerar resultados. Use isso ao seu favor.

Seria esse meu colega alguem que estaria barrando propositalmente as minha mudanças? Esta ele sendo tóxico no ambiente de trabalho? Até onde a PR pode conter essas mudancas simples de nomeclaturar e ordenação de parametros?

Não temos como saber (não pelo menos com as informações passadas, pois só temos o seu lado da história). A empresa ou equipe onde vc trabalha tem essas regras bem definidas? Ou fica a critério de cada um?

Tem empresas que possuem regras bem rígidas quanto ao que pode ser alterado. Já vi lugar que não podia nem remover um espaço sobrando no final da linha, se não fosse código relacionado à funcionalidade que vc mexeu.

Em compensação, já vi lugares menos rígidos, mas que a galera acabava abusando e criando o caos. Por exemplo, um resolveu mudar a formatação de todo o código, ou seja, o commit mudava todos os arquivos. Outros ficavam brigando porque um preferia TAB e o outro espaços para indentar. A cada commit deles, ficava muito difícil saber o que de fato foi alterado e o que era somente a mudança do caractere (fora os conflitos).

Enfim, o ideal é ter as regras bem claras. Se não tem e cada um faz do seu jeito, alguém tem que intermediar a conversa e tentar juntar todo mundo pra discutir e definir um padrão.

Se vai aceitar A ou B, e em quais casos, vai depender dessa conversa. O que não pode é cada um ter um critério, senão vira bagunça.

Quero enfatizar que apoio tudo o que o macnator disse! Não sei o cargo do seu colega, porém se vocês estiverem lado a lado é importante você reportar esses casos para um superior. Desenvolver uma funcionalidade ou realizar uma correção não se trata apenas de adicionar o que é necessário e dane-se o resto. Você PODE e é EXTREMAMENTE NECESSÁRIO a manutenção do código, pois realmente isso pode vir a causar mais custos ou até mesmo churn de clientes para a empresa. Como você é um especialista e imagino que saiba bastante sobre performance, se agarre nisso e mostre que suas opiniões são válidas e podem sim ser aceitas.