Qual é a / Existe uma maneira correta de informar à gerência que nosso código é péssimo?

Nosso código é ruim. Pode não ter sido sempre considerado ruim, mas é ruim e só está indo ladeira abaixo. Comecei recém-saído da faculdade há menos de um ano e muitas das coisas em nosso código me deixam além da crença. No começo, imaginei que, como o novo cara, eu deveria ficar de boca fechada até aprender um pouco mais sobre nossa base de código, mas vi muito para saber que é ruim.

Alguns dos destaques:

• Ainda usamos frames (tente extrair algo de uma querystring, quase impossível)
• VBScript
• Fonte segura
• Nós "usamos" o .NET - com isso quero dizer que temos invólucros .net que chamam DLLs de COM, tornando quase impossível depurar facilmente
• Tudo é basicamente uma função gigante
• O código não pode ser mantido. Cada página possui vários arquivos criados sempre que uma nova página é criada. A página principal basicamente faz o Response.Write () várias vezes para renderizar o HTML (runat = "server"? De jeito nenhum). Depois disso, pode haver muita lógica no lado do cliente (VBScript) e, finalmente, a página é submetida a si mesma (geralmente armazenando muitas coisas em campos ocultos), onde é lançada em uma página de processamento que pode fazer coisas como salvar o arquivo. dados para o banco de dados.
• As especificações que obtemos são risíveis. Muitas vezes, eles pedem itens como "preencher automaticamente o campo X com o campo Y ou o campo Z", sem indicação de quando escolher o campo Y ou o campo Z.

Tenho certeza de que parte disso é resultado de não estar empregado em uma empresa de software, mas sinto que as pessoas que escrevem software deveriam pelo menos se preocupar com a qualidade de seu código. Eu não posso nem imaginar que, se eu fosse mencionar algo, algo seria feito em breve, pois existe um grande prazo, mas continuamos a escrever códigos ruins e a usar práticas inadequadas.

O que eu posso fazer? Como faço para trazer essas questões à tona? 75% da minha equipe concordam comigo e levantaram essas questões no passado, mas nada é alterado.

Certifique-se de que você não está exagerando. Você é novo, provavelmente não trabalhou em muitos outros lugares e, portanto, não está preparado para o mundo do "código da vida real". O código da vida real é uma coisa horrível. É como se seu código legal da escola e seu código pessoal obsessivamente aprimorado fizessem sexo no porão de um reator nuclear e o bebê crescesse em um esgoto de lixo tóxico; é um mutante hediondo.

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

Sendo um júnior, você provavelmente não está em posição de liderar. Se você for gerente, como novo contratado, que também é júnior, sua opinião provavelmente será desconsiderada. Obtenha seu desenvolvedor principal ou um dos mais experientes envolvidos. Novamente, se nenhuma das pessoas mais velhas estiver interessada, você estará desperdiçando seu tempo.

Supondo que você possa interessar 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", da próxima vez que você estiver trabalhando nessa "função gigante", talvez deva refatorar um pouco. Novamente, você precisa colocar todo mundo de lado. Se você lascar pequenos pedaços do seu problema e melhorar pedaço por pedaço, eventualmente eles se tornarão muito menos problemáticos. Sempre que você tocar em um pedaço de código, considere se ele pode ser aprimorado.

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 há problemas e que há um plano para melhorar lentamente à medida que as alterações são feitas. Eles devem ser informados sobre os benefícios do código sustentável. Isso deve vir de uma pessoa idosa em quem eles confiam técnica e profissionalmente - e não de você.

Reescrever completo? Quase sempre uma má ideia.

Em última análise, não há muito que você possa fazer porque é novo. Se ninguém quiser 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 e depois leia alguns outros artigos sobre software ruim e como corrigi-lo, escrito por gerentes, não por programadores. Armado com essas informações, você poderá apresentar um caso para corrigi-las, em termos que os gerentes entendam e se preocupem. Dica: Bons gerentes não gastam tempo e dinheiro baseados apenas nas opiniões e sentimentos dos programadores sobre o que deve ser feito.

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

