Qual é o / Existe uma maneira correta de dizer ao gerente que o nosso código é uma droga?

Verifique se você não está exagerando. Você é novo, provavelmente não trabalhou em muitos (outros?) Outros lugares, e por isso não está preparado para o mundo do "código da vida real". Código da vida real é uma coisa horrível. É como se o seu código da escola fosse legal e seu código pessoal de projeto obsessivamente alterado fizesse sexo no porão de um reator nuclear e o bebê crescesse em um esgoto de lixo tóxico; é um mutante medonho.

Mas supondo que você esteja certo, e o código é tão ruim quanto você diz (ou seja, pior do que apenas o código normalmente ruim), então você está certo em se preocupar. Converse com sua equipe e determine se todos os outros estão do lado. É preciso trabalhar para melhorar a situação - se o resto da equipe reconhecer o problema, mas não se importar, você estará desperdiçando seu tempo.

Sendo um júnior, você provavelmente não está em posição de liderar. Se você for para a gerência sozinho, como um novo contratado que também seja júnior, sua opinião provavelmente será desconsiderada. Obtenha seu desenvolvedor líder ou um dos caras mais experientes envolvidos. Novamente, se nenhuma das pessoas mais experientes estiver interessada, você está desperdiçando seu tempo.

Supondo que você possa ter interessados em algumas pessoas técnicas seniores, eu trabalharia para identificar áreas problemáticas e possíveis soluções. Por exemplo, se "tudo é basicamente uma função gigante", então da próxima vez que você estiver trabalhando nessa "função gigante" talvez deva refatorar um pouco. Mais uma vez, você precisa colocar todo mundo em jogo. Se você cortar pedaços pequenos do seu problema & melhorar pedaço por pedaço, eventualmente, eles se tornarão muito menos de um problema. Toda vez que você tocar em um pedaço de código, considere se ele pode ser melhorado.

Você não vai se sentar com a gerência e dizer "tudo está ruim e precisa ser reescrito". Isso não faz sentido para eles - custa muito e é potencialmente muito arriscado. Em vez disso, eles devem estar cientes de que existem problemas e que há um plano para melhorar lentamente à medida que as mudanças são feitas. Eles devem ser educados sobre os benefícios do código sustentável. Isso deve vir de uma pessoa sênior em quem eles confiam técnica e profissionalmente - não de você.

Reescrita completa? Quase sempre uma má ideia.

Em última análise, não há muito o que fazer porque você é novo. Se ninguém quer melhorar as coisas, você reúne sua experiência e passa para o próximo lugar.

Leia Joel On Software - coisas que você nunca deve fazer. Entenda seu raciocínio, leia alguns outros artigos sobre softwares ruins e como corrigi-los, escritos por gerentes, não por programadores. Armado com esta informação, você será capaz de apresentar um caso para corrigi-lo, em termos que os gerentes entendam e se preocupem. Dica: Bons gerentes não gastam tempo e dinheiro apenas com base em opiniões e sentimentos dos programadores sobre o que deve ser feito.

"Este código é uma porcaria e precisa ser reescrito" certamente será jogado de volta em você, mesmo se você estiver tecnicamente correto.

