No mundo do software, cinco anos podem significar tanto um sistema ainda muito bem preparado para дальнейzo desenvolvimento, como um problema tecnológico que, a cada mês, custará cada vez mais.
No entanto, a idade da aplicação por si só não é motivo para a substituir.
Esta é uma das coisas mais importantes a dizer logo no início.
Não existe um limite universal após o qual uma aplicação deva ser reescrita do zero. Existem sistemas que funcionam há várias dezenas de anos e que ainda têm uma arquitetura sensata, dependências atualizadas, boa documentação e um processo de deployment comprovado. Existem também aplicações muito mais jovens cujo desenvolvimento foi dificultado por decisões arquitetónicas erradas, falta de testes, dependências descontroladas ou sucessivos remendos rápidos.
O problema não é, portanto, o número de anos.
O problema é a capacidade do sistema para continuar a mudar.
A pergunta mais importante não é: "A aplicação é antiga?"
A melhor pergunta é: "Quanto custa-nos a próxima mudança?"
Se adicionar uma nova funcionalidade exige cada vez mais horas, envolver várias equipas, testes manuais e contornar limitações da arquitetura antiga, o sistema começa a gerar um custo que não se vê no próprio código.
Este é precisamente um dos sinais práticos do aumento da dívida técnica.
Dívida técnica pode ser entendida como o custo de mudanças futuras resultante de decisões técnicas anteriores. Martin Fowler descreve-a como o esforço adicional que é preciso suportar ao modificar o sistema, quando a sua qualidade interna dificulta a evolução.
É precisamente por isso que uma aplicação pode continuar a funcionar corretamente e, ao mesmo tempo, tornar-se cada vez mais difícil de desenvolver.
10 funcionalidades depois, o sistema parece completamente diferente
O início de um projeto é muitas vezes simples.
Cria-se um MVP.
Depois surgem novos requisitos:
- integração com CRM,
- pagamentos online,
- painel administrativo,
- aplicação móvel,
- novos papéis de utilizador,
- relatórios,
- automatizações,
- API,
- integrações com serviços externos,
- novas versões linguísticas.
Cada alteração, por si só, pode ser justificada.
O problema surge quando a arquitetura não foi concebida tendo em conta essa direção de desenvolvimento.
Nessa altura, as novas funcionalidades deixam de ser adicionadas a uma estrutura estável.
Passam a ser adicionadas a exceções anteriores, soluções de contorno e compromissos.
Como reconhecer que o sistema começa a envelhecer?
Não é preciso esperar por uma falha total.
Os sinais de aviso aparecem muito antes.
1. Uma nova funcionalidade demora cada vez mais
Antes, uma funcionalidade demorava alguns dias. Hoje, uma alteração semelhante exige várias semanas.
Isso não tem de significar uma equipa mais lenta.
Pode significar que cada vez mais tempo é consumido a compreender o sistema existente e a protegê-lo dos efeitos da mudança.
2. Cada alteração desencadeia um efeito dominó
Modificar um módulo causa problemas em vários outros locais.
Isto é um sinal de que os componentes estão demasiado interligados ou de que as fronteiras de responsabilidade entre eles foram mal definidas.
3. Os testes são maioritariamente manuais
Se cada grande alteração exige verificar manualmente dezenas de funcionalidades, o custo de implementação aumenta.
O problema não é a ausência de automação em si.
O problema é não haver forma de obter rapidamente informação fiável sobre se a mudança estragou alguma coisa.
4. A equipa tem medo de mexer em determinadas partes do sistema
Este é um indicador muito prático.
Se existem módulos que os programadores evitam porque "ninguém sabe ao certo o que vai acontecer depois da alteração", o risco técnico já é um custo de negócio real.
5. O sistema depende de tecnologias desatualizadas
Um framework antigo, por si só, não significa um problema.
O problema surge quando:
- já não é suportado,
- é difícil encontrar especialistas,
- as dependências não podem ser atualizadas em segurança,
- o ambiente de execução é problemático,
- a integração com novas soluções é dificultada.
Nessa altura, a tecnologia começa a limitar as possibilidades de negócio.
É sempre preciso reescrever a aplicação do zero?
Não.
Este é um dos erros mais frequentes na abordagem ao legacy software.
Uma reescrita completa pode ser justificada, mas é um projeto de alto risco.
Um sistema antigo contém frequentemente dezenas ou centenas de regras de negócio, exceções e comportamentos que não constam da documentação. Ao reescrevê-lo do zero, pode ser muito fácil criar um sistema tecnologicamente novo, mas incompleto do ponto de vista do negócio.
Por isso, em muitos casos, a melhor solução é a modernização faseada.
Uma parte do sistema continua ativa e as restantes áreas são gradualmente substituídas por novos componentes.
Esta abordagem é conhecida, entre outras coisas, como o padrão Strangler Fig. Permite modernizar o sistema passo a passo, entregar valor mais cedo e reduzir o risco de uma migração única de toda a solução.
Quando é que a modernização faz sentido?
Vale a pena considerá-la quando:
- o sistema continua a suportar processos de negócio importantes,
- a arquitetura permite isolar pelo menos parte da funcionalidade,
- os dados podem ser migrados ou integrados em segurança,
- o problema diz respeito a áreas concretas e não a toda a estrutura,
- a aplicação gera valor e a sua substituição total seria arriscada,
- o sistema pode ser modernizado por fases.
Esta é uma solução particularmente boa no caso de sistemas que não podem simplesmente ser desligados durante vários meses.
Quando é que a modernização pode não fazer sentido?
Há também situações em que continuar a salvar um sistema antigo deixa de ser económico.
Por exemplo, quando:
- a arquitetura é fundamentalmente incompatível com os requisitos atuais,
- as tecnologias chave já não são suportadas,
- o sistema não tem testes nem documentação fiáveis,
- a segurança exige uma reconstrução profunda,
- cada grande alteração exige intervenção em quase todo o sistema,
- faltam pessoas que compreendam o seu funcionamento,
- os custos de manutenção e evolução superam o valor de continuar a utilizá-lo.
Nesse caso, vale a pena calcular não só o custo da modernização.
É preciso calcular também o custo de manter a solução atual.
A aplicação mais cara nem sempre é a mais cara de manter
Pode ter-se um sistema cuja manutenção mensal custa relativamente pouco.
E, ao mesmo tempo, cada nova funcionalidade custa muito mais do que deveria.
É precisamente por isso que a fatura do alojamento, do servidor ou do suporte não diz ainda quanto custa a tecnologia.
O custo real do sistema inclui também:
- tempo de desenvolvimento,
- tempo de testes,
- custo dos erros,
- tempo de implementação,
- custo de interrupções,
- dificuldade de recrutamento,
- risco de segurança,
- custo da perda de conhecimento,
- atraso de novas funcionalidades,
- limitações de negócio decorrentes da tecnologia.
Em algum momento, a tecnologia deixa de ser uma ferramenta que apoia o negócio.
Passa a ser uma limitação para o negócio.
Como abordar a decisão?
Antes que se tome a decisão de "reescrever do zero", vale a pena realizar uma auditoria técnica.
Ela deve abranger pelo menos:
Arquitetura - como o sistema está dividido e como os seus elementos se comunicam.
Código - qualidade, complexidade, repetição e pontos particularmente difíceis de manter.
Dependências - frameworks, bibliotecas, versões e seu suporte.
Segurança - vulnerabilidades, forma de gerir o acesso e riscos decorrentes de componentes desatualizados.
Testes - nível de automatização e possibilidade de introduzir mudanças com segurança.
CI/CD - forma de construir, testar e implementar a aplicação.
Dados - estrutura da base de dados, migrações, integrações e dependências.
Monitorização - se se sabe o que acontece com o sistema após a implementação.
Processo de desenvolvimento - quanto realmente custa entregar a próxima funcionalidade.
Só com base nisso é possível considerar racionalmente três cenários:
- mantemos e desenvolvemos,
- modernizamos por etapas,
- construímos um novo sistema.
Não existe uma única resposta correta. Existe, no entanto, uma forma correta de chegar à resposta.
A tecnologia deve possibilitar o crescimento, e não bloqueá-lo
Uma boa arquitetura não consiste em o sistema parecer moderno.
Consiste em poder ser alterado quando o negócio assim o exige.
Por isso, vale a pena olhar para a aplicação não apenas pela perspetiva de saber se ela funciona hoje.
Também é preciso verificar, quanto custará adicionar funcionalidades nos próximos um, dois ou cinco anos.
Porque um sistema que funciona, mas impede um desenvolvimento eficiente, pode ser um problema muito maior do que um sistema que simplesmente precisa de modernização.
