Como digo (com tato) ao meu gerente de projeto ou desenvolvedor líder que a base de código do projeto precisa de um trabalho sério?

Acabei de ingressar em uma equipe de desenvolvimento (relativamente) pequena que trabalha em um projeto há vários meses, se não um ano. Como a maioria dos desenvolvedores que ingressou em um projeto, passei meus primeiros dias revisando a base de código do projeto.

O projeto (um aplicativo interno de linha de negócios de médio a grande porte do ASP.NET WebForms) é, por falta de um termo mais descritivo, um desastre. Existem três problemas imediatamente visíveis nos padrões de codificação:

1. O padrão é muito flexível. Ele descreve mais o que não fazer (não use a notação húngara, etc.) do que o que fazer.
2. O padrão nem sempre é seguido. Existem inconsistências com a formatação do código em todos os lugares .
3. O padrão não segue as diretrizes de estilo da Microsoft. Na minha opinião, não vale a pena desviar-se das diretrizes estabelecidas pelo desenvolvedor da estrutura e pelo maior colaborador da especificação da linguagem.

Quanto ao ponto 3, talvez isso me incomoda mais, porque dediquei um tempo para obter meu MCPD com foco em aplicativos da Web (especificamente, ASP.NET). Também sou o único Microsoft Certified Professional da equipe. Por causa do que aprendi em toda a minha escolaridade, auto-ensino e aprendizagem no trabalho (incluindo minha preparação para os exames de certificação), também vi várias instâncias no código do projeto em que as coisas simplesmente não são feitas no melhor maneira.

Estou nessa equipe há apenas uma semana, mas vejo tantos problemas com a base de código que imagino que passarei mais tempo lutando com o que já está escrito para fazer as coisas "do jeito deles" do que eu faria se estivesse. trabalhando em um projeto que, por exemplo, seguiu padrões de codificação, padrões de arquitetura e melhores práticas mais amplamente aceitos. Isso me leva à minha pergunta:

Devo (e em caso afirmativo, como devo) propor ao meu gerente de projeto e à equipe liderar que o projeto precise ser reformado em grande parte?

Eu não quero entrar no escritório deles, agitando meus certificados MCTS e MCPD, dizendo que a base de código do projeto deles é uma porcaria. Mas eu também não quero ter que ficar em silêncio e ter de escrever código kludgey sobre seu código kludgey, porque eu realmente quero software de qualidade de gravação e eu quero que o produto final seja estável e de fácil manutenção.

Você poderia gastar seu tempo discutindo seu caso; ou você pode gastar seu tempo limpando à medida que avança.

Pegar Código Limpo e ágeis Princípios de Desenvolvimento de Software, Padrões e Práticas e aplicar o que aprendeu lá como você trabalha no sistema. Eventualmente, as pessoas perceberão (para melhor ou para pior).

Editar Também confira Trabalhando Efetivamente com Código Legado

Pelo que você descreve, parece que os problemas são principalmente sobre não seguir os padrões de codificação e os problemas de nomeação. Isso não é um desastre , de longe. Para uma comparação, isso é um desastre, de verdade.

Talvez você esteja acostumado e exija altos padrões? Nesse caso, qualquer desvio da perfeição pode ser considerado um fracasso. Essa é uma armadilha fácil de cair quando suas demandas são altas, mas é importante manter a perspectiva das coisas.

Sugiro que você fale sobre isso como uma melhoria e ajude a equipe a atualizar suas diretrizes e treiná-las para começar a usá-las de verdade. Eu realmente gosto de usar uma Definição de Concluído como uma referência de qualidade e criar uma é uma grande exorcização de equipe por si só. Mas não acho que você deva fazer muito mais do que isso, pelo menos não como um novo membro da equipe.

Definitivamente, não vá acenar com o seu MCSD, as pessoas vão rir de você com toda a franqueza, os alunos da EM são bons de se ter, mas não são de forma alguma uma qualificação profissional!

Entre para uma nova equipe e procure oportunidades para sugerir mudanças à medida que avança.

Espere até chegar ao terreno antes de descartar um código de equipe.

Você pode considerar que o problema é você. Nenhuma das três coisas que você mencionou é digna de uma reformulação completa de um aplicativo. São apenas detalhes detalhados.

Lembre-se de que o objetivo do aplicativo não é ter um código bonito, é resolver um problema de negócios. Certamente, é bom ter um código consistente e que siga um bom padrão, mas a falta dele não é motivo para descartar toda a base de código. Só porque o motor é oleoso não significa que ele precisa ser reconstruído.

Olha, todo mundo odeia todas as bases de código que não escreveram. De fato, se você esperar três anos e analisar seu próprio código, também o odiará e achará necessário uma reescrita completa. A verdade é que não. A menos que você considere que, gastando meses em tornar o código esteticamente agradável para você, em vez de criar recursos para agregar valor comercial, você provavelmente está latindo na árvore errada.

