Quando o código é “legado”? [fechadas]

Eu prefiro o resumo da Wikipedia :

A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available.

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

But it's still used in the production systems - so is it really legacy? And what makes it legacy?

O fato de que ainda é usado na produção é precisamente 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 "aposentado", respectivamente. Legado significa que ainda está em uso e funciona bem, mas incorpora projetos ou técnicas que não estão mais em uso comum.

Qualquer código ou sistema que você quer (a) deseja 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 de código, isso significa significativas alterações no design, possivelmente usando um novo framework ou até mesmo uma nova plataforma.

Existem vários motivos pelos quais sistemas ou códigos podem se tornar legados:

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

• Falta de testes. Outra resposta faz referência à alegação hiperbólica de um autor popular de qualquer código não coberto por testes sendo 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 tornam-se tímidos e com medo de fazer grandes mudanças porque se preocupam em quebrar alguma coisa, o que leva ao "apodrecimento do software" acima.

• Rev-locking, um fator frequentemente negligenciado que é particularmente insidioso em projetos que usam grandes bibliotecas ou frameworks de código aberto (embora eu tenha visto isso acontecer com ferramentas comerciais também). Muitas vezes, haverá uma grande personalização feita na estrutura / biblioteca, tornando a 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 adicionado, nunca alterado. Como esses sistemas precisam ser reescritos para atualizar - ao contrário de revisões incrementais / iterativas - muitas empresas não se incomodarão.

Qualquer coisa que atrase ou interrompa as atualizações em uma base de código pode fazer com que a base de código se torne legada.

Agora, a questão 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:

Should we shy away from this unwarranted labelling of perfectly functioning code?

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

Em alguns casos, não há nada errado com o código legado. Não é uma palavra ruim. Código / sistemas legados não são maus. Eles apenas coletaram um pouco de poeira - às vezes um pouco, às vezes muito.

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

Geralmente, significa que está escrito em um idioma ou baseado em um sistema em que você normalmente não faz um novo desenvolvimento.

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

Legado significa que qualquer código que você prefira substitui do que o trabalho. 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 projeto grande onde você tem que codificar para um design congelado, mesmo o que você está escrevendo no momento pode ser incluído também).

1. A ênfase "em vez disso" pretende transmitir esse código legado também significa que você está preso a trabalhar com ele, embora prefira não. Não tenho certeza se a ênfase foi suficiente. Razões para isso podem variar. Alguns realmente são 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 eu talvez não tenha enfatizado o suficiente é que, embora a qualidade do código possa ser um fator, raramente (ou nunca) é o único fator - e muitas vezes nem mesmo um fator particularmente importante.
3. Acho que as pessoas testando testes de unidade como o fator determinante são como o cara olhando sob a luz da rua para o brinco, sua esposa caiu a um quarteirão de distância. A luz pode ser melhor, mas você ainda está procurando no lugar errado. Pense antes de você beber o Kool-Aid .
4. (Um corolário para 3.) Parece-me que algumas pessoas estão falando mais sobre como desejam que as coisas fossem do que como realmente são. Se John Conways ' Jogo da Vida para um Apple IIc Plus não é legado, é porque é suficientemente pequeno e simples que é fácil reimplementar a partir do zero. O teste de unidade mais perfeito já escrito não altera esse iota .

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

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

Talvez um exemplo disso ajude: vamos supor que um programa tenha uma biblioteca de interface do usuário com excelentes testes de unidade, e vários programas que usam essa biblioteca. Alguém na alta administração se convence de que a "web enabled" é importante (e, apenas por uma questão de argumento, vamos supor que, neste caso, ele está realmente certo sobre isso). Após uma análise cuidadosa, os gerentes do meio descobrem que o teste de unidade atual é suficiente para mudar de uma interface de usuário exibida através do recurso de janelas do sistema operacional local para ser exibido remotamente via HTML / CSS / AJAX, mantendo toda a validação de entrada original.

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

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

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 isso é realmente necessário. Ao mesmo tempo, a velha linha sobre martelos e pregos praticamente me lembra. Pode ser ainda pior quando você não só tem um martelo, mas tem um monte de experiência com este martelo, e sabe que é realmente um martelo de alta qualidade que funciona incrivelmente bem. em muitas situações diferentes. O simples fato de ser tão bom em tantas coisas em tantas situações torna ainda mais difícil reconhecer quando é completamente a ferramenta errada para o trabalho em questão.

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

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