"Podemos tirar meses do cronograma atual do projeto, custando menos e tornando-o mais confiável." vai chamar sua atenção (note falta de menção do COMO você pretende fazer isso em seu estágio.

O que quer que você diga, esteja certo de que você está correto. Se você disser que é ruim, sua reescrita precisa ser muito boa. Se você disser que levará uma semana, é melhor ter certeza de que será uma semana e ser bom. Qualquer defeito no código retrabalhado custará caro, pessoalmente, independentemente do que possa ter acontecido se você não tivesse feito o retrabalho. Se alguém já esteve lá antes de você e errou ou sobreviveu uma reescrita, desista, os gerentes não gostam de ser feitos de bobos e não deixam acontecer duas vezes. Por esse sinal, não estrague tudo para os caras que seguem, você só tem uma chance nisso ...

Encontre formas de distribuir o custo ao longo de um período ou número de projetos. Os gerentes odeiam o risco, o investimento especulativo e o fluxo de caixa negativo - trabalhe dentro das tolerâncias dos gerentes. Comece com uma pequena sugestão de baixo risco e baixo custo. Uma vez que você está certo, você pode ir para o peixe maior.

Em segundo lugar, muitas vezes há considerações de custo para melhorar os sistemas antigos. Por exemplo, eu vi mais de uma empresa que tinha 10 anos de idade VB6 e aplicativos ASP clássicos ainda em operação. Em alguns casos, isso ocorreu porque um grande projeto para mover o .NET falhou gravemente. Em outros, o motivo era "se não está quebrado, não conserte". Mas, em outros, o custo do movimento é justificável, já que os problemas causados pelo sistema legado são grandes demais para serem ignorados.

Em situações em que houve uma grande falha no passado, é quase impossível provocar uma mudança. Nesse caso, aperfeiçoe seu currículo e comece a procurar um novo emprego. Se não estiver quebrado, você provavelmente não terá motivos para reclamar do código em si, mas de que você não estava em uma carreira satisfatória e crescente. Se está quebrado, e parece que é no seu caso, é quando você tem a chance de mudar.

A melhor abordagem que eu vi não é para morder muito, mas para começar com mudanças incrementais que terão o impacto mais positivo. Com base na sua descrição, gerenciar melhor as solicitações de alteração seria um lugar para começar. Uma vez sob controle, você pode começar a procurar criar uma estrutura de serviço ou outras melhorias incrementais de design / código.

A pior abordagem que eu vi é tentar dar um grande salto diretamente de um sistema legado para o mais recente e maior, por exemplo, saltar de um sistema VB6 / Classic + / COM + funcional para um MVC / Entity Sistema de estrutura.

"Hey Boss, depois do Big Project, eu e a equipe gostaríamos de algum tempo, idealmente X meses, para organizar nosso código. Coisas que devem ser feitas em minutos levam horas porque tudo é muito desorganizado. Se não for possível fazê-lo logo após o Big Project, gostaríamos de planejar um cronograma realista. "

(parcialmente parafraseado do comentário de Azkar sobre a questão)

Comece a ler o Joel on Software (Joel Spolsky / Fundador da Stack Exchange) ...

A PRIMEIRA coisa que eu faria seria realizar um Teste de Joel .

Isso permitirá que você apresente como "Enquanto eu estava procurando maneiras de melhorar como desenvolvedor ... Eu tropecei neste teste de 12 perguntas sobre ambientes de desenvolvimento, então por diversão eu respondi a eles sobre onde eu trabalho." ... Isso, por sua vez, faz com que seja uma terceira parte delineando o que está errado com seu código e não com você pessoalmente.

Ao ler mais sobre Práticas Pragmáticas , você estará melhorando a si mesmo e implementando coisas como red / green / refactor e este por sua vez, permitirá que você limpe a base de código para que ela se torne sustentável. (com o tempo)

Espero que ajude! Bem-vindo à programação (o código de ontem geralmente é uma droga) ;-)

Dica rápida: se você propuser gerenciamento com uma lista de razões por que você deve codificar diferentemente, inclua como um argumento "Melhoria da moral / condições de trabalho para os programadores".

Deixe claro que a equipe de tecnologia terá mais conteúdo escrevendo e mantendo código limpo do que essa bagunça atual, e isso certamente pode melhorar sua atitude em relação ao trabalho. Poderia ser um argumento útil.

