Quando o código é "herdado"? [fechadas]

Todos nós fizemos isso, rotulamos algum código (geralmente coisas que herdamos) como "legado"? Mas ainda é usado nos sistemas de produção - então é realmente legado? E o que o torna legado? Devemos evitar essa rotulagem injustificada de código que funciona perfeitamente; onde a rotulagem é uma conviniência pura que nos permite avançar com coisas novas e manter a gerência superior agradável e feliz?

Resumo das respostas

Analisando as respostas, vejo quatro temas gerais. Aqui está como eu vejo a repartição:

1. Qualquer código que foi entregue: 6
2. Sistemas mortos: 2.5
3. Sem testes de unidade: 2
4. Os desenvolvedores não estão por perto: 1.5

Sou um pouco parcial do resumo da Wikipedia :

Um sistema legado é um método, tecnologia, sistema de computador ou programa de aplicativo antigo que continua a ser usado, normalmente porque ainda funciona para as necessidades dos usuários, mesmo que agora estejam disponíveis tecnologias mais recentes ou métodos mais eficientes de executar uma tarefa.

Muito do que as outras pessoas estão descrevendo em suas respostas são razões pelas quais o código se torna "legado". Mas a questão essencial em si é esta:

Mas ainda é usado nos sistemas de produção - então é realmente legado? E o que o torna legado?

O fato de ainda ser usado na produção é exatamente o que o torna legado . Se o código não funcionar corretamente ou não for mais usado na produção, esse código será "quebrado" ou "retirado", respectivamente. Legado significa que ele ainda está em uso e funciona bem, mas incorpora projetos ou técnicas que não são mais de uso comum.

Qualquer código ou sistema que você (a) gostaria de atualizar / atualizar, mas não pode, ou (b) ainda está no meio da atualização, é um sistema legado. Isso não significa refatoração ou limpeza geral do código, significa mudanças significativas no design, possivelmente usando uma nova estrutura ou mesmo uma nova plataforma.

Há várias razões pelas quais sistemas ou código podem se tornar herdados:

• Falta de manutenção regular ou apodrecimento do software . Claramente, se o aplicativo não for mantido regularmente, ele não acompanhará as principais mudanças no mundo do software. Isso pode ser devido à simples negligência ou pode ser uma escolha deliberada com base nas prioridades de negócios ou restrições orçamentárias.

• Falta de teste. Outra resposta faz referência à alegação hiperbólica de um autor popular de qualquer código não coberto por testes como código legado. Isso realmente não é uma definição precisa, mas é uma possível causa raiz; sem bons testes (automatizados ou manuais), os desenvolvedores ficam tímidos e com medo de fazer grandes alterações porque se preocupam em quebrar alguma coisa, liderando a "podridão do software" acima.

• Rev-locking, um fator frequentemente esquecido, particularmente insidioso em projetos que utilizam grandes bibliotecas ou estruturas de código aberto (embora eu tenha visto isso acontecer com ferramentas comerciais também). Freqüentemente, haverá grandes customizações na estrutura / biblioteca, tornando uma atualização proibitivamente difícil ou cara. Assim, o sistema se torna legado porque é executado em uma plataforma mais antiga (e possivelmente não mais suportada).

• O código fonte não está mais disponível, o que significa que o sistema só pode ser incluído, nunca alterado. Como esses sistemas precisam ser reescritos para atualizar - em vez de revisar de forma incremental / iterativa - muitas empresas não se incomodam.

Qualquer coisa que diminua ou interrompa as atualizações em uma base de código pode levar a essa base de código a se tornar herdada.

Agora, a pergunta separada, não declarada, mas implícita é: o que há de errado com o código legado? É frequentemente usado como um termo pejorativo, daí a pergunta:

Devemos evitar essa rotulagem injustificada de código que funciona perfeitamente?

E a resposta é não, não devemos; a rotulagem é garantida e o próprio termo implica claramente código de funcionamento. O ponto não é que é função, mas como está funcionando.