Nada diz que você precisa escrever código kludgy apenas porque pode haver alguns na base de código. E nada diz que o código é kludgy apenas porque não adere ao seu estilo de animal de estimação. Basta refatorar à medida que avança nas partes em que trabalha e escrever um bom código ao trabalhar em coisas novas.

Não há problema em se preocupar com essas coisas, mas se você é novo na equipe, não mexa no barco ainda, até que tenha construído alguma credibilidade com elas.

Parece que você escolheu três coisas (relativamente) menores para se preocupar. Há outras coisas com as quais me preocupo mais:

• O código está bem documentado?
• O código segue as especificações / documentos de design?
• O código funciona?
• É fácil entender o que o código faz?
• Você está pensando em enviar grandes partes dessa base de código para TheDailyWTF?

Você está lá há uma semana? Não tenho certeza de que você já saiba o suficiente para fazer propostas ao gerente de projetos. Mesmo se você suspeitar que o código e as práticas dessa equipe são "ruins", a melhor maneira de influenciar essas coisas ao longo do tempo é ganhar gradualmente sua confiança e respeito. Entrar em um projeto e depois de uma semana dizendo à equipe que seu código precisa ser reescrito não é uma boa maneira de ganhar confiança e respeito.

Nos seus primeiros meses, concentre-se em dar um exemplo melhor e em fazer perguntas sobre o motivo de terem feito as coisas de determinadas maneiras. Tenha cuidado com o seu tom ao fazer essas perguntas. Se você se apresentar como o novato "sabe tudo", ninguém ouvirá suas opiniões mais tarde, quando você estiver realmente em posição de influenciar a maneira como as coisas são feitas.

Com o tempo, se o seu código realmente for "melhor", os outros desenvolvedores verão isso. Eles começarão a chegar até você como um recurso para ajudá-los a consertar os deles e, depois, pedir seu conselho sobre como eles devem fazer as coisas. Nesse ponto, você estará em uma ótima posição para contar à equipe (e à gerência) suas opiniões sobre padrões de codificação e similares. Quanto tempo leva esse processo varia de acordo com a organização. Poderia ser apenas algumas semanas em um ambiente muito adaptável, ou meses a anos em uma cultura mais estóica. Crie sua influência uma pessoa de cada vez.

Você nunca entrará em um novo trabalho, onde achará que a base de código é perfeita e tudo foi feito da maneira "certa". Aprenda a aceitar isso. Tudo o que você pode fazer com o código legado é refatorar e avançar pouco a pouco. Algumas coisas que você não deseja refatorar até ter uma compreensão maior do motivo pelo qual eles fizeram o que fizeram. Além disso, ninguém nos negócios pagará para você consertar o código de trabalho; portanto, você precisaria argumentar sobre os motivos pelos quais ele precisa funcionar antes de acelerar e gastar o tempo. É melhor esperar para refatorar o código quando houver uma alteração que você precise fazer de qualquer maneira. Você pode não ter escolhido o método que eles fizeram para algumas coisas, mas se funcionar, tenha muito cuidado ao alterá-lo e introduzir novos bugs. Especialmente quando você não foi solicitado a alterá-lo.

Após uma semana, você não tem credibilidade para fazer grandes sugestões sobre como eles negociam. Se você mencionar as coisas agora, as pessoas rirão de você e nunca o levarão a sério. Prove-se primeiro com um bom código e depois as pessoas estarão mais inclinadas a ouvir.

E, francamente, ninguém se importa que você seja um Microsoft Certified Professional. Qualquer pessoa com muita experiência viu tantos programadores ruins que tiveram essa certificação como pessoas boas. Não estou dizendo que isso faz com que você pareça mal ter uma certificação, estou dizendo que não damos muita credibilidade a eles, porque não vimos onde eles são eficazes, está nos mostrando quem é um bom programador.

Eu provavelmente tentaria descobrir como apresentar a proposta com a intenção de que você acabe não sendo capaz de justificar sua posição adequadamente. Algumas perguntas a serem consideradas na criação dessa proposta:

• Quanto valor comercial é obtido com as mudanças que você descreve aqui?
• Você já pensou em opções como reescrever o aplicativo do zero, modificar o código existente para atualizá-lo ou apenas fazer pequenas alterações ao longo do tempo?
• Você sabe quais recursos e erros são desejados agora e que impediriam você de fazer as alterações desejadas?

Embora eu possa gostar de querer consertar a base de código ruim, isso precisa ser ponderado para que faça sentido, do ponto de vista comercial, fazê-lo.

No momento, você não está em condições de impedir o código incorreto, portanto precisará descobrir como contê-lo.

O PM e os líderes de equipe só se importam se não funcionar. A próxima preocupação deles será quando eles pedirem que você faça alterações e se perguntem por que as coisas "simples" demoram tanto. É aí que você entra.

Comece agora com o problema de consistência. Qualquer que seja o método potencialmente padrão atualmente, tente identificá-lo e verifique se você não pode aplicá-lo. Se você começar com uma metodologia com a qual ninguém mais está familiarizado, você receberá um empurrãozinho para trás.

