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?
fonte
Respostas:
Parece que você está confundindo várias coisas com o termo "erros"
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:
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
fonte
... JFDI ...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.
fonte
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.
fonte
s/weeks/years/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"
fonte
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"parastyle="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?fonte
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+)"porstyle="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 ;-)
fonte