O que é um software legado? Quando um software se torna legado? Por que o termo legado se tornou pejorativo na área de software? Há respostas simplistas a tais perguntas e, em geral, elas geram um impacto negativo para quem considera que trabalha com software legado. O tema é complexo e pode ser examinado por uma perspectiva diferente, principalmente porque o software legado ainda está presente no dia a dia de muitos times.
Há muitas variações com relação a como cada desenvolvedor(a) interpreta o que vem a ser software legado, dentre as mais comuns temos softwares:
- Escritos com linguagens “mais antigas”.
- Com arquitetura monolítica.
- Sem testes.
- Com muitas dívidas técnicas.
- Que o time tem dificuldades em manter e/ou evoluir.
O fato é que o termo legado se tornou pejorativo quando associado a desenvolvimento de software, o que contraria uma visão geral do termo, onde para muitas pessoas refere-se a “deixar algo positivo, valioso ou impactante para as gerações futuras”. Mas olhando puramente para o significado do termo, não há julgamento de valor sobre ser negativo ou positivo, legado refere-se simplesmente a “o que é passado às gerações futuras”.
Legado é visto como negativo em software por normalmente deixarmos para as pŕóximas gerações (próximos times) softwares difíceis de manter. Contudo, considerando o significado do termo, um software legado deveria ser apenas aquele cuja manutenção é herdada por outros times. Diante dessa interpretação e das perguntas iniciais, pode-se afirmar que:
Software legado não é exatamente um software antigo e com problemas, é algo que foi implementado há algum tempo e que agora ainda precisa ser mantido.
Não há uma marcação exata de tempo, linguagem ou arquitetura utilizada que define que o software é ou vai se tornar legado.
O termo se tornou pejorativo porque muitos softwares crescem acumulando problemas de arquitetura e código, os quais herdamos ao assumir a manutenção.
Logo, se um software é escrito em uma linguagem e arquitetura mais antiga, sem testes, com muitas dívidas técnicas e difícil de manter e evoluir, não determina automaticamente que tal software seja um legado! Tal software provavelmente é apenas um software mal construído (talvez há poucos meses).
Porém, há termos tão consolidados que torna-se difícil mudar a interpretação deles.
Desta forma esse artigo não tem pretensões de mudar a interpretação já existente sobre software legado! Mas pode mudar seu sentimento e comportamento ao trabalhar em softwares considerados legados! (ou só mal implementados)
Os próximos tópicos destacam como trabalhar com software legado de forma mais saudável!
O valor que o software legado gera.
É comum que ao trabalharmos em um software considerado legado, tenhamos o sentimento de estar estagnados tecnicamente ou de estar participando de entregas menos badaladas e de baixo valor. Mas se softwares legados ainda estão ativos, é porque geram algum valor, seja financeiro ou estratégico, e por vezes são os que ainda mantêm uma boa saúde financeira de uma empresa ou que proporcionam oportunidades para novas soluções.
Desta forma, atuar na manutenção e até evolução do software é contribuir para que a empresa mantenha sua operação, que clientes continuem a usufruir dos benefícios ao utilizarem o software e que toda uma cadeia de valor se mantenha ativa, indo de colaboradores(as) da empresa que mantém o software até as pessoas que são impactadas direta ou indiretamente com a solução que o software gera.
Nosso compromisso como desenvolvedores(as) de software deve ir além do “aprender e trabalhar com tecnologias legais e atuais”, deve focar em trabalhar em softwares que agregam algum valor!
Um software que gera valor ao ser denominado como legado não deveria impactar na motivação de mantẽ-lo! Já um software com arquitetura moderna e construído com as melhores práticas de desenvolvimento, sem gerar valor para clientes, é um software sem sentido!
Se o software ainda gera valor, orgulhe-se em trabalhar em um software legado!
Se o software é considerado legado porque foi mal implementado, aproveite a oportunidade para fazer melhorias técnicas, desde que elas agreguem valor..
A continuidade do software.
Quando um software ainda é utilizado, há um compromisso implícito de quem o mantém para com quem o utiliza. Manter esse software em funcionamento e estável se torna um comportamento responsável que dá segurança de continuidade a toda uma cadeia de atores que depende do funcionamento deste software.
O fato de um software ser considerado legado, por vezes faz devs baixarem seus critérios com relação a qualidade, mas é sobre esses softwares, principalmente se geram grande valor, que se deve manter criteriosidade com relação às modificações para garantir o adequado funcionamento.
Assim como nós, desenvolvedores(as), esperamos ter continuidade das linguagens, frameworks e bibliotecas que utilizamos, devemos nos dedicar para manter a continuidade do software do qual somos responsáveis!
A arquitetura e o código de um software legado.
Essa talvez seja a questão de maior lamentação entre devs quando falamos sobre software legado! É comum que a má implementação seja confundida com as escolhas arquiteturais do software, o que pode ter relação, contudo a arquitetura define apenas como organizar o código e estruturar responsabilidades de cada parte, incluindo formas de comunicação entre estas partes.
O que normalmente dificulta a manutenção e evolução de um software é o alto acoplamento e baixa coesão dos componentes, módulos, pacotes, classes e métodos, além da baixa legibilidade de código.
Logo, embora a arquitetura possa contribuir para dificuldades em manter um software, ela não é exatamente a maior vilã dos considerados legados. Algumas arquiteturas hoje vistas como antigas, logo associadas a legados, como monólitos, server side, dentre outras, são boas arquiteturas e que inclusive ainda possuem boa aplicabilidade.
Se a arquitetura do software legado que você trabalha compromete sua motivação, avalie se o problema de manutenibilidade é arquitetural de fato ou apenas código mal implementado, que, comumente, não respeita a arquitetura inicialmente definida.
Antes de mudar a arquitetura, avalie melhorias na implementação do código buscando reduzir o acoplamento e aumentar a coesão. Faça opção por mudanças de arquitetura em função das necessidades de negócio e requisitos não funcionais.
Há soluções hoje com arquiteturas distribuídas fazendo uso de microservices, FaaS (functions as a service), há frontends fazendo uso de SPA (single application pages), microfrontends, dentre outras, sendo todas elas arquiteturas consideradas modernas, mas algumas cuja o código já apresenta as mesmas dificuldades de manutenção e evolução que seus antecessores legados. Arquiteturas novas com código ruim são candidatas a se tornarem rapidamente novos legados.
Testes automatizados.
Uma das maiores dificuldades em manter e evoluir o código de um software legado está na comum ausência de testes automatizados. Por vezes, é complexo adotar testes automatizados em softwares legados, porém não adotar tende a ser uma opção de maior custo se houver constante necessidade de manutenção no código.
Devs normalmente focam em testes unitários, mas mais importante que o tipo de testes é ter testes que explicitem as funcionalidades. Nosso comportamento como desenvolvedores(as) deve priorizar a garantia de que qualquer manutenção não irá gerar impactos negativos nas funcionalidades do software.
Se o software legado não possui testes, então:
- Crie uma lista das funcionalidades mais importantes do software, ordenando-a pela sua relevância e valor que a mesma gera ao cliente. Apresente o quão relevante é garantir que tais funcionalidades nunca contenham erros e quanto um problema pode impactar financeiramente ou estrategicamente.
- Inicie implementação por testes de integração, de componentes ou outros posicionados mais ao topo da pirâmide de testes, de forma que a implementação custe pouco tempo e gere maior confiabilidade do todo.
Trabalhar em um software legado, com testes, diminui em muito a insegurança com relação às manutenções.
Automatização de rotinas.
Software considerados legados normalmente possuem várias rotinas manuais, ou que até possuem scripts que facilitam sua execução, mas que não estão devidamente documentadas e/ou conectadas a processos de CI/CD (Integração e Implantação Contínua).
Tais rotinas se tornam tediosas para devs e passíveis de erros em sua execução, o que gera insegurança e desmotivação em times que atuam na manutenção do legado.
O primeiro passo é mapear todas rotinas executadas, identificando quais são passíveis de automatização.
Das automatizáveis, deve-se avaliar quais são executadas com maior frequẽncia e, então, deve-se iniciar a automatização por elas.
Cada rotina automatizada permite que o tempo antes utilizado para tais execuções seja direcionado para outras melhorias no legado e/ou ainda atuar em novos softwares.
Dívidas Técnicas.
Softwares legados acumulam dívidas técnicas, sendo algumas conscientes e muitas inconscientes. Tais listas tendem a gerar no time um sentimento de problemas que nunca se resolvem e normalmente são desconsideradas em momentos de priorização.
Gerar dívida técnica não é algo totalmente negativo, dívidas conscientes fazem parte de um processo maduro de desenvolvimento de software. O maior ponto de atenção está no como e quando as dívidas serão pagas. Software legados tendem a ter dívidas que dificilmente serão pagas. Em casos assim, é sensato avaliar quais dívidas ainda fazem sentido serem pagas, pois se o pagamento da dívida custar muito tempo e não gerar um retorno real, é aceitável que tal dívida seja considerada caduca (fazendo alusão ao mundo financeiro).
Concentre-se nas dívidas técnicas que geram maior dificuldade ao time apresentando o impacto negativo financeiro ou estratégico.
Uma dívida técnica a ser paga em um legado não deve focar só na melhoria técnica e sim em como ela permitirá a continuação da geração de valor que o legado possui.
Todo software tende a se tornar legado e isso não significa que ele deva ser de difícil manutenção e que devs tenham um sentimento negativo ao trabalhar nele.
Se você trabalha em um software considerado legado, não deixe isso influenciar a motivação! Lembre que se o legado está ativo é porque gera algum valor e você é responsável por manter essa geração de valor!
Legados podem ser melhorados, comece focando no baixo acoplamento e alta coesão como um todo antes de iniciar com mudanças de arquitetura. Implemente testes automatizados, automatize rotinas que envolvem integração e implantação contínua, elimine dívidas técnicas, sempre destacando como cada melhoria manterá a geração de valor do legado!
As ponderações deste artigo são apenas algumas dentre outras que podemos fazer para trabalhar melhor com softwares legados.
Softwares novos geralmente só existem porque houveram legados antes deles, cabe a nós manter e honrar os legados, para construir novos softwares melhores!
A imagem principal foi composta a partir de ilustrações de: Fundo vetor criado por macrovector - br.freepik.com