Milhares de erros!


30

Fui designado para um novo projeto recentemente. Bem, na verdade, um projeto antigo, escrito em ASP clássico. Agora, uma nova versão do aplicativo está sendo escrita no ASP.NET mais recente, mas não se espera que seja o RTM daqui a um tempo (a data estimada de lançamento é janeiro de 2017), por isso preciso executar algumas manutenções no aplicativo antigo até que ele possa ser descartado.
Além disso, tenho a sensação de que nem todos os clientes passarão para o novo programa imediatamente, portanto esta versão provavelmente estará disponível por um tempo.

E o problema é que está cheio de erros. Partes dele datam do século anterior, quando não havia padrões da Web, e eu realmente não me importo com o modo Quirks, widthe heightatributos, em vez de CSS, tabelas usadas para layout, conjuntos de quadros etc., mas oh, todos esses erros! width="20px"em todo o lugar, onchange="javascript:..."e naqueles lugares em que eles usam css style="width:20"e style="width=20px"são comuns. Sem mencionar muitas linhas onde existem contraditórios widthe styleatributos. Etc etc.
Como resultado, o aplicativo Web é executado apenas no IE e apenas no modo de compatibilidade. É claro que os desenvolvedores nunca olharam para a validade do código, apenas se o que saiu parecesse com o que eles tinham em mente.

E eu não sei como lidar com isso. Acho impossível fechar meus olhos para esses erros enquanto procurava no código por outros erros.
É claro que posso fazer uma busca e substituição global para eliminar a maioria dos problemas, mas isso significaria que meu primeiro commit consistiria em milhares de arquivos .asp alterados. Posso fazer isso?


21
por "erros" você quer dizer estilo de codificação que você não gosta?
Ewan

9
Uma dica que ouvi: Vá para um lugar onde os estudantes de música praticam. Tente ficar quinze minutos em uma sala à prova de som. Gritar por quinze minutos. Agora você se sente melhor, vá e corrija os bugs! Sério, verifique com a gerência qual é o objetivo. Se esse software for necessário, poderá em breve impedi-lo de atualizar os computadores e causar problemas na substituição de computadores quebrados mais antigos.
gnasher729

24
Esta pergunta parece mais um discurso retórico. Por que você está reclamando de um software que será descartado em alguns meses?
Doc Brown

5
Não é um "erro" que o código escrito em "ASP clássico" siga os padrões (como eram) do ASP clássico, que são diferentes da última moda na codificação da Web - e provavelmente a última moda estará "fora data "no próximo ano, em qualquer caso. "Está claro que os desenvolvedores nunca examinaram a validade do código" - se o OP achar que pode escrever código que ainda "parecerá válido" 15 ou mais anos no futuro, o tempo dirá se essa crença é apenas o otimismo natural ( ou ignorância) da juventude.
alephzero

19
"Eu tenho que executar alguma manutenção no aplicativo antigo até que ele possa ser descartado." Que manutenção? Por favor, seja específico. Se você foi encarregado de manter essa base de código e nada mais foi dito, não altere nada. Mantê-lo implica que você continue fazendo o trabalho, não corrija as coisas que não são consideradas quebradas em primeiro lugar.
Stephan Branczyk

Respostas:


99

Parece que você está confundindo várias coisas com o termo "erros"

  • atributos html herdados
  • estilo de codificação
  • erros de codificação que não causam bugs
  • bugs não relatados
  • erros que agora são características
  • bugs relatados
  • bugs relatados aos quais você foi designado para corrigir

Em um aplicativo herdado que será substituído, apenas um desses tipos de erro deve preocupar você. O último.

Eu diria que você não deveria refatorar outras coisas em um recurso que está corrigindo erros, principalmente devido a:

  • erros que agora são características

Você pode ver no código como ele talvez funcionasse, mas nunca funcionou, mas todos os usuários estão se dando bem com o elemento de largura indeterminada nos últimos 10 anos e não agradecem por corrigi-lo.

No lado positivo, se você colocar sua cabeça cínica no JFDI, poderá queimar, embora os bugs sejam super rápidos e a equipe da nova versão não consiga acompanhar os recursos das versões antigas.

Isso dará a você um sorriso irônico de alegria irônica, pois você recomenda um emulador de plug-in chrome ie6 para os clientes, para que eles possam continuar usando o 'recurso' de letreiro que amam


28
" Erros que são agora apresenta " - oh, a alegria ...
FP

36
Na verdade ser muito cauteloso no que você toque, este imediatamente me veio à mente: xkcd.com/1172
Dennis Jaheruddin

3
Por favor, esclareça... JFDI ...
GER

5
@GER "Just [expletive] Do It", que significa evitar os padrões e testes normais e outras coisas e apenas corrigir o problema sem se importar se é feito de maneira sustentável e legível.
Nzall