• Não pode ser estendido sem esforço maciço
• Não é possível migrar facilmente para novo hardware
• É muito importante 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 de Perl dos seus antecessores, eu simpatizo, mas não acho que seja legado. Eu recentemente modernizei um script Perl de 15 anos de idade que estava ligado a um obsoleto banco de dados Sybase . Foi um bolo comparado a fazer até mesmo a menor alteração no nosso horrível sistema de contabilidade COBOL .

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

Tecnicamente, legado é qualquer código que esteja pronto escrito. Então, assim que estiver em produção, é legado. Porque já existe valor lá, você não pode simplesmente jogar fora ... Você tem que lidar com isso.

É "antes do tempo", mas "ainda está com dor de cabeça" .

O código legado é um código que permanece na base de código porque muitas coisas parariam de funcionar de outra forma. 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 vai quebrar todo o código contando nele (que pode ser um código que você não pode adaptar de acordo). Portanto, você tem que mantê-lo (e às vezes até mesmo mantê-lo), mas você deseja que todo código novo não seja escrito contra ele.

Um exemplo são os métodos obsoletos da API de uma biblioteca. Eles ainda estão lá, de modo que, se quem atualizar a biblioteca ainda puder construir seu projeto, eles serão marcados como obsoletos e o compilador deverá fornecer um aviso.

Outro exemplo são todos aqueles truques estranhos que a Microsoft faz para executar programas que foram escritos para versões do sistema operacional que eles desaprovaram completamente. O auge deste ser:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
-- Joel on Software

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

Todas as outras considerações descendem 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 / SO em que ele roda for antigo e tiver sido descontinuado pelo fornecedor - ataque 1.

Se é mais trabalho tentar corrigi-lo, do que reescrevê-lo, por qualquer motivo, porque

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

para fazer isso

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

Ataque 2.

Uma fusão de várias organizações em uma só - o Strike 3 - um lado provavelmente será rotulado como legado.

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 onde a consistência é valorizada em relação à nova tecnologia 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 for uma pequena empresa de desenvolvimento que continua aprimorando / dando suporte ao aplicativo para fazer o que os clientes precisam, ele é considerado código legado ou apenas código "antigo". Eu conheço uma empresa chamada Mc2Ok - eles desenvolveram o software no que parece ter sido o Windows 3.1, e continuaram carregando-o para a frente. Ele ainda tem uma aparência do Windows 3.1, mas eles também adicionaram uma interface da Web a ele. É uma empresa de desenvolvimento de dois homens (eu acho), e eu diria que quando eles deixarem de trabalhar nela, então será considerado legado, e o tempo para migrar um ano ou dois depois de usá-lo. Mas isso poderia ser mais 10 ou mais anos.

Às vezes, quando o gerenciamento muda, ele pode mudar em ondas que têm muitos efeitos de gotejamento ... Dependendo da influência do novo gerenciamento, ele pode renderizar muitos aplicativos legados que, de outra forma, poderiam estar bem.

Cada organização, acredito, precisa definir o que 'código herdado' significa para eles. Eu costumava consultar os The Sunday Times todas as semanas para ver o que as organizações estavam procurando. Esse costumava ser meu barômetro para o que não era mais relevante (isto é, legado). Bem, The Sunday Times não é mais relevante :-) E podemos generalizar que COBOL é legado, ASP Classic é legado, etc ... Mas acredito que cada organização tem que decidir quando uma inscrição é considerada legada.

O código é legado quando se tem medo de mudá-lo, porque ele pode quebrá-lo. É ainda mais doloroso quando todo o sistema pode ser controlado por mudanças nesse código.

É por isso que também concordo com a definição de Michael Feathers. O código que tem 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.