Em alguns casos, não há nada de errado com o código herdado. Não é uma palavra ruim. Os sistemas / códigos legados não são maus. Eles acabaram de coletar poeira - às vezes um pouco, às vezes muito.

O legado se torna obsoleto quando o sistema não pode mais atender (todas) as necessidades do cliente. Esse rótulo é um dos quais precisamos ter cuidado. Caso contrário, é simplesmente uma equação de custo / benefício; se o custo da atualização for menor que o custo de seus benefícios (incluindo menores custos futuros de manutenção), faça a atualização; caso contrário, deixe em paz. Não é necessário cuspir a palavra "legado" no mesmo tom que você normalmente reserva para "auditoria fiscal". É uma situação perfeitamente aceitável.

Normalmente, isso significa que está escrito em um idioma ou com base em um sistema no qual você normalmente não desenvolve um novo desenvolvimento.

Por exemplo, a maioria dos lugares não escreve novos programas no Cobol. No entanto, grande parte de seus negócios pode ser executada em aplicativos escritos em Cobol. Portanto, esses aplicativos são rotulados como "Legados".

Legado significa qualquer código que você prefira substituir do que trabalhar. Dada a atitude da maioria dos programadores em relação à maioria dos códigos existentes, isso geralmente inclui quase tudo, exceto o que você está escrevendo ativamente no momento (e em um grande projeto em que você precisa codificar para um design congelado, mesmo o que está escrevendo no momento também pode ser incluído).

1. A ênfase "em vez" tem como objetivo transmitir que o código legado também significa que você está preso a trabalhar com ele, mesmo que prefira não. Não tenho certeza se a ênfase foi suficiente. Razões para isso podem variar. Alguns são realmente grandes e complexos demais para serem substituídos. Outros são interfaces para outros sistemas. Outros ainda são movidos por políticas e personalidades (por exemplo, o código é horrível, mas o bebê do estande era incrível).
2. Outro ponto que talvez eu não tenha enfatizado suficientemente é que, embora a qualidade do código possa ser um fator, raramente (se é que alguma vez) é o único fator - e geralmente nem mesmo é particularmente importante.
3. Acho que as pessoas que fazem testes unitários como o único fator determinante são como o cara que procura sob a luz da rua o brinco que sua esposa deixou a um quarteirão de distância. A luz pode ser melhor, mas você ainda está procurando no lugar errado. Pense antes de beber o Kool-Aid .
4. (Um corolário de 3.) Parece-me que algumas pessoas estão falando mais sobre como elas desejavam que as coisas eram do que realmente são. Se o Jogo da Vida de John Conways para um Apple IIc Plus não é legado, é porque é suficientemente pequeno e simples que é fácil reimplementar desde o início. O teste de unidade mais perfeito já escrito não vai mudar isso um único iota .

O último ponto leva a outros dois pontos que eu acho que muitas vezes são verdadeiros.

Primeiro, o código geralmente é mantido como legado, mesmo quando realmente não deveria ser. Os gerentes de nível superior geralmente assumem que a reimplementação de um sistema custará tanto ou mais que a implementação inicial, o que raramente é verdade.

Segundo, os testes de unidade são uma faca de dois gumes. Eles tornam muito fácil pensar que as mudanças localizadas na implementação são o que realmente importa. Para fazer melhorias significativas em um sistema maior, você freqüentemente (normalmente?) Precisa alterar o design geral o suficiente para que muitos (se não a maioria) dos testes de unidade se tornem irrelevantes. Infelizmente, a presença de testes de unidade e a atitude que eles geram podem facilitar demais ignorar as mudanças realmente necessárias.

Talvez um exemplo disso ajude: suponha que um programa tenha uma biblioteca de interface do usuário com ótimos testes de unidade e vários programas que usam essa biblioteca. Alguém na alta gerência se convence de que "a Web habilitada" é importante (e, apenas por uma questão de argumentação, vamos supor que, nesse caso, ele esteja realmente certo sobre isso). Após uma análise cuidadosa, os gerentes de nível médio descobrem que seus testes de unidade atuais são suficientes para que possam mudar de uma interface do usuário exibida através da capacidade de janelas do sistema operacional local para serem exibidos remotamente via HTML / CSS / AJAX, mantendo toda a validação de entrada original.

