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


63

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


11
É um código legado assim que é entregue e está funcionando.
Martin Beckett

23
é código legado se você não escrevê-lo ;-)
Steven A. Lowe

20
É um código legado se todos que o escreveram estão aposentados ou mortos, e se aqueles que continuam mantendo o desejam, desejam. Caso contrário, é chamado de base de código existente.
Unpythonic

3
@ StevenA.Lowe, dado tempo suficiente, é um código legado, mesmo que eu o tenha escrito.
22713 Kyralessa

Respostas:


43

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.


Dito isto, a auditoria tributária também deve ser uma situação perfeitamente aceitável.
Florian Margaine

Eu diria: Sistema que não pode mais ser escalável com a pilha de tecnologia existente.
precisa

40

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".


Eu concordo com esta resposta mais. O legado é mais sobre ficar preso em uma plataforma obsoleta do que ser um código irritante (ainda moderno) que você não deseja oferecer suporte. O código legado geralmente é muito bom (caso contrário, ninguém se importaria se você o deixasse para trás!), Mas geralmente é associado a hardware obsoleto e a linguagens / bibliotecas / bancos de dados / etc antiquados.
23411 Satanicpuppy

3
@Satanicpuppy: Eu simplesmente não posso concordar - eu lidei com (por exemplo, um pouco de Java) que definitivamente não estava vinculado a nenhum hardware, biblioteca ou banco de dados em particular -, mas era o "legado" possível (e era sendo reescrito em Java, então a linguagem também não era o problema). Eu também lidou com um código que foi amarrado a um hardware específico, mas ainda só foi mal afiação na categoria "legado".
Jerry Coffin

4
@ jerry: Então, o que o tornou legado? Legado não é sinônimo de "ruim".
2361111 Satanicpuppy

11
No caso em que estou pensando, era um sistema distribuído bastante grande (construído em torno do BEA Tuxedo). O design parecia baseado em cenários de livros de texto destinados a ensinar sobre sincronização, maximizando o número de vezes / locais em que a sincronização é necessária. Isso (mais ou menos) faz sentido para um livro de texto, mas é horrível para projetos reais. Era grande o suficiente para que até arquitetar uma substituição fosse um projeto de vários anos. A substituição teve que ser feita em fases sem tempo de inatividade, porque o sistema era totalmente necessário para os negócios.
Jerry Coffin

11
@Cawas: Parece-me que a resposta de @ Chad se aplicaria quando / se o novo sistema estivesse sendo executado em um idioma diferente ou usando hardware diferente, etc. Isso estava sendo re-desenvolvido ainda usando Java, ainda usando Tuxedo, etc. Eu não vejo isso como aplicação.
Jerry Coffin

28

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.


3
Veja, agora não sei se vou marcar isso ou não, infelizmente isso é verdade, mas me pergunto se é uma atitude da qual precisamos nos afastar ...
Nim

+1. Eu estava prestes a responder algo na mesma medida. Legado é qualquer código usado em vez de mantido ativamente.
Denis de Bernardy

@ Nim: Eu não acho que é uma atitude que "nós" precisamos fugir. É uma mera afirmação do óbvio. :-) Pense por um momento e pergunte-se o que você consideraria um código legado se você chegasse a um novo ambiente; será tudo, exceto as coisas novas e legais que estão sendo ativamente desenvolvidas.
Denis de Bernardy

@ Jerry, então você não gosta de testes de unidade, então? ;)
Nim

11
@ Nim: Não é assim - acho que são úteis, mas muito aquém da panacéia como frequentemente retratada.
Jerry Coffin

17

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 .


Assustador, nosso desenvolvedor líder também é ucraniano ... haha ​​... Concordo com a parte intermediária da sua resposta, o primeiro ponto - nem tanto - acho que depende de como a sua equipe de desenvolvimento está configurada.
Nim

11
lol, você provavelmente conseguiu ofender (motoristas de ônibus, o idioma ucraniano e os desenvolvedores do VB6) em um único parágrafo. Mas caramba, eu ri :) #
0000 Darknight

Sou um viajante do tempo a partir de 1999, você quer dizer que o Visual Basic 6 é legado a partir de 2011?
Hjk

@hjk Eu diria que praticamente qualquer coisa após o advento do C # / asp.net em 2005 seria em terreno movediço, mas certamente uma vez que o fim do suporte da Microsoft rolava em 2008.
Satanicpuppy

12

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.


24
Isso me parece um caso de tentar definir "qualquer coisa que não siga a metodologia escolhida" como "legado". É nada mais ou menos do que uma tática de debate barata, basicamente apenas pegando a lei de Godwin e suavizando a linguagem (apenas) o suficiente para impedir que os leitores reconheçam instantaneamente que não é nada além de um ataque não suportado (e muitas vezes insuportável) a todos que não seguem suas preferências.
Jerry Coffin

4
@ Jerry: Eu concordo com a definição de Feather. Código sem testes de unidade é um horror para se trabalhar. Se você decidir refatorar algumas partes, para que fique mais fácil argumentar sobre isso, esqueça! você pode estar introduzindo bugs e o código provavelmente do jeito que está é não testável! Acho que a definição de Feather não é convencional, mas ele é alguém que ganha a vida trabalhando com código legado.
devorado elysium

10
@ devoured: os testes de unidade não são um teste preciso para a capacidade de trabalhar com código. Eu lidei com o código que carecia de testes de unidade, mas era fácil - e com o código que tinha testes de unidade - e ainda era um pesadelo. Por fim, os testes de unidade não resolvem nada por si mesmos. Os testes de unidade para um projeto no qual (por exemplo) a divisão em unidades foi mal realizada ainda podem ser totalmente inúteis, e todo o projeto (incluindo testes) precisa ser descartado e substituído para produzir algo útil.
21411 Jerry Coffin

6
Eu concordo com os comentários de Jerry. A ausência de testes de unidade é apenas um dos vários odores de código que podem (ou não ) indicar mal.
smci

4
Concordo novamente com a definição de Feather e também comi. Ausência de teste de unidade é tudo, pois isso significa que até o trecho de código mais bonito está faltando nas especificações. Os testes de unidade são 51% da documentação e 100% da especificação do código. Um código que falta a maior parte é sua documentação e todas as suas especificações devem ser corretamente classificadas como legadas.

8

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" .


5

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


4

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.


O passado pode ser de 1 dia, 1 hora ou 1 ano. Isso não torna legado.
Vince Panuccio

2

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.


+1, resposta boa - melhor considerar algo legado a partir da perspectiva do org ...
Nim

0

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.

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.