Em conjunto: como manteremos os sistemas legados? [fechadas]

NOVA YORK - Com uma explosão que fez tremer os arranha-céus, um cano de vapor de 83 anos enviou uma mensagem poderosa de que os quilômetros de tubos, fios e ferro sob Nova York e outras cidades dos EUA estão envelhecendo e podem se tornar perigosamente instáveis.

História de julho de 2007 sobre um cano de vapor estourado em Manhattan

Ouvimos falar sobre podridão de software e dívida técnica .

E ouvimos de pessoas como:

• "Tio Bob" Martin - Quem nos alertou sobre " as consequências de fazer uma bagunça ".
• Michael C. Feathers - Quem nos deu orientação para 'Trabalhar efetivamente com o código legado' .

Portanto, certamente a comunidade de engenharia de software está ciente desses problemas.

Mas sinto que nossa sociedade agregada não aprecia como essas questões podem afetar os sistemas e aplicativos de trabalho.

Como Steve McConnell observa :

... Diferentemente da dívida financeira, a dívida técnica é muito menos visível e, portanto, as pessoas têm mais facilidade em ignorá-la.

Se isso é verdade, e acredito que seja, então temo que governos e empresas adiem a manutenção e fortificação regulares contra hackers até que seja tarde demais. [Muito parecido com Nova York e os canos de vapor.]

Minha pergunta:

• Existe uma maneira de evitarmos o equivalente em software de Nova York e os canos de vapor?

Um problema-chave relacionado à manutenção de sistemas legados é a falta de pessoas que a) estejam atualizadas nesses sistemas eb) dispostas a continuar mantendo-os.

Recentemente, fiz uma pergunta em linhas semelhantes sobre se os programadores mais jovens estavam interessados ​​nos mainframes. O consenso inclinou-se para não.

A manutenção de sistemas legados é vista como suicídio na carreira. Em muitas empresas onde a inércia governa, há pouco investimento em treinar a equipe para permanecer no topo desses sistemas, levando a pontos únicos de falha do lado pessoal. Muitas pessoas que conheço que trabalham em sistemas similares estão procurando rotas, porque não veem futuro a longo prazo nos sistemas e apenas veem prejuízo na carreira.

Em algumas indústrias, os regulamentos de manutenção de dados podem ser um fator-chave para garantir que os sistemas legados sejam razoavelmente vigiados. Esta é particularmente a questão do setor financeiro, eu acho. Esses regulamentos - que eu saiba - geralmente são de tempo limitado.

No entanto, acho que na prática o que acontecerá é:

Chegará um ponto no gráfico em que o custo de passar para um sistema mais moderno, que permita rotear as desvantagens de um sistema legado, ficará abaixo do custo de manutenção do sistema legado, porque é mais barato.

A IBM está vendendo muitos mainframes no momento e está trabalhando duro para garantir que suas grandes máquinas não excluam os profissionais mais jovens. Mas não acho que seja suficiente nesta fase. Eles possuem alguns USPs em termos de pegada de carbono e poder de processamento real.

No entanto, para cada pessoa que compra um mainframe IBM porque você pode executar o Linux nele, custa menos em eletricidade e é altamente eficiente, você terá vários outros que escolherão um farm de servidores porque estão mais familiarizados com esse mundo e muitos outros programadores também.

Em última análise, muito depende da indústria envolvida. Eu trabalho em um setor específico, que depende muito de mainframes há anos e anos e eles ainda são amplamente utilizados. Porém, as soluções hospedadas estão se tornando mais populares, o que permite a consolidação de habilidades em empresas maiores - isso elimina alguns dos problemas enfrentados por empresas individuais em termos de pontos de falha - e, além disso, alguns fornecedores estão olhando fortemente para soluções não baseadas em mainframe para os problemas inerentes a essa indústria.