Isso é ótimo, não é? Mostra como o teste de unidade pode ser útil. Trocamos toda a implementação de toda a interface do usuário, mas garantimos que a aparência, a funcionalidade e a aparência permaneçam praticamente consistentes, e toda a entrada do usuário seja validada para garantir a integridade dos dados. O teste de unidade salvou o dia!

Ou não! Essa excelente, altamente flexível e cuidadosamente testada unidade de biblioteca de interface do usuário ajudou a cegar todos os envolvidos com o fato de que, para esse programa em seu mercado com seus usuários, uma interface do usuário baseada na Web é a coisa totalmente errada para se trabalhar. O que é realmente necessário é um serviço da web com uma interface RESTful e absolutamente nenhuma interface de usuário própria.

Agora, certamente é verdade que o teste de unidade não remove, por si só, a capacidade das pessoas de entender seu mercado ou perceber que é realmente necessário. Ao mesmo tempo, a velha linha sobre martelos e pregos vem à mente. Pode ser ainda pior quando você não apenas tem um martelo, mas tem muita experiência com esse martelo e sabe que é realmente um martelo de alta qualidade que funciona incrivelmente bem em muitas situações diferentes. O fato de ser tão bom em tantas coisas em tantas situações torna ainda mais difícil reconhecer quando é a ferramenta errada para o trabalho em questão.

O código legado geralmente fica órfão de alguma forma. O desenvolvedor principal, o único que entendeu, foi atropelado por um ônibus, e suas anotações foram escritas em seu dialeto ucraniano nativo, que agora é um idioma morto. Ou, alternativamente, qualquer coisa escrita no Visual Basic 6.0 .

Eu trabalho no código legado o tempo todo. Eu diria que as características são:

• Não pode ser estendido sem grande esforço
• Não pode ser facilmente migrado para um novo hardware
• É muito crítico para os negócios ser facilmente substituído

Se não tiver essas características, provavelmente não é legado. Se você não gosta dos scripts Perl dos seus antecessores , eu simpatizo, mas não acho que seja legado. Recentemente, modernizei um script Perl de 15 anos que estava associado a um banco de dados obsoleto da Sybase . Isso foi demais comparado a fazer a menor alteração no nosso terrível sistema de contabilidade COBOL .

Em seu livro, Trabalhando efetivamente com o código herdado , Michael Feathers define o código herdado como um código que não é coberto por testes de unidade. Essa é uma definição, com a qual concordo. Também vejo o código legado como antigo, mas ainda utilizável.

Tecnicamente, legado é qualquer código pronto para escrita. Assim, logo que está em produção, é legado. Porque já existe valor lá, você não pode simplesmente jogá-lo fora ... Você tem que lidar com isso.

É "antes do seu tempo", mas "ainda é sua dor de cabeça" .

Código legado é o código que permanece apenas na base de código, porque muitas coisas parariam de funcionar de outra maneira. Em outras palavras: a única razão de ser é a compatibilidade com versões anteriores.

Você prefere alterá-lo ou até jogá-lo fora, mas não pode, porque você quebrará todo o código contido nele (que pode ser um código que você não pode adaptar adequadamente). Portanto, você deve mantê-lo (e às vezes até mantê-lo), mas deseja que todo o novo código não seja escrito contra ele.

Um exemplo são métodos preteridos da API de uma biblioteca. Eles ainda estão lá, portanto, se quem atualiza a biblioteca ainda pode criar seu projeto, mas eles são marcados como obsoletos e o compilador deve lhe dar um aviso.

Outro exemplo são todos aqueles truques estranhos que a Microsoft faz para executar programas que foram escritos para versões de seus sistemas operacionais que foram completamente reprovados. O auge deste ser:

