Trabalhando com sistemas legados
Você ouve falar ou lê sobre empresas legais, que deixam levar cachorro pro escritório e que oferecem academia de ginástica, salão de jogos, ioga e cromoterapia durante o expediente. Pra completar, eles ainda desenvolvem aplicações revolucionárias e falam em IoT, Jarvis (na vida real) e DevOps. Nessa hora, você se lamenta por estar trabalhando com sistema legado?
Bem… talvez você não esteja vendo pelo ângulo certo…
Primeiro, vamos tentar definir o que é sistema legado
É só digitar “what is a legacy system?” no Google que encontramos a seguinte definição na Wikipedia, que reproduzo aqui grifando algumas palavras:
“Em computação, sistema legado é uma tecnologia, um sistema computacional ou uma aplicação antiga, muitas vezes suportadas por um computador ultrapassado. Frequentemente é usado como um termo pejorativo. Dizer que um sistema é “legado” sugere que o sistema está ultrapassado ou que precisa ser substituído“.
Não é à toa que tanta gente fala mal da Wikipedia. Mas outros “dicionários on-line” e sites diversos têm definições semelhantes que repetem as expressões “outdated” e “in need of replacement“.
O que primeiro me chama a atenção é a ideia de “computador ultrapassado”. Muitos sistemas legados foram escritos (e são mantidos) em COBOL, NATURAL e PL/I. Boa parte deles roda em mainframes da família System Z, da IBM. No momento em que esse artigo está sendo escrito, o último modelo Z havia sido lançado em 2015, com o nome de Z/13. Essa máquina tem capacidade para processar 2,5 bilhões de transações comerciais por dia, ou o equivalente a 100 Cyber Mondays ou Black Fridays em único dia. Continua funcionando durante um terremoto de 8.0 na escala Richter. Substitui até 8.000 servidores Linux. Consumiu US$ 1 bilhão de dólares em pesquisa e desenvolvimento e deu origem a mais de 500 patentes, predominantemente na área de criptografia e segurança.
Se essa é uma máquina ultrapassada, então a única máquina moderna é o HAL 9000, que tentou matar o astronauta no filme do Kubrick.
Outro conceito interessante é aquele que diz que sistemas legados “precisam ser substituídos”. Se o sistema de conta corrente de um grande banco “precisasse” ser substituído isso teria acontecido nos dois ou três anos que antecederam o ano 2000. Naquele período, todas as grandes empresas do mundo tiveram que varrer dezenas de milhares de programas, ajustar o tratamento de datas, testar, homologar e implantar as correções antes do muro intransponível que estava parado às 23h59 do dia 31/12/1999. E tiveram que fazer isso sem afetar a operação do negócio.
Por que não substituíram? Porque um sistema que existe há décadas é estável, resultado de um investimento de dezenas de milhões de dólares; é seguro, portável (o programa que roda no z/13 é o mesmo que rodava no 4381, das décadas de 1970/1980), escalável (ele começou processando milhares de transações e hoje processa milhões) e integrado (conversa com qualquer outra plataforma, de caixas eletrônicos a portais na Web).
Convenhamos, precisar ser substituído ele não precisa. A definição faria mais sentido se dissesse que sistemas legados podem ser substituídos. Mas aí, meu caro, qualquer sistema se encaixaria nessa definição.
Sistemas legados são aplicações antigas
É fato que operadoras de cartão de crédito, bancos, agências de governo, grandes redes de varejo, empresas aéreas, concessionárias de serviço público… grande parte delas roda sistemas que foram desenvolvidos 20 ou 30 anos atrás, às vezes mais.
Mas pense naquele sistema em Visual Basic, Delphi, Power Builder, ASP ou mesmo Java que todos nós desenvolvemos em algum momento da vida, há menos de 20 anos… Quantos ainda devem estar rodando? Quantos foram substituídos por pacotes ou tiveram que ser reescritos (em outra plataforma) para aproveitar a evolução que a tecnologia proporcionou nesse período?
Todo sistema, independentemente da plataforma e da arquitetura, será legado em algum momento. Desde que consiga se justificar por tanto tempo.
Se você trabalha com um sistema legado e não gosta dele, tente ver por outro ângulo: se ele ainda está lá, é porque não encontraram alternativa tecnicamente melhor e/ou economicamente viável.
O lado chato do dia a dia de quem trabalha com sistemas legados
Se você entrou pra essa área porque gostava de tecnologia e programação então você já percebeu: mexer no código dos outros dá sono, irrita, entristece, decepciona… às vezes tudo ao mesmo tempo.
É muito melhor poder desenhar uma arquitetura de sistemas do zero, definir padrões de documentação e programação, selecionar metodologia, projetar o sistema, construir e implantar… Muito postit na parede! Tudo limpo! Tudo novo! Seguindo as melhores práticas!
Mas nem sempre é como a gente gostaria que fosse.
Clientes querem prazo e preço baixo. Se não houver uma promessa de retorno muito alto que compense os riscos ele nem vai querer ouvir falar na possibilidade de trocar o certo pelo duvidoso, ou de investir numa melhoria. E nós continuaremos lá, abrindo programas Cobol de algum humorista do passado que resolveu reaproveitar variáveis e dar nomes enigmáticos para seus parágrafos.
Mas o tédio não está associado ao fato do sistema ser “legado”. O tédio está muitas vezes ligado ao método de trabalho que algumas (se não muitas) empresas adotam no seu dia a dia.
Sistemas legados exigem manutenções corretivas e evolutivas. E um dos grandes equívocos que presenciei (mais de uma vez) é querer ignorar que manutenção evolutiva é uma coisa e desenvolvimento de sistema é outra.
Já vi arquitetos quererem “corrigir o passado”, exigindo especificações funcionais e técnicas em conformidade com as mais modernas metodologias de desenvolvimento, em sistemas que NUNCA tiveram nenhum tipo de documentação. Eles alegavam que se não começássemos a produzir as especificações, diagramas e casos de uso… aí é que o sistema não teria documentação mesmo, nunca mais.
O raciocínio equivocado, na minha humílima opinião! Todo livro começa com um manuscrito. Logo, se a Bíblia não tem manuscrito precisamos escrever um (!). Um caso de uso poderia ter ajudado nos anos 1980, quando o sistema estava sendo construído. Agora não precisa mais! Os programas estão prontos e rodando há décadas! Agora a gente precisa de ferramentas, métodos e processos customizados para o trabalho de quem quer entender o sistema e implementar correções e evoluções que rodem certo na primeira vez.
Por que não investir, por exemplo, no uso de computação cognitiva para acelerar o entendimento funcional do sistema, facilitando a elaboração de estimativas e análises de impacto?
Por que não investir em ferramentas de refactoring que possam, efetivamente, diminuir a entropia de sistemas que passaram na mão de analistas e programadores com diferentes níveis de conhecimento e capricho?
Por que não pensar num tipo de documentação diferente daquela que está na moda, e que foi discutida apenas sob a ótica de quem pretende desenvolver um sistema novo?
Por que, ao invés de copiar às cegas as regras dos teóricos da UML, não pensamos numa modelagem reversa que facilite o entendimento de novos analistas e novos programadores que toda hora sobem a bordo das nossas equipes?
A verdade está nos fontes e só precisamos extraí-la de lá.
O lado bom do dia a dia de quem trabalha com sistemas legados
Antes de Greys Anatomy e suas intermináveis reflexões sobre relacionamentos e pessoas, houve uma outra série hospitalar chamada E.R. (ou Plantão Médico, no Brasil) que mostrava as agruras de uma equipe de médicos num pronto socorro.
Os dramas mais legais dessa série aconteciam quando, no meio de um diálogo prosaico entre os personagens, a porta se abria de repente e entrava uma vítima de acidente ou um paciente com alguma crise aguda que exigia rapidez, precisão e conhecimento dos médicos.
Trabalhar com sustentação de sistemas legados muitas vezes me passa essa sensação. Um programa abendado de madrugada é um paciente infartado. Ok, é provável que ninguém morra por causa disso, mas os problemas operacionais e financeiros que um sistema parado pode causar exigem rapidez, eficiência e talento dos profissionais envolvidos. Entender o defeito (o sintoma), encontrar sua causa (a doença), intervir no programa sem provocar um problema maior (o procedimento) e botar o programa para rodar (voltar a ouvir o bip-bip do monitor cardíaco) dá uma tremenda satisfação. Pelo menos para mim.
Da mesma forma, é necessário conhecimento e experiência para implementar uma manutenção evolutiva num “senhor” de 30 anos, sem aumentar a entropia que um sistema dessa idade certamente já tem. As intervenções têm que atender aos requisitos sem afetar (ou prejudicar ainda mais) a saúde dos programas impactados.
Outro desafio interessante é conhecer e dominar, o mais rapidamente possível, a funcionalidade e a lógica de cada um dos programas e sistemas sob nossa responsabilidade. Além de conhecimento técnico de linguagens, ferramentas e ambientes, isso exige que a gente desenvolva memória, capacidade de análise e habilidade para focar no essencial.
Conclusão
Desenhar e construir sistemas e aplicações novas é muito legal, e provavelmente foi isso que nos trouxe para essa profissão. Mas ninguém vai refazer sistemas de dois em dois, e por isso sempre haverá mais opção de trabalho em manutenção do que em desenvolvimento.
Se um sistema for bem desenvolvido e corretamente mantido ao longo do tempo, certamente ele será legado um dia. E por isso precisamos descobrir a melhor forma de trabalhar com ele.