Então, suponho que, em resumo, o que estou dizendo é que, em geral, haverá uma mudança em direção à migração de sistemas legados assim que um ponto econômico de manutenção versus migração cair em favor da migração. No entanto, será em grande parte invisível para muitas pessoas, porque não é novo e descolado e não tem uma face muito pública da mesma maneira que uma grande novidade. Essa migração pode ser para provedores de serviços ou para novas tecnologias (especialmente onde os provedores de serviços são os diretamente afetados).

Minha experiência - principalmente em redes - é que existe uma medida para remover a dependência de sistemas legados.

A maioria das empresas já ignora as dívidas técnicas e nem percebe que as coisas estão ruins até que literalmente entre em colapso e as leve à falência (se é que chega a esse ponto). Eu realmente viisso aconteceu e não foi bonito; o que piorou foi o fato de eu tentar repetidamente conscientizar os proprietários da empresa sobre a crescente dívida técnica e que ela teria que ser corrigida, e toda vez que ela era rejeitada devido à falta de vontade de gastar o tempo e os recursos necessários para consertar isto. O resultado final foi que, após mais de 10 anos, o sistema finalmente falhou catastroficamente (depois que eu saí) e eles não conseguiram se recuperar e fecharam o negócio, porque eram estúpidos demais para perceber, nesses dez anos, que gastar um pouco de dinheiro para corrigir o problema teria sido melhor do que ignorá-lo completamente. Eu podia reclamar por horas sobre a estupidez absurda daquela empresa, e o que mais me doeu foi que poderia ter sido totalmente evitado se os proprietários não estivessem apenas para ganhar dinheiro rapidamente cortando todo o resto.

É insanamente difícil tentar dizer a uma empresa se seus sistemas estão mal gravados e precisam de alguma refatoração pesada (se não uma reescrita total, que normalmente é o caso porque é tão ruim). Na maioria das vezes, eles simplesmente derrubam você, mesmo que você os avise que é difícil fazer alterações ou adicionar novos recursos (da maneira certa, quero dizer, não apenas colocar mais lixo na pilha), ou até mesmo considerá- lo um prejudicar os negócios porque você vê problemas com o sistema em seu estado atual.

Sinceramente, cheguei à conclusão de que é uma batalha perdida e que não vale a pena lutar. As pessoas inteligentes o suficiente para saber sobre a dívida técnica não precisam ser informadas duas vezes sobre ela e estão cientes dos perigos desde o início, e todo mundo não escuta nenhum tipo de razão ou aviso até que seja tarde demais. A melhor opção (e claro, a mais irrealista) seria deixar a seleção natural entrar em ação e deixar as pessoas ignorantes serem extintas, deixando apenas as inteligentes. Não conheço nenhuma maneira mais realista de lidar com isso, porque tudo o que tentei pessoalmente no passado foi completamente ignorado, reduzi meu valor aos olhos da empresa (por "reclamações") ou até mesmo resultou em minha rescisão porque estava "muito focado" em consertar "o que não é ' quebrado e ninguém mais teve o estado de espírito adequado para ver que estava quebrado.

Os quilômetros de tubos, fios e ferro sob Nova York e outras cidades dos EUA estão ficando mais velhos e podem se tornar perigosamente instáveis.

Para a anedota, o mesmo argumento foi feito em Paris no século 16-17. Tantos buracos e túneis foram cavados por baixo (além dos buracos naturais devido à geologia da área) que um edifício ocasional desmoronava.

No momento em que quarteirões inteiros da cidade estavam desabando no chão, haviam sido dadas diretrizes para preencher os buracos e túneis desnecessários com cascalho e ossos (eles também tinham problemas de cemitério superlotados). A cidade sobreviveu assim até que o concreto foi inventado.

O que quero dizer aqui é que muitas organizações tendem a esperar o último minuto para fazer qualquer manutenção de software, mas os codificadores (como engenheiros civis) fazem o trabalho de maneira rápida e eficaz.

Nós sobrevivemos ao bug do Y2k. O bug do Y2036 forçará muitas organizações a atualizar seu hardware e software. O mundo poderia acabar em 2012. Mas os cientistas da computação não são sociólogos ou críticos literários .