• A gerência realmente dita o design? Se você tem a maior parte da equipe atrás de você, o que está te impedindo? Seja proativo e decida como um grupo. Crie um plano para implementá-lo incrementalmente . Então faça isso.
• O gerenciamento dita as ferramentas de desenvolvimento que você usa? A menos que haja um custo de tempo para trocar um gerenciamento de ferramentas, geralmente não importa. Seja proativo e decida como um grupo quais ferramentas de desenvolvimento você deseja usar. Se você precisar comprar da gerência, mostre a eles um plano de migração e uma análise de custo-benefício. Em seguida, faça isso.
• O gerenciamento dita os idiomas que você usa? Seja proativo e decida como um grupo o que usar em vez do VBScript. Apresente um plano para implementá-lo de forma incremental e faça-o. Se você precisar de uma gestão, mostre-lhes o plano. Então faça isso.
• Eu não tenho nada para especificações. Isso geralmente depende muito das pessoas e processos em seu trabalho. Identificar o que está quebrado e as mudanças mínimas necessárias para corrigir o processo leva tempo, análise e compreensão de como as coisas funcionam atualmente e como elas devem funcionar. Se você sabe que pode elaborar um plano e tentar convencer a administração.

Você obtém mais mudanças e respeito se propor formas de alteração que não envolvam grandes quantidades de tempo dedicado sem o valor comercial (ou flexível) para mostrar isso.

Falando da experiência: não é fácil. É quase impossível. Gestão não se importa que o código é uma porcaria e mais do que provável são completamente ignorantes e / ou ignorante dos problemas que estão sendo enfrentados, ou eles teriam consertado isso há muito tempo e você não estaria preso com isso hoje. A melhor coisa que você pode fazer é fazer uma lista das razões pelas quais o código é uma droga, e então o raciocínio por trás do por que é ruim para demonstrar o valor real do negócio em refatorar / reescrevê-lo.

Um exemplo pode ser "Código não é sustentável":

O código atual não é passível de manutenção por causa de X , Y e Z (liste os motivos pelos quais não pode ser mantido). Isso torna as requisições de mudança e os novos recursos muito difíceis de fazer, porque X , Y , Z (razões pelas quais é difícil fazer mudanças). Como as mudanças são difíceis, a equipe de desenvolvimento não pode responder facilmente a correções de bugs e melhorias.

Sua única esperança é que seu chefe e sua alta gerência não sejam burros demais para entender as ramificações do código e que estejam dispostos a deixar de receber novas solicitações de recursos para resolver os problemas. Caso contrário, seus esforços serão seja em vão. Falando de experiências passadas, é muito provável que eles não vejam nada de errado com o código, e / ou seus colegas de trabalho fiquem com covardia demais para trazer suas preocupações para a gerência.

Boa sorte. Você precisará disso.

"Eu comecei a sair da faculdade" - deveria responder sua pergunta.

O gerenciamento provavelmente sabe que o código está abaixo do ideal. A maioria dos códigos é a menos que você contrate Ray Gosling, Guido Van Rossum ou alguém realmente bom e caro para escrevê-lo.

O gerenciamento também sabe que funciona usando qualquer definição de "obras" que se aplica à sua empresa (não trava, vende, entrega relatórios ou qualquer outra coisa).

Eles querem que você mantenha o código "funcionando" a um custo mínimo. Eles não querem uma proposta de um projeto caro para reescrever tudo.

O caso de negócio é quase impossível de fazer porque o seu entregável está funcionando software (o que eles já têm) não código elegante.

Acrescente o fato de que no software há um grande custo de oportunidade de chegar ao mercado com recursos primeiro. Se você realmente pensar sobre isso, o retorno a longo prazo do investimento de tempo não é garantido.

Dito isto, ainda é um bom plano refatorar e consertar as pequenas coisas (como obter um bom VSS) ao longo do caminho em mordidas gerenciáveis. Em última análise, esta é uma questão técnica e não de gestão. Basta fazer o que precisa ser feito enquanto ainda cumpre o que você promete e você ficará bem. O gerenciamento provavelmente não vai se interessar pelos detalhes básicos da qualidade do código, mesmo que você tenha um argumento strong.

