Manutenção e evolução de sistemas

Para quem faz sentido

• O sistema funciona, mas cada funcionalidade nova demora mais que a anterior.
• Quem construiu não está mais disponível.
• Existem defeitos conhecidos que ninguém consegue reproduzir com segurança.
• As dependências estão desatualizadas e ninguém quer ser o primeiro a atualizar.

Problemas que resolvemos

• Custo de mudança que só cresce

  Quando cada alteração exige entender o sistema inteiro, o prazo de qualquer pedido aumenta. Normalmente não é falta de capacidade do time: é ausência de limites claros entre as partes, e isso é recuperável.

• Comportamento que ninguém consegue explicar

  Erros que aparecem em produção e não se reproduzem localmente costumam ser falta de visibilidade, não mistério. Registro, monitoramento e um caminho reproduzível de execução transformam isso em problema comum.

• Dependências paradas no tempo

  Quanto mais tempo sem atualizar, mais arriscada fica a atualização — e o risco não desaparece esperando. O caminho é atualizar em etapas verificáveis, começando pelo que tem cobertura ou pelo que é mais isolado.

• Sistema sem quem o conheça

  Quando o time original saiu, o conhecimento ficou no código e em ninguém. Recuperar isso é um trabalho concreto: mapear o que existe, onde estão as regras e o que é seguro tocar — antes de prometer prazo.

O que fazemos

• Diagnóstico técnico do sistema atual
• Correção de defeitos e comportamento inconsistente
• Evolução funcional contínua
• Atualização de dependências
• Observabilidade e processo de deploy
• Modernização por partes

Como trabalhamos

• Entender antes de estimar

  Entender o estado atual do sistema vem antes de estimar prazo e escopo: o que ele faz, onde estão as regras de negócio e o que é seguro alterar. Essa leitura pode concluir que o melhor caminho não é conosco, ou que reescrever custa menos que manter.

• Estabilizar antes de acelerar

  Primeiro o sistema para de surpreender: os defeitos mais frequentes, a visibilidade do que acontece em produção e um caminho de deploy confiável. Só depois disso faz sentido acelerar entrega de funcionalidade.

• Modernização por partes

  Trocar tudo de uma vez concentra o risco no pior momento possível. Preferimos isolar uma parte, substituí-la com o comportamento antigo ainda disponível, e repetir — mesmo que a soma leve mais tempo.

• Deixar o sistema explicável

  O objetivo não é criar dependência de quem mantém. Decisões registradas, ambiente reproduzível e o mínimo de conhecimento que só existe na cabeça de alguém — inclusive na nossa.

Onde atuamos

Relacionado

Perguntas frequentes

• É possível assumir um sistema desenvolvido por outra empresa?

  Em geral sim, desde que haja acesso ao código, ao ambiente e ao histórico. Começa por entender o sistema existente, suas dependências e os pontos de maior risco — sem isso, qualquer prazo seria chute.

• Vale mais manter ou reescrever?

  Depende de onde está o problema. Se a arquitetura ainda sustenta o que o negócio precisa, manter e evoluir costuma custar bem menos. Reescrever se justifica quando o custo de cada mudança já supera o de recomeçar — e mesmo aí, normalmente por partes, não de uma vez.

• Como começar a modernizar um sistema legado?

  Pelo que dá visibilidade: registro, monitoramento e testes nas áreas mais críticas. Com isso é possível mudar o resto com segurança, em vez de trocar tudo e descobrir os efeitos em produção.