Ah, e como diz o ditado: escreva código como se o próximo mantenedor fosse um psicopata cruel que sabe onde você mora.

Eu esqueço, o que consideramos código legado hoje em dia? Código do ano passado, código da última década ou código do século passado?

O dinheiro dirige a conversa em torno da manutenção de sistemas legados. A dívida técnica assume sua forma como um custo aumentado para alterar o sistema.

Eu trabalhei com sistemas mal projetados e inteligentemente projetados. O interessante é que os custos para mantê-los não variam muito. Os maiores problemas são arquiteturas incorretas para uso atual, que geralmente aparecem em problemas de dimensionamento ou quando uma grande alteração é desejada. Você não converte facilmente uma grande área de código de thread único para multi-thread.

Os problemas mais significativos que experimento são as linguagens de desenvolvimento usadas. Os sistemas mais antigos são escritos em idiomas menos populares atualmente, então você precisa treinar mais ou contratar mais recursos raros e experientes. Em qualquer um dos casos, por causa do pool menor, você também luta para encontrar pessoas qualificadas que tendem a gerar tantos problemas quanto soluções.

Quanto à reescrita prometida, a maioria dos sistemas que tiveram grandes investimentos não justifica uma reescrita. É incrível quanto tempo o software pode ser mantido funcionando e aprimorado. Alterações de hardware (alguns sistemas que minha empresa suporta usam hardware especializado) tendem a ser nosso maior problema. A capacidade de aprimoramento geralmente é limitada apenas pelos mecanismos para integrar o código legado aos novos recursos.

Este já é um grande problema. E não mostra sinais de mudança.

Nos anos 60 e 70, grandes instituições de todos os tipos passaram de contabilidade em papel para contabilidade em sistemas de computação. De maneira esmagadora, eles escolheram COBOL. A maioria ainda está usando versões atualizadas desses sistemas COBOL. Veja http://cis.hfcc.edu/faq/cobol para algumas estatísticas sobre este