Outros membros da equipe podem querer obter a certificação e você será um ótimo recurso. Espero que pelo menos queiram melhorar e procurem você para mostrar o caminho.

Reclamar sobre a notação húngara não lhe dará simpatia e é provavelmente uma das últimas batalhas na lista de prioridades.

Concordo que você precisa ter cuidado com isso. Você precisa criar reputação dentro da equipe antes de poder expressar críticas e propor profundas mudanças no código ou nos processos. Gostaria apenas de tomar notas sobre minhas descobertas e sugestões por enquanto e aproveitar oportunidades para me familiarizar com os membros da equipe e com a gerência, entrando em discussões gratuitas, mas não recusando se a conversa se voltar para questões de qualidade, questões de codificação etc., às vezes até jogando algumas das minhas próprias perguntas na lagoa (mas de uma forma geral, não muito apontadas para qualquer questão concreta que eu tenha visto nessa base de código). Dessa forma, posso conhecer a opinião dos membros da equipe e encontrar aliados em potencial.

Na melhor das hipóteses, você pode achar que uma parte significativa da equipe (e / ou gerência) vê os mesmos problemas que você, apenas não houve nenhuma iniciativa para fazer algo a respeito deles, ou nenhum recurso concedido a ela pela gerência. Juntos, você tem mais a dizer para convencer a gerência, se necessário.

Como o @Mike sugeriu, certamente é necessário fazer uma limpeza, mas, novamente, é melhor ter paciência. Se você começar muito rápido, poderá alienar outros membros da equipe que podem considerá-lo uma crítica pessoal. Também entrar em extensa limpeza / refatoração de código pode ser considerado pelo gerente como um sinal de que você não está focado o suficiente na tarefa real. Portanto, você deve obter um mandato para refatorar antes de embarcar em um nível mais sério. Pequenas mudanças locais provavelmente estão OK.

Além disso, para convencer o gerenciamento, você precisa de uma lógica comercial. O gerenciamento raramente é movido por descrições de quão inconsistente é o estilo de codificação. Você precisa mostrar a eles qual o valor que as alterações propostas podem trazer para a empresa - o resultado final é o dinheiro. Se você pode montar um cálculo convincente sobre os benefícios de custo versus longo prazo de várias alterações propostas e mostrar que o saldo geral está claramente do lado positivo, você aumentou suas chances visivelmente.

Faça Você Mesmo. Se você valoriza determinados estilos de codificação, trabalhe no código que viola os estilos de codificação . Faça check-out de um código incorreto no controle de origem, reformate o código para os requisitos de espaços em branco do estilo (como exemplo) e confirme o código atualizado com a mensagem "Conformidade com a regra do guia de estilo sobre espaços em branco".

Depois de uma semana, a pior coisa que você provavelmente pode fazer é ir diretamente à gerência com isso. Com toda a probabilidade, eles dedicaram muito tempo ao código e têm algum grau de orgulho nele. Você provavelmente sairia como um severo "sabe tudo".

O que eu faria se fosse você é melhorá-lo à medida que avança. À medida que você se familiarizar com ele e trabalhar mais, terá a chance de melhorá-lo. Seria nesse ponto que eu começaria a mostrar os benefícios do que você está fazendo com outros colegas de trabalho. Depois disso, quando as reuniões de design surgirem para novos módulos, apresente um argumento para o que você considera o melhor caminho.

E honestamente, os padrões existem por uma razão, mas, se funcionar e funcionar bem, vale 100 vezes mais em meu livro (especialmente depois de uma semana). Eu ficaria mais preocupado se você abrisse o código e visse vários erros de lógica ou algo dessa natureza.

Não vá diretamente ao gerenciamento com esse 'problema'.

Primeiro, converse com seus colegas de trabalho e descubra com eles por que as coisas são do jeito que são. Então você pode fazer uma avaliação melhor, se há um problema ou não. Você pode se surpreender com o que aprende. Você também pode encontrar aliados em querer limpá-lo.

Se você não tem idéia de como chegou aonde está, torna muito mais difícil sair.

Muitas sugestões boas aqui já, e eu sou da opinião de que não queime suas pontes até que você se prove primeiro como as outras. O que eu acrescentaria é discutir as coisas com seus colegas de equipe muito antes de aliená-las, indo primeiro ao gerente de projeto ou ao líder da equipe. E certamente mostre a eles antes disso que você deve ser levado a sério.

Parece também que é mais um problema estilístico que você está tendo com o código. Assumir o código de outra pessoa e segurar seu nariz enquanto se acostuma à maneira como ela a escreveu é apenas parte do trabalho, mesmo que seja algo trivial como a forma como a formata. Entregar um dos seus 'bebês' a outra pessoa para que eles o mutilem com as mãos sujas é ainda pior ...

Se, em última análise, for mais do que isso - e o problema for mais funcional do que estilístico - se você estiver indo para o líder da equipe / pm, é melhor apresentar a necessidade de retrabalho em termos de onde economizaria dinheiro e esforço no futuro projeto de desenvolvimento. Boa e velha refatoração.