"Podemos tirar meses do cronograma atual do projeto, custando menos e torná-lo mais confiável". chamará a atenção deles (observe a falta de menção ao COMO você pretende fazer isso no estágio dele.

Tudo o que você diz, tenha certeza de que está correto. Se você diz que é ruim, sua reescrita deve ser muito boa. Se você disser que levará uma semana, é melhor ter certeza de que será uma semana e será boa. Qualquer defeito no código reformulado custará caro para você, pessoalmente, independentemente do que possa ter acontecido se você não tivesse feito o retrabalho. Se alguém esteve lá antes de você e estragou ou vendeu demais uma reescrita, desista, os gerentes não gostam de ser feitos de tolos e não deixarão que isso aconteça duas vezes. Por esse sinal, não estrague tudo para os caras que seguem, você só tem uma chance disso ...

Encontre maneiras de distribuir o custo por um período ou número de projetos. Os gerentes odeiam riscos, investimentos especulativos e fluxo de caixa negativo - trabalhe dentro das tolerâncias de seus gerentes. Comece com uma sugestão pequena, de baixo risco e baixo custo. Quando estiver certo, você pode procurar o peixe maior.

Primeiro de tudo, você encontrará coisas herdadas de patetas em qualquer lugar em que trabalhe como programador, a menos que trabalhe em uma start-up e você quem criou o código legado de pateta original. Você precisa ser capaz de dar esses socos se planeja ter uma carreira em programação.

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

Em situações em que houve um grande fracasso no passado, é quase impossível provocar uma mudança. Nesse caso, aprimore 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 que não estava em uma carreira satisfatória e crescente. Se estiver quebrado, e parece que está no seu caso, é quando você tem uma chance de mudar.

A melhor abordagem que já vi não é exagerar, mas começar com mudanças incrementais que terão o impacto mais positivo. Com base na sua descrição, o melhor gerenciamento de solicitações de mudança seria um ponto de partida. Quando estiver sob controle, você poderá começar a criar uma estrutura de serviço ou outras melhorias incrementais de design / código.

A pior abordagem que já vi é tentar dar um grande salto diretamente de um sistema legado para o mais recente e melhor, por exemplo, saltando de um sistema VB6 / Classic ASP / COM + funcional, mas desajeitado, para um sistema MVC / Entity Framework.

"Ei, chefe, 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 fazer isso logo após o Big Project, gostaríamos de planejar um cronograma realista ".

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

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

A PRIMEIRA coisa que eu faria é realizar um teste de Joel .

Isso permitirá que você a apresente como "Enquanto eu procurava maneiras de melhorar como desenvolvedor ... deparei-me com este teste de 12 perguntas sobre ambientes de desenvolvimento, então, por diversão, respondi a eles sobre onde trabalho". ... Isso, por sua vez, torna um esboço de terceiros o que há de errado com seu código e não com você.

À medida que você ler mais sobre Práticas Pragmáticas, você estará aprimorando-se e implementando coisas como vermelho / verde / refatorado, e isso, por sua vez, permitirá que você limpe a base de código para que seja mantida. (hora extra)

Espero que ajude! Bem-vindo à programação (o código de ontem costuma ser péssimo) ;-)

Dica rápida: se você propõe um gerenciamento com uma lista de razões pelas quais deve codificar de maneira diferente, inclua como argumento "Melhor moral / condições de trabalho para os programadores".

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

• A gerência realmente dita o design? Se você tem a maioria da equipe atrás de você, o que está impedindo você? Seja proativo e decida como um grupo. Elabore um plano para implementá-lo de forma incremental . Então faça.
• O gerenciamento determina as ferramentas de desenvolvimento que você usa? A menos que haja um custo de tempo para trocar um gerenciamento de ferramentas geralmente não se 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. Então faça.
• A gerência dita os idiomas que você usa? Seja proativo e decida em grupo o que usar em vez do VBScript. Elabore um plano para implementá-lo de forma incremental e fazê-lo. Se você precisar comprar a gerência, mostre o plano. Então faça.
• Não tenho nada para especificações. Isso geralmente é altamente dependente das pessoas e processos no 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 devem funcionar. Se você sabe que pode elaborar um plano e tentar convencer o gerenciamento.

Você obtém mais mudanças e respeito se propor formas de mudança que não envolvam grandes quantidades de tempo dedicado, sem valor comercial (ou moderado) a ser mostrado.

Falando por experiência própria: não é fácil. É quase impossível. A gerência não se importa que o código seja péssimo e, mais do que provável, seja completamente ignorante e / ou sem noção dos problemas que estão sendo enfrentados, ou eles o teriam corrigido há muito tempo e você não ficaria preso a ele hoje. A melhor coisa que você pode fazer é fazer uma lista dos motivos pelos quais o código é uma porcaria e, em seguida, o raciocínio por trás dele para demonstrar o valor real dos negócios na refatoração / reescrita.

Um exemplo pode ser para "O código não é sustentável":

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