3
como Aglié mas mais ainda
Ewan

40

O que você faz não é uma pergunta técnica e ninguém aqui pode responder.

Você está trabalhando em um software no modo de manutenção e observa a tecnologia fora de moda e um grande número de imperfeições e inconsistências. Você pergunta o que fazer. Você deveria, por exemplo, estender esforços para torná-lo compatível com vários navegadores? Você deve alinhá-lo com os padrões modernos? Você deve corrigir inconsistências sintáticas no aplicativo? O problema é que essas são decisões de negócios . Você deve perguntar ao seu gerente ou proprietário do produto quais problemas eles querem que você resolva e quais são suas prioridades. Como já existe um projeto em andamento para reescrever o aplicativo, é provável que o gerenciamento já esteja ciente dos problemas observados.

Se o aplicativo for totalmente substituído em questão de meses, é provável que eles desejem apenas que você corrija problemas críticos específicos e deixe o resto da bagunça em paz. Mas nós não sabemos.

Você pergunta se pode fazer uma operação abrangente de pesquisa e substituição na base de código, alterando milhares de arquivos. Claro que você pode. A questão é se você deveria . Tais mudanças radicais provavelmente exigirão testes extensivos para garantir que nada ocorra. Novamente, é uma decisão comercial se o benefício exceder o custo em tempo e risco.


11
É uma decisão de negócios, mas é tão óbvio responder que ele não precisa perguntar ao gerente. Ele não deve limpar a bagunça, se não for necessário. (+1)
usr

14

Quando o aplicativo for substituído em 18 a 24 semanas (adicionando os atrasos esperados às 6 a 8 semanas estimadas apresentadas acima), você realmente precisará se perguntar qual valor agrega ao negócio, ainda investindo uma quantidade considerável de trabalho em a versão antiga.

Claro, quando você ficaria com o suporte do aplicativo por vários anos, então se livrar da dívida técnica pode valer a pena a longo prazo. Mas quando tudo vai ser descartado de qualquer maneira, por que se preocupar? Basta adicionar outra correção hackiana em cima de todas as outras correções hackísticas para reparar qualquer problema que simplesmente não pode esperar até o lançamento da nova versão e encerrar o dia.

Você também pode se perguntar o que pode fazer pelo aplicativo no pouco tempo de vida que ainda resta. Quando você está realmente entediado agora e simplesmente não tem nada melhor a ver com o seu tempo, você pode fazer uma grande revisão e remover todos os problemas de estilo mencionados, mas é muito provável que isso a princípio acabe com mais coisas do que consertará . Talvez você consiga se livrar desses novos problemas, com tempo suficiente, mas não tem esse tempo.


11
s/weeks/years/
CodesInChaos

9
No ano passado, eu estava corrigindo um bug de desempenho que basicamente correspondia a uma tabela que deveria armazenar em cache alguns valores recentes, mantendo realmente todo o histórico e crescendo sem limites. No local apropriado no código, houve um comentário dizendo essencialmente "isso deve ser limpo periodicamente, mas não importa, pois planejamos descartar o sistema até o final de 2007". Nada vive mais do que soluções temporárias.
Peteris

@ Peter Bem, impostos temporários. Mas sim.
Jay

Na última vez em que trabalhei em um aplicativo como este, ele também estava destinado a ser temporário. O pedaço de hardware que ele foi projetado para controlar estava sendo descartado e construído um substituto, e um novo software deveria ser desenvolvido para controlar o substituto., Que estaria disponível em 6 meses. Infelizmente, o hardware de substituição estava com defeito e todo o orçamento foi gasto na tentativa de corrigir as falhas; portanto, não havia mais nenhum para o sistema de controle de substituição. Depois de alguns anos, todo o projeto foi descartado. AFAIK, todo o sistema ainda roda em hardware e software antigos, cinco anos depois.
Jules

Felizmente, consegui permissão para corrigir o pior dos problemas (os ataques de injeção SQL, as tabelas SQL com milhões de linhas, mas sem índices , as páginas em que o desenvolvedor original havia esquecido de verificar a autorização ...).
Jules

3

Razões para não fazer grandes alterações:

Um: o código será desativado em alguns meses. Realmente valeria a pena o tempo da empresa para você passar 5 meses consertando um sistema que será descartado 1 mês depois? Advertência: Os sistemas raramente desaparecem quando estão programados para desaparecer. O sistema de substituição quase sempre está atrasado, existem usuários que não podem atualizar por qualquer motivo, etc. Mas esse é um problema complexo.

