Como o código "Tendência de meta" deve ser tratado por um gerente de desenvolvimento?

Primeiro, permita-me cunhar um termo:

definição de objetivos de código: Fazendo check-out do código pela manhã e revisando silenciosamente todas as alterações feitas pelos outros desenvolvedores no dia anterior, arquivo por arquivo (especialmente os arquivos de código que você desenvolveu originalmente) e corrigindo formatação, lógica, renomeando variáveis, refatorando métodos longos, etc., e depois confirmar as alterações no VCS.

Essa prática tende a ter alguns prós e contras que eu identifiquei:

• Pro : a qualidade / legibilidade / consistência do código é frequentemente mantida
• Pro : alguns erros foram corrigidos devido ao outro desenvolvedor não estar muito familiarizado com o código original.
• Contras : Muitas vezes é uma perda de tempo do desenvolvedor de objetivos.
• Con : Ocasionalmente introduz bugs que causam raiva de puxar os cabelos por desenvolvedores que pensaram ter escrito código sem bugs no dia anterior.
• Contras : Outros desenvolvedores se agravam com o excesso de nitpicking e começam a não gostar de contribuir para o código do concurso.

Isenção de responsabilidade: para ser justo, não sou realmente um gerente de desenvolvimento, sou o desenvolvedor que está realmente cumprindo o "objetivo".

Em minha defesa, acho que estou fazendo isso por um bom motivo (para manter nossa base de códigos extremamente grande uma máquina bem lubrificada), mas estou muito preocupada que isso também esteja criando uma atmosfera negativa. Também estou definitivamente preocupado que meu gerente precise resolver o problema.

Então, se você fosse o gerente, como lidaria com esse problema?

ATUALIZAÇÃO: Não quero que isso seja muito localizado, mas alguns perguntaram, então talvez algum plano de fundo seja esclarecedor. Fui designado para um projeto gigante (200K LoC) há três anos e apenas recentemente (1 ano atrás) foram adicionados desenvolvedores adicionais ao projeto, alguns dos quais não estão familiarizados com a arquitetura, outros que ainda estão aprendendo o idioma (C #). Geralmente, tenho que responder pela estabilidade geral do produto e fico particularmente nervoso quando mudanças são surpreendentemente feitas nas principais partes da arquitetura da base de código. Esse hábito surgiu porque, no começo, eu estava otimista com as contribuições de outros desenvolvedores, mas eles cometeram muitos erros que causaram problemas sérios que não seriam descobertos até semanas depois, onde o dedo seria apontado para mim por escrever um código instável. Muitas vezes estes "

Parece que o que você está fazendo é basicamente equivalente a uma revisão de código, exceto que, em vez de fornecer feedback ao desenvolvedor, você está fazendo todas as alterações sugeridas em uma revisão de código. Você certamente seria melhor fazer uma revisão de código real em que você (ou outra pessoa) forneça feedback ao desenvolvedor original sobre problemas de qualidade de código e bugs óbvios e peça ao desenvolvedor original para corrigi-los. Isso mantém a qualidade do código, mas também ajuda o desenvolvedor a se familiarizar com o código original e suas armadilhas e ajuda a melhorar futuras alterações no código. Além disso, ele não tem a desvantagem de causar "raiva de puxar o cabelo" quando um bug é introduzido silenciosamente ou faz com que outros desenvolvedores pensem que estão sendo comentados pelas costas.

Para ser franco, IMHO, esta é uma ideia terrível.

Eu esperaria que o moral caísse na sarjeta, se ainda não o fez.

Para ser justo com você, você reconhece isso.

Revisões de código de pares são boas, ele coloca o ônus nos desenvolvedores em um único nível, em vez de ser um cenário "eles versus nós". (onde eles são gerentes / leads).

Pode haver alguns desenvolvedores que talvez você precise observar mais do que outros, mas é ridículo forçar todo o código a passar por você primeiro.

E, apesar de quão bom você pensa que é, haverá momentos em que você está errado, ou "nit picking" e isso só tornará as coisas ainda piores.

Se eu fosse o gerente, para resolver este problema:

• Analise os padrões e práticas de código com a equipe, entregue-lhes uma cópia dos padrões de codificação
• Código de revisão por pares regularmente para reforçar os padrões e práticas a serem seguidas
• Aplique nitpicking / formatação com uma ferramenta de automação para que os desenvolvedores sejam obrigados a seguir os padrões
• Livre-se de colegas de equipe ruins que se recusem a seguir os padrões
• Pare de ser o goleiro

Suas intenções são boas, mas a implementação é terrível e, como outros já apontaram, causará falta de moral e insatisfação entre os membros da equipe.

Se o projeto nunca teve um padrão para começar, tente facilitar o novo padrão em etapas, em vez de apenas apertar um botão.

Bad juju.

Não sou gerente de desenvolvimento, mas, se fosse, não gostaria que nenhum dos meus desenvolvedores tomasse código que não faz parte de um defeito ou recurso atribuído a eles. Período. Se você encontrar um problema com o código de outra pessoa, leve-o à atenção do (s) desenvolvedor (es) responsável (s), mas não mergulhe e corrija-o sozinho, especialmente se você não tiver coordenado com o outro desenvolvedor ( s) primeiro.

As tarefas de limpeza devem ser executadas somente após uma revisão formal do código pela equipe e somente pelo (s) desenvolvedor (es) a quem essas tarefas foram atribuídas.

A iniciativa é boa em geral, mas às vezes pode morder sua bunda. Se você introduzir algum bug no código que estava funcionando, poderá rapidamente desejar ter escolhido uma carreira diferente.