Sua única esperança é que seu chefe e a gerência sênior não sejam muito estúpidos para entender quais ramificações existem para o código e estejam dispostos a deixar de apresentar solicitações de novos recursos para resolver os problemas, caso contrário seus esforços serão 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 sejam muito fracos para trazer suas preocupações para a gerência.

Boa sorte. Você precisará disso.

"Comecei recém-saído da faculdade" - deve responder sua pergunta.

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

A gerência também sabe que funciona usando qualquer definição de "funciona" que se aplique à sua empresa (não trava, vende, entrega os relatórios ou o que for).

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

O caso de negócios é quase impossível de ser feito, porque a sua entrega é um software funcional (o que eles já têm) e não um código elegante.

Acrescente o fato de que, no software, há um grande custo de oportunidade ao chegar ao mercado com os recursos primeiro. Se você realmente pensa sobre isso, o retorno a longo prazo do investimento em 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, não de gerenciamento. Basta fazer o que precisa ser feito enquanto ainda cumpre o que promete e você ficará bem. Provavelmente, o gerenciamento não se interessará pelos detalhes detalhados da qualidade do código, mesmo que você faça um bom argumento.

Apenas saia o mais rápido possível (talvez não saia tão cedo quanto não quiser parecer uma tremonha de emprego). O fato de que eles codificam é uma bagunça e as pessoas ficam lá significa que você provavelmente está trabalhando com desenvolvedores ruins. Qualquer desenvolvedor decente que se preocupa com seu trabalho não fica muito tempo trabalhando nessa porcaria.

A chance de uma reescrita ocorrer bastante baixa, a menos que você possa demonstrar com muita clareza que valerá o investimento no valor de $ $.

A gerência não se importa com o código. Eles se preocupam 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 (digo a maioria porque sempre há um cara que codificou pedaços grandes ou tudo isso e o conhece como o verso de a mão dele) então os aborda e diz que está custando o dinheiro da empresa em tempo de desenvolvimento, e isso afetará a satisfação do cliente.

Porém, mais uma vez, eles ainda não se importam com o código, se preocupam com um produto, portanto, embora essa resposta possa fazê-los dizer "Sim, vamos lá", você também pode arrumar o código sem procurar a permissão de um gerente. Não exagere, certifique-se de conversar com a equipe primeiro, ninguém gosta de vir e tentar usar a função que levou três meses para escrever e agora parece não funcionar porque foi invadida.

Aborde o gerenciamento de maneira que você mostre que entende os impactos no orçamento de fazer grandes alterações no código e os impactos no orçamento de NÃO fazer as alterações. Gostei da redação de Emilio.

É importante ter em mente que o código "antigo" sempre será péssimo. Com isso, quero dizer, todos nós crescemos como desenvolvedores constantemente. 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 ficam constantemente tentando melhorar e desperdiçar mais dinheiro a longo prazo. É um ato de equilíbrio. Dito isto, é sempre ótimo se você pode torná-lo melhor à medida que avança. Quando você modificar essa função gigante, divida-a! Eventualmente, você chegará a algum lugar.

Não faça isso.

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

Nunca pensei que fosse fácil falar aos gerentes, especialmente aos gerentes de projeto, sobre códigos ruins e refatoração. Primeiro, eles devem confiar em você, mesmo que você seja um veterano, ainda precisa de tempo para confiar. Segundo, eles simplesmente não entendem o quão ruim é o problema. Se hoje é o último dia para lançar uma nova compilação, e a compilação falhará. Eles sabem o quão sério é, mas nunca sabem que a construção falhou porque muitos problemas, como código incorreto, teste inadequado etc.

Concluí tarefas de configuração e implantação em um projeto da web. Geralmente, leva muito tempo para corrigir problemas inesperados toda vez que implanto uma nova compilação. A maioria dos problemas foram de segurança e integração (entre vários aplicativos Web / Windows). Nosso código é péssimo, o código dos outros é péssimo, eles são completamente códigos espaguete.

Estávamos planejando uma nova versão e solicitei fortemente alguma refatoração, basta adicionar um registro detalhado ao código de login / autenticação onde os bugs costumavam ocorrer. Os gerentes concordaram, mas, em seguida, foram colocados em uma lista interessante e não sei se isso será feito, pois já tínhamos uma grande lista de recursos e um prazo apertado.

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

De qualquer forma, os gerentes são todos mentirosos, por isso têm uma forte disposição de assumir que todo mundo é.

O que quero dizer é que, se você diz que o software está desatualizado, eles o consideram uma desculpa. Eles não se importam.