Dois: Se você fizer muitas alterações, principalmente pesquisas em massa e substituições, irá introduzir bugs. Não, você pode introduzir bugs: você irá. Suponha que você tenha feito um S&R e alterado "width = 200" para "width: 200px". Existe código C # ou VB nos seus pges ASP? Porque se você tivesse uma variável chamada "width" que estava configurando para 200, você a quebraria. (Ou, nesse caso, você pensou em limitar as páginas S&R para ASP?) Ou se você alterou "width: 200" para "width: 200px", o que acontece se houvesse um lugar no código que dizia "width: 200mm "? Agora diz "width: 200pxmm". Ok, vamos supor que você pensou nisso. E se houver algum lugar que tenha a especificação de largura inválida, que é obviamente ignorada, e que agora esteja bem definida. Voce conserta" a largura e agora apresenta 200px ... e a tela está estragada, porque 200px é de fato a largura errada para dar e só funcionou porque esse valor foi ignorado? Mass S&R's são muito perigosos, porque você quase certamente não está estudando todos os lugares que muda. Você provavelmente nem sabe ao certo o que testar.

Terceiro: código "obviamente" errado pode ser o que o usuário deseja. Eu já vi muitas especificações de requisitos que exigem um comportamento que é obviamente errado e insano ... e depois volto aos usuários e pergunto o que eles REALMENTE desejam, e acontece que eles realmente querem esse comportamento insano, porque é isso como seus negócios funcionam ou regulamentos governamentais exigem isso ou o que seja.

Mesmo que o comportamento esteja realmente errado, talvez os usuários esperem e rotineiramente o contornem e, ao corrigi-lo, você quebrará as soluções alternativas. Exemplo: eu trabalho em um sistema em que temos um local onde você especifica a partir de e até as datas em que uma venda está disponível ao público. Ambas as datas eram realmente a meia-noite que começou naquele dia. Portanto, se você disser "até 30 de julho", isso significava que terminava no final do dia 29 de julho, ou seja, um minuto antes das 12:01 de 30 de julho, e não no final de 30 de julho Em um ponto, eu consertei isso, mas só consegui fazer isso porque havia menos de meia dúzia de pessoas com autoridade para usar essa tela, e podia simplesmente contar a elas tudo o que havia consertado. Se houvesse centenas de usuários, e todos já tivessem descoberto que você realmente precisava dar o dia após a data limite, então minha "correção"


0

É claro que posso fazer uma busca e substituição global para eliminar a maioria dos problemas, mas isso significaria que meu primeiro commit consistiria em milhares de arquivos .asp alterados. Posso fazer isso?

Não vejo por que não. Um commit deve ser conceitualmente uma coisa, mas não vejo razão para que uma descoberta e substituição global de style="width=20"para style="width: 20px"não contem como "uma coisa", conceitualmente falando. E se isso ajudasse você a dormir melhor, evite que você se distraia ao consertar outras coisas e não estrague nada , por que não?


12
Por que não? Como uma ampla pesquisa e substituição em uma grande base de códigos herdada exige testes extensivos depois para garantir que nada ocorra.
JacquesB

-2

Seu problema é definir prioridades : quais dos problemas são obstáculos (em produção)? Quais são as bombas temporais? E o que pode ser deixado em um tempo mais longo (porque funciona e já o faz há anos, até mais ou menos)?

O que eu faria na sua situação seria fazer listas de classes de problemas que gostaria de examinar. Por exemplo, substituir style="width=(\d+)"por style="width: \1px"(que provavelmente pode ser corrigido com uma localização / substituição global usando regexp - desculpe se o meu não é 100%) seria uma classe e, se houver apenas uma ocorrência, que seja. Para cada categoria, liste uma prioridade (quão urgente é fazer isso) e uma estimativa do trabalho (quanto tempo levará para fazer essa categoria).

Suas tarefas de manutenção também aparecerão nesta lista. Agora você está começando a aplicar algum gerenciamento, mesmo que seja apenas para você, e você tem uma ferramenta para usar quando tiver tempo disponível e nada para fazer ou quando precisar negociar com o gerente sobre o trabalho a ser feito (ou solicitar tempo a ser alocado para algo que ele pode não estar ciente). (Esse tipo de proatividade pode ajudá-lo a ser notado pelas promoções, se bem feito.)

Eu acho que você gosta de programar porque tem uma personalidade perfeccionista leve, até certo ponto. MAS, em um ambiente comercial, você precisa começar a perceber que o perfeito é o inimigo do bem (e o bom traz dinheiro, o perfeito pode não necessariamente trazer muito mais para muito mais trabalho). Primeiro faça o que é necessário, depois faça o que é bom de ter. Sim, isso pode ir contra o seu grão sem fim. Apenas sorria e aguente, e talvez tenha um hobby para exercitar seu perfeccionismo e mantê-lo saudável ;-)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.