Apenas saia o mais rápido possível (talvez não seja muito cedo, pois você não quer se parecer com um funil de trabalho). O fato de que eles codificam é uma bagunça e as pessoas ficam lá significa que você provavelmente está trabalhando com desenvolvedores pobres. Qualquer desenvolvedor decente que se importe com o trabalho deles não ficaria muito tempo trabalhando nessa porcaria.

A chance de uma reescrita ocorrer em um nível muito baixo, a menos que você possa demonstrar claramente que valerá a pena o investimento.

O gerenciamento não se importa com o código. Eles se importam em ter um produto para vender.

Se o sistema legado é muito, muito ruim e está adicionando uma quantidade ridícula de sobrecarga para a maioria da equipe (eu digo maioria porque há sempre um cara que codificou grandes pedaços ou tudo isso e sabe como a parte de trás de sua mão), em seguida, abordá-los e dizer que está custando o dinheiro do negócio em tempo de desenvolvimento, e vai ter uma batida em efeito com a satisfação do cliente.

Mas, mais uma vez, eles ainda não se importam com código, eles se preocupam com um produto, então, embora essa resposta possa fazer com que "Sim, vamos fazer", você pode arrumar o código sem pedir permissão um gerente. Não exagere, não deixe de falar com a equipe primeiro, ninguém gosta de vir e tente usar essa função que levou 3 meses para escrever e agora parece não funcionar porque foi hackeada.

Aproxime-se da gestão de modo a mostrar que compreende os impactos orçamentais de fazer grandes alterações ao código e os impactos orçamentais de NÃO efetuar as alterações. Eu gostei do texto de Emilio.

É importante ter em mente que o código "antigo" sempre será horrível. Por isso quero dizer, todos nós crescemos como desenvolvedores constantemente. Nós escrevemos um bom código, depois aprendemos a escrever um código melhor mais tarde e o código "bom" anterior parece terrível. Muitos desenvolvedores são apanhados constantemente tentando torná-lo melhor e desperdiçar mais dinheiro a longo prazo. É um ato de equilíbrio. Dito isto, é sempre bom se você pode melhorar ao longo do caminho. Quando você vai modificar essa função gigante, divida-a! Eventualmente você chegará a algum lugar.

Não faça isso.

Reescrever um grande projeto do zero é um grande erro na maioria das vezes.

Nunca achei que seja fácil dizer aos gerentes, especialmente aos gerentes de projeto, sobre códigos incorretos e refatoração. Primeiro, eles devem confiar em você, mesmo se você é um cara mais velho, você ainda precisa de tempo para ser confiável. Em segundo lugar, eles simplesmente não entendem o quão ruim é o problema. Se hoje é o último dia para liberar uma nova compilação, e a compilação falhar. Eles sabem o quão sério é, mas eles nunca sabem que a construção falhou por causa de muitos problemas, como códigos ruins, testes inadequados, etc.

Eu fiz tarefas de configuração e implantação em um projeto da web. Geralmente, leva muito tempo para corrigir problemas inesperados sempre que eu implantar uma nova compilação. A maioria dos problemas eram segurança e integração (entre vários aplicativos da web / Windows). Nosso código é péssimo, o código dos outros é péssimo, é um código completamente espaguete.

Estávamos planejando uma nova versão e solicitei bastante alguma refatoração, basta adicionar o log de detalhes ao código de login / autenticação, onde os erros costumavam ocorrer. Os gerentes concordaram, mas depois foi colocado em uma lista legal e eu não sei se isso será feito, já que já tínhamos uma lista grande de recursos e um prazo apertado.

Existem dois tipos de gerentes: aqueles que fingem entender o que você faz e aqueles que não o fazem. Aqueles que pretendem entender o software serão hostis a você. Os que não são apenas aborrecidos por você.

Em qualquer caso, os gerentes são todos mentirosos, então eles têm uma strong disposição para assumir que todos os outros são.

Meu ponto é, se você disser que o software está desatualizado, eles simplesmente aceitarão isso como uma desculpa. Eles não se importam.