A primeira vez que ouvi falar disso foi de um dos desenvolvedores do jogo de sucesso SimCity, que me disse que havia um bug crítico em seu aplicativo: ele usava memória logo após liberá-lo, um grande não-não que funcionava bem no DOS, mas não funcionaria no Windows, onde a memória liberada provavelmente será recuperada por outro aplicativo em execução imediatamente. Os testadores da equipe do Windows estavam passando por vários aplicativos populares, testando-os para garantir que funcionassem bem, mas o SimCity continuava travando. Eles relataram isso aos desenvolvedores do Windows, que desmontaram o SimCity, o percorreram em um depurador, encontraram o bug e adicionaram um código especial que verificava se o SimCity estava em execução e, se funcionava, executava o alocador de memória em um modo especial no qual você ainda pode usar a memória após liberá-la.
- Joel em Software

Legado implica herança. O código legado é simplesmente o código que você herda do passado. É um código legado, mesmo que você tenha escrito antes!

Todas as outras considerações decorrem basicamente do fato de você não ter escrito especificamente para o seu projeto atual. Não é necessariamente uma coisa ruim em si.

Minha opinião é que o que é considerado código legado depende de várias coisas, e a tag 'legado' provavelmente é específica da organização.

Se o hardware / sistema operacional em que ele é executado for antigo e tiver sido descontinuado pelo aviso do fornecedor 1.

Se for mais trabalhoso tentar corrigi-lo do que reescrevê-lo, por qualquer motivo, porque

• os desenvolvedores originais se foram
• o programa está mal escrito
• isso pode ser feito melhor em uma plataforma mais nova e ainda vale a pena para a empresa

fazer isso

• a fonte original não está mais disponível e / ou faltam peças

Greve 2.

A fusão de várias organizações em um lado - Greve 3 - provavelmente será marcada como legada.

Existe uma alternativa melhor e mais barata vendida como aplicativo e / ou serviço de terceiros - greve 4.

A organização é algo como um hospital ou um distrito escolar em que a consistência é valorizada em relação às novas tecnologias quando se trata de operações diárias? Levará mais tempo para que um aplicativo seja considerado legado em comparação com o mesmo aplicativo em uma organização comercial / competitiva.

Se a empresa é uma pequena empresa de desenvolvimento que continua aprimorando / dando suporte ao aplicativo para fazer o que os clientes precisam, é considerado código legado ou apenas código "antigo". Conheço uma empresa chamada Mc2Ok - eles desenvolveram o software no que parece ter sido o Windows 3.1 e apenas continuaram levando-o adiante. Ele ainda possui uma aparência e funcionalidade do Windows 3.1, mas eles também adicionaram uma interface da web. É uma empresa de desenvolvimento de dois homens (eu acho), e eu diria que quando eles pararem de trabalhar nela, será considerado legado e tempo para migrar um ano ou dois depois de usá-lo. Mas isso pode levar mais 10 anos ou mais.

Às vezes, quando o gerenciamento é alterado, ele pode mudar em ondas com muitos efeitos escassos ... Dependendo da influência do novo gerenciamento, ele pode tornar muitos aplicativos herdados que, de outra forma, poderiam ser bons.

Cada organização, acredito, precisa definir o que 'código legado' significa para elas. Eu costumava pesquisar nos classificados do The Sunday Times toda semana para ver o que as organizações estavam procurando. Esse costumava ser meu barômetro para o que não era mais relevante (ou seja, legado). Bem, o Sunday Times não é mais relevante :-) E podemos generalizar que COBOL é legado, ASP Classic é legado, etc ... Mas acredito que cada organização precisa decidir quando um aplicativo é considerado legado para ele.

Código é legado quando alguém tem medo de alterá-lo, porque ele pode quebrá-lo. É ainda mais doloroso quando todo o sistema pode ser afetado por alterações nesse código.

É por isso que também concordo com a definição de Michael Feathers. Código com bons testes de unidade pode ser alterado sem medo.

Eu também acho que o código legado não tem nada a ver com a idade. Pode-se escrever código legado desde o início.