De vez em quando recebemos lembretes aleatórios disso, como quando Arnold Schwarzenegger descobriu há alguns anos atrás que ele não podia simplesmente cortar o pagamento de 200.000 trabalhadores estaduais sem seis meses de desenvolvimento primeiro (consulte http://www.infoworld. com / d / developer-world / californias-cobol-conundrum-067 para verificação).

Dados os riscos da mudança, é muito difícil justificar a alteração desses sistemas. Sempre. Essa tem sido a realidade para a minha vida. Mas não vejo razão para esse fato mudar na vida de meus filhos. Ou a vida de seus filhos também.

Tenho amigos que mantiveram um código mais antigo do que são. Eu tenho um amigo que voltou para uma empresa 30 anos depois de trabalhar lá pela primeira vez, para descobrir que seus programas ainda estavam em execução, inalterados, em um idioma que ela nem se lembrava!

Deixe-me terminar com uma história verdadeira do que ambos podem acontecer.

Nos anos 70, uma empresafoi fundada para fornecer um mercado on-line para os comerciantes. O PDP-11 era um bom preço / desempenho adequado para eles, então eles escolheram isso. Eles estavam ultrapassando os limites de desempenho de uma máquina, então eles escreveram seu sistema em uma montagem PDP-11 altamente otimizada. Alguns anos depois, o PDP-11 parou de ser vendido. No entanto, os negócios foram excelentes, as máquinas duraram e as substituições em segunda mão foram fáceis de encontrar. Eles mantiveram sua plataforma. Alguns anos depois que as substituições se tornaram mais difíceis de encontrar. Um grande projeto foi feito para substituir a plataforma de negociação. Falhou. Eles tentaram novamente. E falhou novamente. Uma das principais causas do fracasso foi que ninguém sabia como o sistema de negociação funcionava e ninguém mais conseguia ler a montagem do PDP-11. Então a salvação chegou. Alguém criou um montador PDP-11 que rodava no Linux.

Foi assim que, em 2000, os negócios que chegavam a um bilhão de dólares / ano foram para máquinas Linux, através de uma ponte ethernet-decnet, para emular máquinas PDP-11 que executavam o comércio em um sistema de software escrito em PDP- altamente otimizado. 11 montagem. Para velocidade.

Eu não tive nenhuma conexão com a referida empresa na última década. Portanto, não posso dizer se eles ainda estão sendo executados em PDP-11s emulados. Eu sei que a decimalização estava apertando suas margens dolorosamente, então eles tiveram mais um esforço para migrar. (Eu só aprendi a história porque entrevistei várias pessoas que foram demitidas de lá e perguntei o que havia acontecido.) No entanto, dadas as falhas anteriores, eu daria melhor do que as chances de que elas não substituíssem com sucesso esse sistema.

Parece uma preocupação muito genuína da visão do usuário. Para que a podridão seja adiada, ou melhor, evitada, o software em questão precisa estar livre de suas correntes. Seus editores devem ter liberado o código-fonte ou devem manter e atualizar os códigos-fonte até que seu último usuário pare de usá-lo. Caso contrário, há uma chance muito grande de que eles possam sair do negócio devido a apodrecimentos semelhantes no mundo dos negócios, deixando assim o software totalmente aberto para os apodrecimentos.

Ou seja, a duração do prazo dos direitos autorais do software e das licenças restritivas deve ser muito curta, ao final do qual o software e sua base de códigos entram no domínio público e permanecem lá. Assim, possibilitando ao usuário continuar atualizando as fontes ou contratar alguém para fazê-lo, atrasando e / ou evitando os apodrecimentos.

Ou, se você estiver um pouco aberto à idéia de software livre, poderá escrever seus programas sob uma licença gratuita, como a AGPL ou a GPL ou outras licenças de software livre. Pelo que vi, quando as fontes de um software não atraem mais o interesse dos desenvolvedores em aprimorá-lo por qualquer motivo, a base de fontes é canibalizada e ganha vida nova. Pacotes no sistema operacional Debian tendem a seguir esse ciclo de vida, tanto quanto eu vi.

Tendo suportado uma variedade de aplicativos governamentais e do setor privado, eu diria que a maioria das empresas e, pelo menos, o governo dos EUA está ciente dos perigos de deixar o código apodrecer e não permanecer no topo das últimas tendências de segurança.

Precisamos regularmente obter nosso software certificado para várias suscetibilidades e a maioria dos sistemas eletrônicos do governo, mesmo os antigos, recebe atualizações regulares para mantê-los seguros.

É claro que existem exceções, e os hackers estão sempre em movimento, mas, no geral, acho que as pessoas estão cientes de que você não pode simplesmente jogar algo lá fora e nunca mais tocá-lo.

Aviso: Isso será um pouco de forma livre ...

Eu acho que existem duas maneiras de analisar sua preocupação.

Se você pensar bem, alguns ônibus espaciais e satélites executam o mesmo código que os lançou originalmente. Por outro lado, alguns foram projetados para serem atualizados, mesmo que sejam (muito) remotos.

O que importa é o meio ambiente. Obviamente, desde que você não modifique o ambiente, seu código não se tornará obsoleto. Nesse caso, o código rot realmente não existe: o próprio código (ou o binário produzido) não pode rot. Pode quebrar se você começar a atacá-lo de um ângulo completamente diferente. Não é que esteja apodrecendo, é que não está se adaptando ao ambiente. Pense nisso como um problema evolutivo.

Mas nosso ambiente muda. E de alguma forma, qual é a chave do seu problema também é a solução. Nosso ambiente muda tão rápido que hoje em dia não esperamos que uma solução de software evolua com o tempo. Ignoramos os projetos de software que não foram atualizados no ano passado e lamentamos o suporte ao produto e ao cliente que não produz um roteiro claro. E mesmo quando isso funciona bem - você obtém um roteiro claro, bom suporte, atualizações regulares ... - sempre há a chance agora que um desafiante virá à tona, com crescimento exponencial. Muitas vezes cometemos o erro de pensar que as grandes empresas estabelecidas sempre dominam, exatamente porque dominam. No entanto, da mesma forma que o elemento dominante em um rebanho envelhece, o software / hardware superdimensionado / qualquer fornecedor que envelhece. Ou apenas um pouco preguiçoso. E um desafiante chega e muda as coisas ainda mais rápido do que o dominante estabelecido poderia ter feito 5 ou 10 anos antes. Ou o dominante terá apenas uma boa surra, mal sobrevivendo enquanto vemos uma ruptura no mercado (economicamente falando, com impactos em diferentes campos), e as coisas continuarão. Talvez isso pareça imperfeito, mas por si só é um processo orgânico.

Então, da perspectiva do usuário, acho que o problema não é tão grande. A podridão de código não acontecerá da perspectiva do usuário, pois ele poderá usar uma alternativa (possivelmente com uma transição / migração contínua ... espero).

Agora, supondo que não estamos vendo as coisas do ponto de vista do usuário, ou que estamos falando de um sistema que é imune - por razões desconhecidas, desenvolvimento governamental, viagens espaciais, etc ... - à concorrência e é realmente suposto Para sermos construídos para viver / sobreviver por muito tempo, precisamos examinar os textos que você referenciou. E provavelmente um pouco mais de literatura sobre sistemas confiáveis ​​e sistemas tolerantes a falhas. Embora provavelmente desejemos avançar ainda mais. Não queremos apenas tolerância a falhas, queremos sistemas evolutivos.

O problema com a evolução é que ela introduz mudanças e as mudanças introduzem pontos de falhas. Vejamos agora e o que podemos fazer para resolvê-los.

Ainda podemos confiar na metáfora de infraestrutura / arquitetura / engenharia enquanto o fazemos (afinal, todos nós somos engenheiros de software, embora não haja indiscutivelmente engenharia de software ... por enquanto). Há uma razão para o sistema de tubos ainda estar ativo (com algumas falhas), enquanto o Big Ben ainda funciona (com algumas falhas) ou a Torre Eiffel ainda está de pé. É porque fazemos com elementos vitais (ou não tão vitais) de uma infraestrutura o que deveríamos fazer com o software também: inspeção contínua. Essas entidades não foram projetadas necessariamente para durar tanto tempo, mas se beneficiaram da supervisão permanente e de melhorias e reparos oportunos quando necessário. Chame isso de hotfixes, se desejar.

Por outro lado, alguns projetos foram feitos para durar e duram sem interrupção, mesmo sabendo que a inspeção contínua não será possível. Nesse caso, nos voltamos para um bom design e modelos formais. Elementos de confiabilidade (Disponibilidade, Confiabilidade, Segurança, Integridade, Manutenção) podem ser quantificados - para um determinado ambiente. As estatísticas fazem o resto para planejar o resto e o futuro. O que traz a questão: é possível construir sistemas que serão evolutivos, no sentido real?

Jeff Langer, no Clean Code, faz uma pergunta semelhante ... sem referências a tubos de vapor :)

E se houvesse quatro regras simples que você poderia seguir que o ajudariam a criar bons designs enquanto trabalhava? E se, seguindo essas regras, você obtivesse informações sobre a estrutura e o design do seu código, facilitando a aplicação de princípios como SRP e DIP? E se essas quatro regras facilitassem o surgimento de bons projetos?

Muitos de nós sentimos que as quatro regras de Kent Beck de Design Simples são de grande ajuda na criação de software bem projetado.

Segundo Kent (no Extreme Programming Explained), um design é "simples" se seguir estas regras:

• Executa todos os testes
• Não contém duplicação
• Expressa a intenção do programador
• Minimiza o número de classes e métodos

Para executar todos os testes ... precisamos de testes para executar, e esse é um enorme indicador de dívida técnica. Por exemplo, se houver 10.000 casos de teste em um sistema como o Mercury Quality Center e nenhum desses testes for automatizado, esse é um indicador claro da dívida técnica que foi criada.

E é aí que entra Feathers e seu livro "Trabalhando Efetivamente com o Código Legado".