Sempre que perceber algo assim, insira um novo ticket no seu sistema de rastreamento de problemas.
Crie o hábito de usar o rastreador de problemas como uma ferramenta primária para comunicar coisas desse tipo, porque a partir daí será fácil escolher, avaliar e priorizar seus colegas seniores / líder / gerente / quem for responsável por rastrear os problemas em seu projeto .
Use a ferramenta certa para o trabalho. Eu sempre faço isso e recomendo fortemente que você faça o mesmo.
Como exemplo, aqui está um ticket que criei cerca de um mês atrás. Após a conclusão de um recurso específico, descobri que o código se tornou substancialmente mais complicado do que era antes, mas não posso corrigi-lo no prazo estabelecido para a implementação do recurso.
(Os nomes dos recursos, tickets e código usados no rastreador real são obscurecidos, mas o texto é copiado como está).
Resumo: simplifique o design envolvendoParticularPieceOfCode
Descrição:
No curso da implementação, de acordo com o TICKET-12345, o código que envolve o uso ParticularPieceOfCode
acumulou um pouco de complicação e tornou-se bastante difícil de ler, entender e manter (veja o exemplo de trecho de código abaixo).
Encontre uma maneira de simplificá-lo.
Um exemplo de código que seria desejável reprojetar pode ser encontrado em ClassName#methodName
:
<a piece of code like one behind the right door here:>
FWIW, meu conselho se aplica independentemente do "nível" que você é.
Eu tenho usado no seu nível atual ("mais baixo") e estou usando agora que meu nível está muito longe de "mais baixo" e tenho um "dizer" satisfatório, como você chama, e eu vou usá-lo sempre não importa o quê.
Pense nisso, sem nível, não importa quanta autoridade você tenha, simplesmente não pode haver melhor maneira.
Se você "disser" ei, temos um problema , é apenas um ruído de ar. E mesmo se seu chefe / líder concordar e disser que você está certo, temos um problema , isso não muda nada - é apenas um ruído de ar novamente, e não pode ser mais nada.
- Você pode pensar que ter a sua opinião por escrito (por exemplo, por e-mail) seria melhor, mas se você pensar nisso, realmente não é. Se o seu projeto tiver atividades substanciais de correio, o que foi escrito será perdido e esquecido um mês depois.
Use a ferramenta certa para o trabalho. Para o trabalho que você descreve, o rastreador de problemas é exatamente a ferramenta certa.
Você percebe o problema, entra no sistema projetado para rastrear esses dados e cuida do resto, da melhor maneira possível - simplesmente porque foi projetado para isso :
pacote de software de computador que gerencia e mantém listas de problemas , conforme necessário por uma organização ... comumente usado ... para criar, atualizar e resolver problemas relatados de clientes, ou mesmo problemas relatados por outros funcionários dessa organização ... O sistema é semelhante a um " rastreador de erros " e, freqüentemente, uma empresa de software venderá os dois, e alguns rastreadores podem ser usados como um sistema de rastreamento de problemas e vice-versa. O uso consistente de um problema ou sistema de rastreamento de bugs é considerado uma das "características de uma boa equipe de software" 1 ...
Quaisquer outros meios que você queira escolher para se comunicar, ter um ticket no rastreador apenas facilitará as coisas para você.
Mesmo se você preferir mexer no ar , dizer "Eu gostaria de discutir o TICKET-54321 ..." é um ponto de partida mais sólido do que "Ouça, eu gostaria de falar sobre algum código com o qual lidei há um tempo atrás. ... "E você pode passar com segurança as referências ao ticket pelo correio: mesmo se o correio for perdido, o problema ainda estará presente no rastreador, com todos os detalhes que você deseja informar.