Muitas empresas acabam com um aplicativo do qual ninguém cuida ativamente. O desenvolvedor ou a agência original seguiu em frente, as versões deixaram de ser lançadas, a loja de aplicativos alerta sobre SDKs desatualizados e ninguém se sente seguro para alterar o código. O instinto costuma ser continuar aplicando remendos ou começar do zero. Nenhuma das duas opções deve ser decidida por instinto. Este guia de resgate de aplicativos explica como avaliar um aplicativo abandonado e escolher entre refatorar o que existe e reconstruí-lo, com base em evidências, e não em frustração.
O que é
O resgate de um aplicativo começa por entender o que você realmente tem. Isso significa recuperar o acesso ao código-fonte, à configuração de build, às chaves de assinatura, às contas de hospedagem, às páginas nas lojas de aplicativos e aos serviços de terceiros; depois, revisar a estrutura do código, as dependências, a cobertura de testes e os defeitos conhecidos; e, em seguida, verificar se o aplicativo ainda compila e funciona nas versões atuais dos sistemas operacionais. Refatorar significa melhorar a base de código existente no próprio lugar: atualizar dependências, corrigir defeitos, reestruturar áreas problemáticas e adicionar testes, mantendo o aplicativo funcionando. Reconstruir significa escrever uma nova base de código, geralmente reaproveitando designs, dados e serviços de backend sempre que possível, e migrar os usuários para ela. Refatorar preserva o investimento já feito e evita um longo período sem novas versões. Reconstruir pode ser a opção mais adequada quando a base de código é impossível de manter, foi construída sobre um framework obsoleto ou é fundamentalmente incompatível com o que o produto precisa hoje. Muitas vezes, a resposta é uma combinação: estabilizar agora e substituir partes progressivamente.
Para Quem É
Este guia é útil para:
- Empresas cujo desenvolvedor ou agência do aplicativo não está mais disponível
- Responsáveis por produtos cujo aplicativo não compila, trava em dispositivos novos ou é rejeitado pela loja de aplicativos
- Fundadores que herdaram de uma equipe anterior um aplicativo inacabado
- Equipes que estão decidindo se devem continuar investindo em uma base de código existente
O Que Isso Ajuda A Esclarecer
Uma avaliação estruturada ajuda a esclarecer:
- Se você tem plena titularidade e acesso ao código, às chaves, às contas e aos dados
- Quanto do código existente é sólido, quanto é arriscado e quanto está faltando
- Se o framework e as dependências ainda têm suporte
- Qual caminho, entre refatorar, reconstruir ou substituir em etapas, se adequa ao seu cronograma e à sua tolerância a risco
O que está incluído
- Recupere o acesso: repositórios de código-fonte, arquivos de build, certificados de assinatura e keystores, contas de nuvem e de hospedagem, contas nas lojas de aplicativos e chaves de API de terceiros
- Confirme a titularidade jurídica do código e de eventuais licenças, com seus próprios consultores, se necessário
- Verifique se o aplicativo compila a partir do código-fonte e funciona nas versões atuais dos sistemas operacionais
- Revise as dependências em busca de bibliotecas desatualizadas, sem suporte ou vulneráveis
- Avalie a estrutura do código, a cobertura de testes e a documentação
- Liste os defeitos conhecidos, relatórios de falhas, reclamações de usuários e alertas das lojas de aplicativos
- Mapeie o backend, as APIs e os dados dos quais o aplicativo depende
- Pontue as opções: refatorar, reconstruir ou substituir em etapas, considerando esforço, risco e tempo sem novas versões
- Acorde um plano de estabilização para os problemas urgentes antes de iniciar trabalhos maiores
O que não está incluído
- Afirmação de que todos os problemas legados serão encontrados ou resolvidos
- Desenvolvimento de novas funcionalidades além do escopo de recuperação confirmado
- Avaliação formal de segurança ou teste de intrusão, salvo se definidos em escopo separado
- Consultoria jurídica sobre titularidade do código ou disputas com fornecedores anteriores
Quando Escolher
Aja quando o aplicativo não puder mais ser lançado com segurança, quando os requisitos da plataforma estiverem prestes a torná-lo incompatível com as regras da loja ou quando cada pequena alteração introduzir novos problemas. Não espere até que o aplicativo seja removido de uma loja ou que um serviço crítico seja desativado. Se você não tem acesso ao código-fonte ou às chaves de assinatura, resolva isso primeiro; sem eles, a reconstrução pode ser a única opção, independentemente da qualidade do código.
Nossa abordagem
Comece pelo acesso e pelas evidências, não por opiniões. Muitos aplicativos abandonados são melhores do que parecem quando voltam a compilar; outros parecem bons, mas dependem de frameworks que já não são viáveis. Tome a decisão com base em uma avaliação por escrito que abranja código, dependências, infraestrutura e necessidades do produto. Nosso serviço App Rescue & Rebuild abrange avaliação e recuperação: recuperar um build funcional, estabilizar problemas críticos e recomendar e executar o caminho de recuperação confirmado, com um registro de recuperação com escopo definido e materiais de transferência. Quando o problema se estende a uma plataforma mais ampla, a um backend ou a um sistema legado, o serviço Platform Rescue & Modernisation oferece um mapa do estado atual, um plano de estabilização e um roteiro de modernização. Após a recuperação, planeje a manutenção contínua para que o aplicativo não volte ao mesmo estado: atualizações programadas de dependências, uma rotina de lançamentos e uma definição clara de quem é responsável pelas contas e pelas chaves.
Perguntas Frequentes
Artigos relacionados
Começar
Preso a um aplicativo que ninguém consegue manter?
Conte-nos a que você tem acesso, o que está com problema e o que o aplicativo precisa fazer a seguir. Proporemos uma avaliação e um escopo de recuperação por escrito.
Solicitar um escopo por escrito